一种简单通用的重复提交解决方案

     对于重复提交，想到的最简单的方案就是该方法保证幂等性，所谓幂等性就是F(F(x))=F(x)多次运算结果都是一致的。比如对于innodb存储引擎，RR级别以上的select查询就天然具有幂等性。

     首先重复提交的原因有许多，比如恶意的重复提交，网络重发，分布式RPC的try重发，nginx重发等情况等等。

     下面给一个网络重发的案例。 

10.175.55.64
118.178.88.205 - - [24/Feb/2021:18:12:37 +0800] "118.178.88.205" "118.178.88.205" "GET /mshop/individual/page/createPolicy?callback=jQuery11240578362957500157_1614161390262&userGroup=646124&projectId=6478115&_uid_=161416154963624752277&_=1614161390263 HTTP/1.1" 200 556 "https://jshopx.jd.com/" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.96 Safari/537.36" "-" 0.071 0.071

11.40.53.231
118.178.88.205 - - [24/Feb/2021:18:12:37 +0800] "118.178.88.205" "118.178.88.205" "GET /mshop/individual/page/createPolicy?callback=jQuery11240578362957500157_1614161390264&userGroup=646124&projectId=6478115&_uid_=161416155223623249319&_=1614161390265 HTTP/1.1" 200 550 "https://jshopx.jd.com/" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.96 Safari/537.36" "-" 0.056 0.055

10.172.15.38
118.178.88.205 - - [24/Feb/2021:18:12:37 +0800] "118.178.88.205" "118.178.88.205" "GET /mshop/individual/page/createPolicy?callback=jQuery11240578362957500157_1614161390266&userGroup=646124&projectId=6478115&_uid_=161416155280355422432&_=1614161390267 HTTP/1.1" 200 556 "https://jshopx.jd.com/" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.96 Safari/537.36" "-" 0.053 0.053

function(args****)  {     1、是否存在值     2、如果存在，retrun                              3、插入判断的逻辑 }

后者代码，其实无论如何处理。都存在重复数据的问题。查询时用for update,又会牺牲一定的性能，甚至造成死锁

  那么重复提交的解决方案是什么呢？

   先说说目前存在的方案：

•  前端方案

       前端方案可以用一些js组件禁止恶意的用户层面重复提交，或者借助session，cookie，甚至http的Header头设置缓存控制等等方案。虽然方案较多，但都不彻底，特别是对于网络波动导致的重发，RPC层面的重试导致的重复提交毫无还手之力。

• 后端方案

1.  借助数据库：如对于insert使用唯一索引，update使用乐观锁version版本法。这里只说缺点：首先这种方法都需要熟悉业务，并不是每种方法都满足唯一索引等的约束。最为重要的是在海量数量和高并发效率下依赖数据库硬件来保证并不是十分可取的方法。（当然，如果业务本身满足唯一索引等约束场景，在create table时就需要设计好）
2. 借助悲观锁：可能最常想到的方法就是使用select * for update，甚至整个方法synchronized。对于前者，很容易出现死锁（类似的案例见：一个普通的死锁案例）；后者当然效率就更差劲了。当然，针对于请求并发不大，想分析分析死锁，也是值得推荐大家使用的。
3. 当然还有许多其他方案，这里就不在累述了

---

      下面介绍一种非常轻量级的方法

      借助于redis分布式锁实现的只需要三步就可以解决重复提交的引起的问题。核心技术就是redis分布式锁和AOP，其他也没有啥好介绍的。

     第一步： 引入pom依赖

<dependency>
    <groupId>com.jd.jshop</groupId>
    <artifactId>jshop-common-client</artifactId>
    <version>0.0.1-SNAPSHOT</version>
</dependency>

     第二步：实例化reidsBean  

     com.jd.jshop.common.client.lock.DistributedLockAop 

     第三步：添加注解RedisLock

  @RedisLock(businessKey={"0:a1000", "1:b10000", "2:{A1.aa,A1.bb,A1.bbbbb}"}, action= RedisLock.LockFailAction.CONTINUE, expires = 6000, timeout = 6000)
    其中，businessKey为自定义的业务key，用于表示这些key的组合在expires是操作应该是唯一的 

           action: 表示失败后的逻辑处理

           expires:锁定的时间

           timeout：业务不允许的重复执行最大值timeout

    分布式锁的实现需要注意以下问题：

1. 确保只能释放自己的锁，确保锁可重入性
2. 避免锁超时当前线程挂掉，其他线程获取不到锁的场景
3. 原子性：当通过setNx设置锁时，最好设置锁自动过期时间以预防死锁存在的隐患；确保加锁与释放锁的原子性：redis支持Lua脚本并保证其原子性
4. redis节点故障后，主备切换的数据一致性：由于主从同步具有延迟性，在主节点故障后可能导致同一资源的锁被多个客户端持有。解决思路参考RedLock的分布式一致性算法。当然这要消耗一定的时间来保证锁的正确获取。
5. 时钟漂移问题：由于锁的过期时间依赖于服务器时间，而服务器时间可能发生跳跃，所以会存在多个客户端同时获取到锁的情况发生——这个问题在实际中我暂时没有考虑，目前RedLock也并没有完全解决该问题。

 

        当然，如果业务中的数据库中已经定义了唯一索引，就没有必要再去引用注解RedisLock。