订单分布式锁 锁不住

之前 那个订单 哪里 不是加了分布式锁 锁不住吗，你后来是怎么改的

表设计是 orderid status sku orderType
xx
当时是因为太多的条件干扰，我把锁的粒度放在整个方法上，然后key加了sku，加了30秒过期时间(不过这个不加也是默认30秒)

xx
这样就锁住了

test:
我们 那个订单 判断 业务还是复杂了，影响TPS

test:
有没有觉得

test:
虽然订单量不大

xx
是的，业务比较复杂

xx
判断很多

xx
后面我还做了很多优化，包括把事务缩小，sql优化

test:
[动画表情]

xx
当时直接把锁往上移，出现很多的超时，一天几百上千，然后我在去年年底改了一版，现在一个多月都才不超过5次超时

xx
我现在都还可以收到那个接口超时短信，sd没把邮箱给我去掉，好几个月都才收到一次超时

xx
妈的，给他们做的太好也不行

test:
哈哈哈

test:
你是把锁移到最外层那个 service 方法去了吗

xx
是的

xx
然后优化了sql，把真正用事务的提取出来，事务粒度缩小

xx
还是用了这3步

test:
事务缩小 你是一个@Transaction 改成了多个@Transaction
？

xx
那些查询判断原来都放在一个事务中，都不需要的

xx
就把最后修改放在事务里

xx
只用了一个事务

test:
哦哦 是的查询本来 就不需要

xx
在最后的修改，我单独加了一个类，里面有个方法，在这里加了事务

xx
其他的都是查询判断，不需要加

xx
之前不是老报错说事务锁了

xx
后面改完就好了

test:
那个地方也有这个问题把

xx
当然和最后同步进erp，再修改mysql库存也有关

xx
同步这里也要改

xx
咋了，今天怎么问这个

xx
新项目需要？

test:
我昨天 看到个视频讲这个问题

test:
我就突然想起来

test:
我们以前也遇到

test:
就和你谈论一下
Spring事务失效的场景还有几点如下:
1. 非public修饰
2. final修饰也会失效, 动态代理需要重写方法才能生效事务, final修饰则无法重写
3. static修饰也会失效
4. 吞了异常, catch住没有抛给spring
5. 抛了错误的异常, catch住手动抛Exception则不会回滚, 因为spirng事务只会处理RuntimeException和Error