幂等设计的解决方案

幂等设计的解决方案：

  一、2个请求如何判断是幂等的？
     
     也就是说幂等号（可以是工单号、流水号等等唯一判断标识），是必须要有的，如果一个业务请求，是无法区分的，可重复的，那就没法做幂等。

     场景分析： 
      1、前端界面连续点击两次，如何确定幂等？
        如果接口参数，无法确定出一个幂等号，比如下单，需要到后端获取一个（后端生成，按业务）幂等号，前端点击的时候，带上幂等号，目的就是标记出2次请求，是重复的。
      2、请求超时、消息重复消费
            对于tcp重发请求、或者业务重试，只要能确定幂等号，都是一样的，没影响。
        对于消息队列的消息来讲，消息应该是要做唯一标识的，那就可以当作幂等号了。

   二、方案分析

      1、根据幂等号做防重设计 （比如redis）
            这里要注意几个点：
           （1）不要做可重入，只能执行一次，如果业务失败，宁愿不执行，让用户通过刷新，或者重进，去解决。（bug的话就另外说了，赶紧改bug）
            不做业务，比业务执行多次，好处理的多，损失更小。 一个业务接口本身就是要考虑到没执行成功，会怎么样，没有说代码是100%不出错的。
                2）防重要与业务解耦，减少侵入性，业务本身的事务、代码都不要变。
  
            针对幂等问题，做的防重设计参考下面的文章（都有具体代码实现）：
          https://www.jianshu.com/p/5b7f1fe26711
              https://baijiahao.baidu.com/s?id=1700016323820775953&wfr=spider&for=pc

            还有针对回放攻击，做的防重设计，会有少许区别：

            SpringBoot 如何保证接口安全？
                回放攻击：属于安全类问题 使用的是随机号+时间戳   防重代码一般放在网关。
            幂等问题：属于业务问题   使用的是幂等号  一般使用框架注解，代码放在自身业务测

      2、 自己业务判断
            比如先select，根据数据判断，再处理业务，这里就引出了并发问题，就有各种锁的判断，一般采用分布式锁。
        
        
      3、数据库设计
            一般是要设计主键或者唯一索引。
 

如果觉得该文章对您有用，可以打赏个几毛。

   https://doc-business-center-prod.oss-cn-shenzhen.aliyuncs.com/noticetoutu/sit/skm.jpg