Redis乐观锁解决高并发抢红包的问题

淡淡的烟草味﹌ 2024-02-23 08:01 27阅读 0赞

乐观锁是一种不会阻塞其他线程并发的机制，它不会使用数据库的锁进行实现，它的设计里面由于不阻塞其他线程，所以并不会引发线程频繁挂起和恢复，这样便能够提高并发能力，所以也有人把它称为非阻塞锁，那么它的机制是怎么样的呢？  
  
乐观锁使用的是 CAS 原理，所以我们先来讨论 CAS 原理的内容。

### CAS 原理概述 ###

在 CAS 原理中，对于多个线程共同的资源，先保存一个旧值（Old Value），比如进入线程后，查询当前存量为 100 个红包，那么先把旧值保存为 100，然后经过一定的逻辑处理。  
  
当需要扣减红包的时候，先比较数据库当前的值和旧值是否一致，如果一致则进行扣减红包的操作，否则就认为它已经被其他线程修改过了，不再进行操作，CAS 原理流程如图 1 所示。

![CAS原理][CAS]

图 1 CAS原理

CAS 原理并不排斥并发，也不独占资源，只是在线程开始阶段就读入线程共享数据，保存为旧值。当处理完逻辑，需要更新数据的时候，会进行一次比较，即比较各个线程当前共享的数据是否和旧值保持一致。  
  
如果一致，就开始更新数据；如果不一致，则认为该数据已经被其他线程修改了，那么就不再更新数据，可以考虑重试或者放弃。有时候可以重试，这样就是一个可重入锁，但是 CAS 原理会有一个问题，那就是 ABA 问题，下面先来讨论一下 ABA 问题。

### ABA 问题 ###

对于乐观锁而言，我们之前讨论了存在 ABA 的问题，那么什么是 ABA 问题呢？下面看看表 1 的两个线程发生的场景。

<table>  表 1 ABA问题  
 <tbody> 
  <tr> 
   <th>时 刻</th> 
   <th>线程1</th> 
   <th>线程2</th> 
   <th>备 注</th> 
  </tr> 
  <tr> 
   <td>T0</td> 
   <td>——</td> 
   <td>——</td> 
   <td>初始化 X=A</td> 
  </tr> 
  <tr> 
   <td>T1</td> 
   <td>读入X=A</td> 
   <td>——</td> 
   <td>——</td> 
  </tr> 
  <tr> 
   <td>T2</td> 
   <td>——</td> 
   <td>读入X=A</td> 
   <td>——</td> 
  </tr> 
  <tr> 
   <td>T3</td> 
   <td colspan="1">处理线程 1 的业务逻辑</td> 
   <td>X=B</td> 
   <td>修改共享变量为 B</td> 
  </tr> 
  <tr> 
   <td>T4</td> 
   <td>处理线程 2 业务逻辑第一段</td> 
   <td>此时线程1在 X=B 的情况下运行逻辑</td> 
  </tr> 
  <tr> 
   <td>T5</td> 
   <td>X=A</td> 
   <td>还原变量为 A</td> 
  </tr> 
  <tr> 
   <td>T6</td> 
   <td>因为判断 X=A，所以更新数据</td> 
   <td>处理线程 2 业务逻辑第二段</td> 
   <td>此时线程 1 无法知道线程 2 是否修改过 X，引发业务逻辑错误</td> 
  </tr> 
  <tr> 
   <td>T7</td> 
   <td>——</td> 
   <td>更新数据</td> 
   <td>——</td> 
  </tr> 
 </tbody> 
</table>

在 T3 时刻，由于线程 2 修改了 X=B，此时线程 1 的业务逻辑依旧执行，但是到了 T5 时刻，线程 2 又把 X 还原为 A，那么到了 T6 时刻，使用 CAS 原理的旧值判断，线程 1 就会认为 X 值没有被修改过，于是执行了更新。  
  
我们难以判定的是在 T4 时刻，线程 1 在 X=B 的时候，对于线程 1 的业务逻辑是否正确的问题。由于 X 在线程 2 中的值改变的过程为 A->B->A，才引发这样的问题，因此人们形象地把这类问题称为 ABA 问题。  
  
ABA 问题的发生，是因为业务逻辑存在回退的可能性。如果加入一个非业务逻辑的属性，比如在一个数据中加入版本号（version），对于版本号有一个约定，就是只要修改 X 变量的数据，强制版本号（version）只能递增，而不会回退，即使是其他业务数据回退，它也会递增，那么 ABA 问题就解决了，如表 2 所示。

<table>  
 <br> 表 2 用版本号消除 ABA 问题  
 <tbody> 
  <tr> 
   <th>时刻</th> 
   <th>线程1</th> 
   <th>线程2</th> 
   <th>备 注</th> 
  </tr> 
  <tr> 
   <td>T0</td> 
   <td>——</td> 
   <td>——</td> 
   <td>初始化 X=A，version=0</td> 
  </tr> 
  <tr> 
   <td>T1</td> 
   <td>读入X=A</td> 
   <td>——</td> 
   <td>线程1旧值：version=0</td> 
  </tr> 
  <tr> 
   <td>T2</td> 
   <td>——</td> 
   <td>读入X=A</td> 
   <td>线程2旧值：version=0</td> 
  </tr> 
  <tr> 
   <td>T3</td> 
   <td colspan="1">处理线程1的业务逻辑</td> 
   <td>X=B</td> 
   <td>修改共享变量为 B，version=1</td> 
  </tr> 
  <tr> 
   <td>T4</td> 
   <td>处理线程 2 业务逻辑第一段</td> 
   <td>——</td> 
  </tr> 
  <tr> 
   <td>T5</td> 
   <td>——</td> 
   <td>X=A</td> 
   <td>还原变量为A，version=2</td> 
  </tr> 
  <tr> 
   <td>T6</td> 
   <td>判断 version == 0，由于线程 2 两次更新数据，导致数据 version=2，所以不再更新数据&nbsp;</td> 
   <td>处理线程 2 业务逻辑第二段</td> 
   <td>此时线程 1 知道旧值 version 和当前 version 不一致，将不更新数据</td> 
  </tr> 
  <tr> 
   <td>T7</td> 
   <td>——</td> 
   <td>更新数据</td> 
   <td>——</td> 
  </tr> 
 </tbody> 
</table>

只是这个 version 变量并不存在什么业务逻辑，只是为了记录更新次数，只能递增，帮助我们克服 ABA 问题罢了，有了这些理论，我们就可以开始使用乐观锁来完成抢红包业务了。

### 乐观锁实现抢红包业务 ###

通过上述的讨论，我们清楚了 CAS 原理如何避免数据的不一致，如何规避 CAS 原理产生的 ABA 问题，在高并发的应用中使用 CAS 原理，我们称之为乐观锁。  
  
为了顺利使用乐观锁，需要先在红包表（T\_RED\_PACKET）加入一个新的列版本号（version），这个字段在建表的时候已经建了，只是我们还没有使用，那么在 UserRedPacket.xml 的代码中加入新的方法，代码如下所示。

<update id="decreaseRedPacketForVersion">  
update T\_RED\_PACKET  
set stock = stock - 1,  
**version = version + 1**  
where id = \#\{id\}  
**and version = \#\{version\}**  
</update>

注意加粗的代码，在扣减红包的时候，增加了对版本号的判断，其次每次扣减都会对版本号加一，这样保证每次更新在版本号上有记录，从而避免 ABA 问题。  
  
对于查询也不使用 for update 语句，避免锁的发生，这样就没有线程阻塞的问题了，这里在对应的 UserRedPacketDao 接口上加入对应方法，然后就可以在类 UserRedPacketServiceImpl 中新增方法 grapRedPacketForVersion（需要在其接口 UserRedPacketService 加上同样的方法），完成对应的逻辑即可，代码如下所示。

>     @Transactional(isolation = Isolation.READ_COMMITTED, propagation = Propagation.REQUIRED)
>     public int grapRedPacketForVersion(Long redPacketId, Long userId) {
>         // 获取红包信息，注意version值
>         RedPacket redPacket = redPacketDao.getRedPacket(redPacketId);
>         // 当前小红包库存大于0
>         if (redPacket.getstock() > 0) {
>             // 再次传入线程保存的version 旧值给SQL判断，是否有其他线程修改过数据
>             int update = redPacketDao.decreaseRedPacketForVersion(redPacketId,redPacket.getVersion());
>             // 如果没有数据更新，则说明其他线程已经修改过数据，本次抢红包失败
>             if (update == 0) {
>                 return FAILED;
>             }
>             // 生成抢红包信息
>             UserRedPacket userRedPacket = new UserRedPacket();
>             userRedPacket.setRedPacketId(redPacketId);
>             userRedPacket.setUserId(userId);
>             userRedPacket.setAmount(redPacket.getUnitAmount());
>             userRedPacket.setNote ("抢红包"+ redPacketId);
>             //插入抢红包信息
>             int result = userRedPacketDao.grapRedPacket(userRedPacket);
>                 return result;
>         }
>         //失败返回
>         return FAILED;
>     }

version 值一开始就保存到了对象中，当扣减的时候，再次传递给 SQL，让 SQL 对数据库的 version 和当前线程的旧值 version 进行比较。如果一致则插入抢红包的数据，否则就不进行操作。  
  
为了进行测试，在控制器 UserRedPacketController 内新建方法，代码如下所示。

>     @RequestMapping(value = "/grapRedPacketForVersion")
>     @ResponseBody
>     public Map<String, Object> grapRedPacketForVersion(Long redPacketId, Long userId) {
>         // 抢红包
>         int result = UserRedPacketService.grapRedPacketForVersion(redPacketId, userId);
>         Map<String, Object> retMap = new HashMap<String, Object>();
>         boolean flag = result > 0;
>         retMap.put("success", flag);
>         retMap.put("message", flag ? "抢红包成功" : "抢红包失败");
>         return retMap;
>     }

修改 test.jsp 的 [JSP][] 文件中 [JavaScript][] 的 POST 请求地址和红包，id 对应上新增控制器的方法，便可以进行测试，结果如图 2 所示。

![乐观锁测试结果][3c96e6fb81c0d2b6255d5c0eefea63bd.png]

图 2 乐观锁测试结果

从图 2 中我们看到，经过 3 万次的抢夺，还会存在大量的红包，也就是存在大量的因为版本不一致的原因造成抢红包失败的请求，不过这个失败率太高了一点。有时候会容忍这个失败，这取决于业务的需要，因为允许用户自己再发起抢夺红包，比如微信抢红包也常常发生错误返回。再次对性能进行测试，如图 3 所示。

![测试乐观锁性能][8223b415ca2eef9af969a5c17be0d0ae.png]

图 3 测试乐观锁性能

33 秒完成所有抢红包的功能，这个结果和不使用任何锁一样，但是还存在大量的红包因为版本并发的原因而没有被抢到，而且这个概率比较高，下面解决这个问题。  
  
为了克服这个问题，提高成功率，还会考虑使用重入机制。也就是一旦因为版本原因没有抢到红包，则重新尝试抢红包，但是过多的重入会造成大量的 SQL 执行，所以目前流行的重入会加入两种限制，一种是按时间戳的重入，也就是在一定时间戳内（比如说 100 毫秒），不成功的会循环到成功为止，直至超过时间戳，不成功才会退出，返回失败。  
  
另外一种是按次数，比如限定 3 次，程序尝试超过 3 次抢红包后，就判定请求失效，这样有助于提高用户抢红包的成功率，下面讨论如何重入。

### 乐观锁重入机制 ###

因为乐观锁造成大量更新失败的问题，使用时间戳执行乐观锁重入，是一种提高成功率的方法，比如考虑在 100 毫秒内允许重入，把 UserRedPacketServiceImpl 中的方法 grapRedPacketForVersion 修改为以下代码。

>     @Transactional(isolation = Isolation.READ_COMMITTED, propagation = Propagation.REQUIRED)
>     public int grapRedPacketForVersion(Long redPacketId, Long userId) {
>         // 记录开始时间
>         long start = System.currentTimeMillis();
>         // 无限循环，等待成功或者时间满100亳秒退岀
>         while (true) {
>             // 获取循环当前时间
>             long end = System.currentTimeMillis();
>             // 当前时间己经超过100毫秒，返回失败
>             if (end - start > 100) {
>                 return FAILED;
>             }
>             // 获取红包信息，注意version值
>             RedPacket redPacket = redPacketDao.getRedPacket(redPacketId);
>             // 当前小红包库存大于0
>             if (redPacket.getStock() > 0) {
>                 // 再次传入线程保存的version旧值给SQL判断，是否有其他线程修改过数据
>                 int update = redPacketDao.decreaseRedPacketForVersion(redPacketId, redPacket.getVersion());
>                 // 如果没有数据更新，则说明其他线程已经修改过数据，则重新抢夺
>                 if (update == 0) {
>                     continue;
>                 }
>                 // 生成抢红包信息
>                 UserRedPacket UserRedPacket = new UserRedPacket();
>                 UserRedPacket.setRedPacketId(redPacketId);
>                 UserRedPacket.setUserId(userId);
>                 UserRedPacket.setAmount(redPacket.getUnitAmount());
>                 UserRedPacket.setNote("抢红包" + redPacketId);
>                 // 插入抢红包信息
>                 int result = userRedPacketDao.grapRedPacket(UserRedPacket);
>                 return result;
>             } else {
>                 // 一旦没有库存，则马上返回
>                 return FAILED;
>             }
>         }
>     }

当因为版本号原因更新失败后，会重新尝试抢夺红包，但是会实现判断时间戳，如果时间戳在 100 毫秒内，就继续，否则就不再重新尝试，而判定失败，这样可以避免过多的 SQL 执行，维持系统稳定。乐观锁按时间戳重入，如图 4 所示。

![乐观锁按时间戳重入][ec83690e988372978f3b980f7eb840d6.png]

图 4 乐观锁按时间戳重入

从结果来看，之前大量失败的场景消失了，也没有超发现象，3 万次尝试抢光了所有的红包，避免了总是失败的结果，但是有时候时间戳并不是那么稳定，也会随着系统的空闲或者繁忙导致重试次数不一。  
  
有时候我们也会考虑限制重试次数，比如 3 次。下面再次改写 UserRedPacketServiceImpl 中的方法 grapRedPacketForVersion，代码如下所示。

>     @Transactional(isolation = Isolation.READ_COMMITTED, propagation = Propagation.REQUIRED)
>     public int grapRedPacketForVersion(Long redPacketId, Long userId) {
>         for (int i = 0; i < 3; i++) {
>             // 获取红包信息，注意version值
>             RedPacket redPacket = redPacketDao.getRedPacket(redPacketId);
>             // 当前小红包库存大于0
>             if (redPacket.getStock() > 0) {
>                 // 再次传入线程保存的version旧值给SQL判断，是否有其他线程修改过数据
>                 int update = redPacketDao.decreaseRedPacketForVersion(redPacketId, redPacket.getVersion());
>                 // 如果没有数据更新，则说明其他线程已经修改过数据，则重新抢夺
>                 if (update == 0) {
>                     continue;
>                 }
>                 // 生成抢红包信息
>                 UserRedPacket UserRedPacket = new UserRedPacket();
>                 UserRedPacket.setRedPacketId(redPacketId);
>                 UserRedPacket.setUserId(userId);
>                 UserRedPacket.setAmount(redPacket.getUnitAmount());
>                 UserRedPacket.setNote("抢红包" + redPacketId);
>                 // 插入抢红包信息
>                 int result = userRedPacketDao.grapRedPacket(UserRedPacket);
>                 return result;
>             } else {
>                 // 一旦没有库存，则马上返回
>                 return FAILED;
>             }
>         }
>         return FAILED;
>     }

通过 for 循环限定重试 3 次，3 次过后无论成败都会判定为失败而退出，这样就能避免过多的重试导致过多 SQL 被执行的问题，从而保证数据库的性能。为此笔者也进行了测试，如图 5 所示。

![乐观锁按重试次数重入][ed7a6ac3b6ce70e0a362e328e7670d93.png]

图 5 乐观锁按重试次数重入

显然效果很好，3 万次请求，所有红包都被抢到了，也没有发生超发现象，这样就可以消除大量的请求失败，避免非重入的时候大量请求失败的场景。  
  
但是现在是使用数据库的情况，有时候并不想使用数据库作为抢红包时刻的数据保存载体，而是选择性能优于数据库的 [Redis][]。  
  
之前我们学习过 Redis 事务，也学习过 Redis 的 Lua 语言，它是一种原子性的操作，为此我们将绕开数据库用 Redis 处理高并发的请求。

[CAS]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/23/255f175534804de9a48a6ea31c8910b9.png
[JSP]: http://www.voidme.com/jsp
[JavaScript]: http://www.voidme.com/js
[3c96e6fb81c0d2b6255d5c0eefea63bd.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/23/0c6e70ad08764fb28d242158967d7930.png
[8223b415ca2eef9af969a5c17be0d0ae.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/23/6445e026283e483886206d1dde0003e4.png
[ec83690e988372978f3b980f7eb840d6.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/23/0746bfaa10704c6c830ed1c60bcc3c79.png
[ed7a6ac3b6ce70e0a362e328e7670d93.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/23/636fc02db218473bbfc791d7c622e8cf.png
[Redis]: http://www.voidme.com/redis