高并发幂等性

<h1>高并发如何保证幂等性</h1> <h2>1 什么是幂等性？</h2> <p>幂等概念来自数学，表示N次变换和1次变换的结果是相同的。在某些场景下，客户端在调用服务没有达到预期结 果时，会进行多次调用，为避免多次重复的调用对服务资源产生副作用，服务提供者会承诺满足幂等。</p> <p>HTTP/1.1中对幂等性的定义是：一次和多次请求某一个资源对于资源本身应该具有同样的副作用（网络超时等问 题除外）。也就是说，其任意多次执行对资源本身所产生的影响均与一次执行的影响相同。</p> <p>这里需要关注几个重点：</p> <ol> <li>幂等不仅仅只是一次（或多次）请求对资源没有副作用（比如查询数据库操作，没有增删改，因此没有对数据 库有任何影响）。</li> <li>幂等还包括第一次请求的时候对资源产生了副作用，但是以后的多次请求都不会再对资源产生副作用。</li> <li>幂等关注的是以后的多次请求是否对资源产生的副作用，而不关注结果。</li> <li>网络超时等问题，不是幂等的讨论范围.</li> </ol> <p>幂等性是系统服务对外一种承诺（而不是实现），承诺只要调用接口成功，外部多次调用对系统的影响是一致的。 声明为幂等的服务会认为外部调用失败是常态，并且失败之后必然会有重试。</p> <h2>2 什么情况下需要幂等？</h2> <p>业务开发中，经常会遇到重复提交的情况，无论是由于网络问题无法收到请求结果而重新发起请求，或是前端的 操作抖动而造成重复提交情况。</p> <p>在交易系统，支付系统这种重复提交造成的问题有尤其明显，比如：</p> <ol> <li>用户在APP上连续点击了多次提交订单，后台应该只产生一个订单；</li> <li>向支付宝发起支付请求，由于网络问题或系统BUG重发，支付宝应该只扣一次钱。</li> </ol> <p>很显然，声明幂等的服务认为，外部调用者会存在多次调用的情况，为了防止外部多次调用对系统数据状态的发生 多次改变，将服务设计成幂等。</p> <h2>3 为什么要设计幂等性的服务？</h2> <p>幂等可以使得客户端逻辑处理变得简单，但是却以服务逻辑变得复杂为代价。满足幂等服务的需要在逻辑中至少 包含两点：</p> <ol> <li>首先去查询上一次的执行状态，如果没有则认为是第一次请求</li> <li>在服务改变状态的业务逻辑前，保证防重复提交的逻辑</li> </ol> <h2>4 幂等的不足</h2> <p>幂等是为了简化客户端逻辑处理，却增加了服务提供者的逻辑和成本，是否有必要，需要根据具体场景具体分析， 因此除了业务上的特殊要求外，尽量不提供幂等的接口。</p> <ol> <li>增加了额外控制幂等的业务逻辑，复杂化了业务功能；</li> <li>把并行执行的功能改为串行执行，降低了执行效率。</li> </ol> <h2>5 保证幂等的策略</h2> <p>幂等需要通过唯一的业务单号来保证。也就是说相同的业务单号，认为是同一笔业务。使用这个唯一的业务单号 来确保，后面多次的相同的业务单号的处理逻辑和执行效果是一致的。 下面以支付为例，在不考虑并发的情况下，实现幂等很简单：</p> <ol> <li>先查询一下订单是否已经支付过，</li> <li>如果已经支付过，则返回支付成功；如果没有支付，进行支付流程，修改订单状态为‘已支付’。</li> </ol> <p>上面保证幂等是分两步的，在多线程情况下，无法保证原子性、幂等从而将不能保证，所以可以将①②步加锁， 将并行操作改为串行操作，这样就可以保证幂等性。</p>