项目场景：

例如：一个user表，里面有个字段名称是account_money（账户金额）。
现在的操作是，先查询这个表中账户余额多少，再加上前端传来的金额，最后更新到表中。

---

问题描述

Redis分布式锁失效

加锁{
	查表
	取值
	更新
}
释放锁

---

原因分析：

高并发情况下，数据库事务未提交，但是分布式锁已经释放，导致第二次查询到的数据还是未更新前的数据。

以线程A和B为例：

1. 线程A得到锁，
2. 线程A查看user表得到账户余额，,
3. 线程A加上前端传来的余额,
4. 线程A更新数据库。
   • 开启事务
   • 执行更新语句（注意此时程序顺序执行释放锁，线程B获取锁）
     • 线程B获取锁，
     • 查询user表获得未更新前的账户余额，
   • 提交事务
5. 线程B加上前端传来的余额,
6. 线程B更新数据库。

总结：锁没起到我们想要的效果导致“失效”。

---

解决方案：

1. 手动提交事务。既然是由事务提交慢了导致的，我们可以手动提交事务。
   可供参考：https://www.jianshu.com/p/f39ae0c34a85
2. 分布式锁中重逻辑。在不手动提交事务的情况下，为避免脏读，我们可以让分布式锁中的逻辑变重。试想一下，在线程B获取锁之后，并不立即执行查user表的操作，而是先进行参数校验，或者查询其它表，这就给了线程A事务提交的缓冲时间，从而避免了脏读。
3. 组内一个大佬说spring事务的嵌套提交方式也可以避免这种情况的发生。
   具体实现是，将查表更新表的操作单独封装成一个方法（在事务外面加锁）。然后加上spring事务（嵌套提交）。

@Transactional(propagation = Propagation.NESTED)

可供参考：
Spring事务的七种传播方式:https://blog.csdn.net/t_t2_3/article/details/114548914
Redis分布式锁三种失效场景分析:https://blog.csdn.net/ZDK_csdn/article/details/122487945