之前 那个订单 哪里 不是加了分布式锁 锁不住吗,你后来是怎么改的
表设计是 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