高并发重复请求的去重处理（转）

小灰灰 2022-06-08 12:27 230阅读 0赞

最近碰到一个重复提交请求，并能在数据库重复插入多条同样数据的问题。因为需求涉及到的是给用户发放购物卡，直接关系到的是金钱，所以是影响很大的一个问题，比如给一个用户发放100元一次，结果被某些居心不良之人抓到包，直接复制一百个请求，然后在执行就相当于给用户直接发放100元100次了，后果可想而知是非常严重的，所以必须的赶紧解决。

问题还原：在页面点击购物卡审核通过按钮，然后利用抓包工具抓到相应的请求，并复制请求N份，然后继续执行，这时数据库中会保存为每个userid发放了N份购物卡。

问题分析：对于这种问题，第一反应就是在数据库中加入一个唯一索引，这样就算重复请求N次，有唯一索引控制，结果也只会插入一条数据；并且购物卡发放也确实是有个购物卡批次号ID，这个ID针对每次发放来说都是一个唯一ID。但是在存入购物卡发放的record表中时，需求设计的是一个购物卡批次号中的一个userid可以对应多记录，因为购物卡面值最大100，如果一次性发放1000的话那就要一次性插入十条记录。所以加唯一索引的这条道不通。当然也考虑过加入一个字段，然后把这个字段设为唯一索引，但是现在系统已经迭代了多个版本，这里加一个字段，系统其它很多地方也需求跟着修改并需要重新测试，所以加字段也暂不考虑。

既然这两种方式都不通，那就只能针对具体业务流程去进行具体分析了。因为涉及代码安全性，这里贴出主要业务流程的伪代码，这个业务逻辑主要在service层中进行处理的，service层的方法如下：

public void addcardservice(record r)\{

//新增审批记录,此处操作的是审批表

addcardaudit（）；

。。。

//发放购物卡，此处操作的购物卡发放表record

addcardrecord();

。。。

//修改购物卡状态,此处操作的是card表

updatecard();

针对如上业务流程，因为record是允许插入多条重复记录的，并且在购物卡record发放成功后，我们会去把card表的状态改为审批通过，既state改为3.所以这里想到的一个方法就是对card表加一个乐观锁，提前把card表的状态改审批通过，既state改为3，如果改成功了我们就进行购物record的发放，因为加了乐观锁，所以会保证只能有一条记录被更新为state=3，其余的update全都返回false，所以也就无法进行购物卡的发放了，修改后的伪代码如下：

public void addcardservice(record r)\{

//新增审批记录,此处操作的是审批表

addcardaudit（）；

。。。

//修改购物卡状态,此处操作的是card表

boolean flag = updatecard();

(update card set state=3 where id=\#id\# and state!=3)

。。。

if(falg == true)\{

//发放购物卡，此处操作的购物卡发放表record

addcardrecord();

在修改card表处的update语句，我做了一点修改，既只有当状态不为3时（既状态为审核不通过时）才能update成功，如果状态为3了那么这条语句就永远也不能修改成功了，所以通过这种乐观锁机制，保证了update永远只有一个请求会update成功，然后成功了的请求才会继续发放购物卡，这样就保证了即使有多个重复请求过来也不会有多条重复记录产生。可能还会有个疑问，如果card表修改成功，在发放购物卡record表的操作时失败了，那状态就不一致了，其实这个也不用当心，我们整个业务逻辑都是在service层进行操作的，在service层我们有spring做了事务控制，所以即使操作record表时有了异常，也会整个一起回滚。

做到这里貌似整个方案都完美解决这个问题，并且不用加字段也不用加唯一索引。但是问题并没解决，如果在并发量不大的情况下，这个确实是解决了，但经过压力测试，当并发量较大时，还是会出现两条以上的重复记录，虽然比之前的重复数据少了很多，但是重复数据还是存在。经分析，原因是当足够多的并发量请求一起过来时，如果当两个请求同时进入service层的方法，并同时开启了事务，那么这两个事务看到的数据是一致，也就是两个事务看到card表的state的值都不为3，并且在事务中，其中一个请求update成功后，必须在事务结束时才会提交update的数据，所以其他请求还是会看到state的值为3，并且在高并发情况下还是会产生多条重复数据的情况，虽然重复数据少了很多，但还是存在，所以问题并没解决。碰到这种情况，我们可以在做进一步的处理，如下所示

public void addcardservice(record r)\{

//此处增加行级锁

getcardlock();

(select \* from card where id=\#id\# for update)

//新增审批记录,此处操作的是审批表

addcardaudit（）；

。。。

//修改购物卡状态,此处操作的是card表

boolean flag = updatecard();

(update card set state=3 where id=\#id\# and state!=3)

。。。

if(falg == true)\{

//发放购物卡，此处操作的购物卡发放表record

addcardrecord();

以上处理的逻辑是在进入service层方法时，因为对于card的update操作，我们都是对于其中的一条数据进行update，所以我们可以在事务开启时用for update的方式，增加一个行级锁，这样就算后面同时并发了再多了请求，但锁只有一个，当第一个请求获取到锁时，其他同时并发过来的请求只能处于等待状态。然后在用下面的乐观锁进行card表的update操作，这样就可以从理论上避免了高并发下重复请求提交处理的问题。

最后如果当有一万的并发请求过来时，当第一个请求获得锁在处理业务时，可能其他9999个请求都出于阻塞状态，这样对于服务器来说也是比较损耗资源的，对于这种情况，可以采取下面这种方式进行优化

private Vector<String> uniqeShopcardIds = new Vector<String>(1000);

if(!uniqeShopcardIds.contains(cardid))\{  
                                  uniqeShopcardIds.add(String.valueOf(cardid));  
                                  if(uniqeShopcardIds.size()>500)\{  
                                      uniqeShopcardIds.clear();  
                                  \}  
                            \}

我们在进入service层方法的外层，controller的方法中加入以上代码，因为进入controller中的购物卡批次号是唯一的，虽然有重复请求，我们只需处理一次就足够了，所以用上方法把购物卡批次号存入vector对象中进行重复判断,其中uniqeShopcardIds为全局变量，这样可以过滤掉大部分的请求，从而减少service层中的并发量，也减轻了服务器的压力。

到此关于这个高并发下重复请求处理的问题差不多就完全解决了。暂时先写到这，记录下这个问题的解决方法，留个纪念。![微笑][smile.gif]

原文地址：[http://blog.csdn.net/cz\_111/article/details/52785568][http_blog.csdn.net_cz_111_article_details_52785568]

下面是自己补充的知识：  
mysql里面有**共享锁**和**排他锁**。  
上面的例子是使用到了排他锁  
排他锁用法：  
SELECT … FOR UPDATE;  
MySQL会对查询结果集中每行都添加排他锁，在事物操作中，任何对记录的更新与删除操作会自动加上排他锁。

共享锁的用法： SELECT … LOCK IN SHARE MODE;  
MySQL会对查询结果集中每行都添加共享锁。

[smile.gif]: /images/20220608/b152135d9b1b45a892468832bad7be7d.png
[http_blog.csdn.net_cz_111_article_details_52785568]: http://blog.csdn.net/cz_111/article/details/52785568