软件系统的幂等性控制

什么是幂等性

幂等性应用在软件系统中，我把它简单定义为：某个函数或者某个接口使用相同参数调用一次或者无限次，其造成的后果是一样的，在实际应用中一般针对于接口进行幂等性设计。举个栗子，在系统中，调用方A调用系统B的接口进行用户的扣费操作时，由于网络不稳定，A重试了N次该请求，那么不管B是否接收到多少次请求，都应该保证只会扣除该用户一次费用。

幂等性设计

幂等性一般应用于协议设计，TCP协议支持幂等吗?答案是肯定的，在网络不稳定时，操作系统可以肆无忌惮的重发TCP报文片段。TCP协议能够保证幂等的核心在于sequence number字段，一个序列号的在较长的一段时间内均不会出现重复。对于应用层的协议设计，原理和TCP是类似的，我们需要一个不重复的序列号。再简单一点说，在一个业务流程的处理中，我们需要一个不重复的业务流水号，以保证幂等性。

举个实际应用场景：用户A在网页上发起一笔游戏充值请求，浏览器引导用户去银行支付，支付成功后系统给用户进行充值。

协议设计上，我们通过全局唯一的充值订单号贯穿整个业务流程，使该业务支持幂等。

应用实现上，我们列举在银行支付成功后回调系统，进行充值的步骤进行说明。

 

[plain]  view plain  copy

 

1. func pay_notify(orderid,value,state){//有问题的实现  
2.          order = db.query("select * from payorder where orderid=$orderid");  
3.          check(order,orderid,value,state);//判断支付金额是否与订单金额一致，判断是否是支付成功回调。  
4.          if(order.state=='未支付'）{  
5.             db.update("update payorder set state='已支付' where orderid=$orderid");  
6.             charge(order.username,value);//执行充值  
7.          }else{  
8.          return result("订单已处理")//返回订单已处理，或者返回处理成功  
9.         }  
10.     }  

上述实现的问题在于，当回调出现并发时，order.state已经是脏读了，有可能重复充值，该实现并不能100%保证幂等。

列举三种改进方式：

1、悲观锁，select for update，整个执行过程中锁定该订单对应的记录。

2、乐观锁，affectrows = db.update("update payorder set state='已支付' where orderid=$orderid and state='未支付' ")，如果affectrows=1，执行充值，否则返回已处理。

3、定义notifylog表，orderid为unique key或者primary key，执行前，先insert，若insert成功则执行充值，否则返回已处理。

以上简单例子用以说明幂等性常用应用实现，在SOA化系统中，可能很多原子功能都被拆分到不同的进程里，如charge充值这个函数，可能在另一个进程中，那么整个业务的链路就会更长，可能回调成功了，但是充值失败。同理，只要充值接口保证幂等性，对于已经回调过但是充值结果未返回的请求，回调接收程序，应当重复发起充值请求。更深入更复杂的应用场景，在数据一致性中再细讲。

 

总结

业务层设计协议时，要求请求方定义不重复的业务流水号。应用实现时，利用数据库乐观锁、插入unique key的日志等方式保证并发时的幂等。

幂等性把关环节，在协议设计评审中，评审重要业务RPC或者http接口是否支持幂等，代码评审中，重点把关请求并发时，是否仍旧能够保证幂等性。设计人员和具体实现人员在实现过程中，也应该时刻自审幂等性的实现是否过关。

-----------------------------------------------------

补充：

为啥要做幂等呢？

原因很简单，在系统调用没有达到期望的结果后，会重试。那重试就会面临问题，重试之后不能给业务逻辑带来影响，例如创建订单，第一次调用超时了，但是调用的系统不知道超时了是成功了还是失败了，然后他就重试，但是实际上第一次调用订单创建是成功了的，这时候重试了，显然不能再创建订单了。

查询

查询的API，可以说是天然的幂等性，因为你查询一次和查询两次，对于系统来讲，没有任何数据的变更，所以，查询一次和查询多次一样的。

删除数据

删除数据，仅仅第一次删除是真正的操作数据，第二次甚至第三次删除，直接返回成功，这样保证了幂等。

MVCC方案

多版本并发控制（Multiversion concurrency control，MVCC）。人们一般把基于锁的并发控制机称成为悲观机制，而把MVCC等机制称为乐观机制。这是因为锁机制是一种预防性的，读会阻塞写，写也会阻塞读，当锁定粒度较大，时间较长是并发性能就不会太好；而MVCC是一种后验性的，读不阻塞写，写也不阻塞读，等到提交的时候才检验是否有冲突，由于没有锁，所以读写不会相互阻塞，从而大大提升了并发性能。

MVCC的一种简单实现是基于CAS（Compare-and-swap）思想的有条件更新（Conditional Update）。这也是在系统设计的时候，合理的选择乐观锁，通过version或者其他条件，来做乐观锁，这样保证更新即使在并发的情况下，也不会有太大的问题。例如update table_xxx set name=#name#,version=version+1 where version=#version# ,或者是 update table_xxx set quality=quality-#subQuality# where quality-#subQuality# >= 0 。

 单独的去重表

如果涉及到的去重的地方特别多，例如ERP系统中有各种各样的业务单据，每一种业务单据都需要去重，这时候，可以单独搞一张去重表，在插入数据的时候，插入去重表，利用数据库的唯一索引特性，保证唯一的逻辑。

 

插入数据的唯一索引

插入数据的唯一性，可以通过业务主键来进行约束，例如一个特定的业务场景，三个字段肯定确定唯一性，那么，可以在数据库表添加唯一索引来进行标示。

 

API层面的幂等

这里有一个场景，API层面的幂等，例如提交数据，如何控制重复提交，这里可以在提交数据的form表单或者客户端软件，增加一个唯一标示，然后服务端，根据这个UUID来进行去重，这样就能比较好的做到API层面的唯一标示。

 

状态机幂等

在设计单据相关的业务，或者是任务相关的业务，肯定会涉及到状态机，就是业务单据上面有个状态，状态在不同的情况下会发生变更，一般情况下存在有限状态机，这时候，如果状态机已经处于下一个状态，这时候来了一个上一个状态的变更，理论上是不能够变更的，这样的话，保证了有限状态机的幂等。

 

分布式锁

还是拿插入数据的例子，如果是分布式系统，构建唯一索引比较困难，例如唯一性的字段没法确定，这时候可以引入分布式锁，通过第三方的系统，在业务系统插入数据或者更新数据，获取分布式锁，然后做操作，之后释放锁，这样其实是把多线程并发的锁的思路，引入多多个系统，也就是分布式系统中得解决思路。