小猿最近很苦恼：明明加了分布式锁，为什么并发还是会出问题呢？
故事从接到需求开始说起。
小猿前一阵接到一个小任务，里面有一个功能对应的场景如下：
注：实际业务场景比较复杂，已做简化。
小猿略作思考，就抓住了关键点：余额操作——要注意事务，多实例——要注意并发。
小猿的原始代码如下：
@Override@Lock(key = "#accountNo")@Transactional(rollbackFor = Exception.class)public void updateBalance(String accountNo, AmountOperateParam param) { // do something}可以看到，这个方法上通过注解方式加了分布式锁和事务，锁的 key 是 accountNo，也就是账户业务主键。
自测和测试也没发现啥问题，就高高兴兴发完版回家了。
第二天一早，就接到少量用户反馈，说自己的账户余额不对了。
小猿的第一反应是：我这块自测和测试都没问题，其它功能导致的吧？本地又是一通自测，也没有复现问题。但谨慎起见，还是往代码里加了一些日志，来确认是不是自己的方法引发的。
当又有用户反馈时，小猿根据日志的情况确认了：还真是自己方法的问题，对同一个账户的余额操作，多个并发请求会同时执行到方法体里面。
也就是说……分布式锁没锁住？
冥思苦想了好久，又在本地做了大量的测试，终于让小猿找到了问题所在：AOP 执行顺序问题。
小猿设计的时序：
但实际的时序：
也就是说期望是这样的执行顺序：
但实际的执行顺序：
分布式锁和事务，都是通过 AOP 来实现的，而 AOP 的执行顺序是根据切面的优先级来的，而小猿的分布式锁切面的优先级比事务切面的优先级低，所以就出现了上面的时序问题。
于是通过给分布式锁的切面指定 Order 的方式，让它的优先级高于事务切面（注：Order 值越小，执行优先级越高），验证完没问题后，就又高高兴兴地更新完版本，修复好历史问题数据后回家了。
谁知道第二天一早，还是有极少量的用户反馈账户余额不对的问题。
这次小猿就有点懵了，为什么还会出现这种情况呢？
经过一番艰苦卓绝的排查，终于找到了问题所在：事务嵌套。
从前文中的示例代码中可以看到，小猿的方法上加了事务注解 @Transactional(rollbackFor = Exception.class) 里，没有指定事务的传播行为，默认是 Propagation.REQUIRED，也就是说如果当前没有事务，就新建一个事务；如果当前有事务，就加入到当前事务中。
小猿自己写的代码里没有在事务方法里嵌套调用这个方法的情况，但是同事写的代码里有，这样就会导致前文的时序问题再次发生。
找到问题就好办了，小猿将自己的方法上的事务传播行为改成了 Propagation.REQUIRES_NEW，也就是说如果当前没有事务，就新建一个事务；如果当前有事务，就将当前事务挂起，新建一个事务。
这次更新完版本后，小猿就再也没有收到用户反馈了，终于可以安心回家睡觉了。
在日常的开发过程中，如果涉及到并发和事务，一定要多留几个心眼，考虑周全，确认以下要点是否都正确实现：
本文链接：http://www.28at.com/showinfo-26-11218-0.html后端｜一个分布式锁「失效」的案例分析
声明：本网页内容旨在传播知识，若有侵权等问题请及时与本网联系，我们将在第一时间删除处理。邮件：2376512515@qq.com
Copyright © 2016-2023 天津谷骐科技有限公司 版权所有 sitemap.xml
违法及侵权请联系：2376512515@qq.com 津ICP备18001702号
津公网安备 12010102000574号
