分布式系统中的幂等性

现如今我们的系统大多拆分为分布式SOA，或者微服务，一套系统中包含了多个子系统服务，而一个子系统服务往往会去调用另一个服务，而服务调用服务无非就是使用RPC通信或者restful，既然是通信，那么就有可能再服务器处理完毕后返回结果的时候挂掉，这个时候用户端发现很久没有反应，那么就会多次点击按钮，这样请求有多次，那么处理数据的结果是否要统一呢？那是肯定的！尤其再支付场景。

 

幂等性：就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用。举个最简单的例子，那就是支付，用户购买商品使用约支付，支付扣款成功，但是返回结果的时候网络异常，此时钱已经扣了，用户再次点击按钮，此时会进行第二次扣款，返回结果成功，用户查询余额返发现多扣钱了，流水记录也变成了两条．．．

 

在以前的单应用系统中，我们只需要把数据操作放入事务中即可，发生错误立即回滚，但是再响应客户端的时候也有可能出现网络中断或者异常等等。

 

在增删改查4个操作中，尤为注意就是增加或者修改，

查询对于结果是不会有改变的，

删除只会进行一次，用户多次点击产生的结果一样

修改在大多场景下结果一样

增加在重复提交的场景下会出现

 

那么如何设计接口才能做到幂等呢？

方法一、单次支付请求，也就是直接支付了，不需要额外的数据库操作了，这个时候发起异步请求创建一个唯一的ticketId，就是门票，这张门票只能使用一次就作废，具体步骤如下：

1. 异步请求获取门票

2. 调用支付，传入门票

3. 根据门票ID查询此次操作是否存在，如果存在则表示该操作已经执行过，直接返回结果；如果不存在，支付扣款，保存结果

4. 返回结果到客户端

如果步骤4通信失败，用户再次发起请求，那么最终结果还是一样的

 

方法二、分布式环境下各个服务相互调用

这边就要举例我们的系统了，我们支付的时候先要扣款，然后更新订单，这个地方就涉及到了订单服务以及支付服务了。

用户调用支付，扣款成功后，更新对应订单状态，然后再保存流水。

而在这个地方就没必要使用门票ticketId了，因为会比较闲的麻烦

（支付状态：未支付，已支付）

步骤：

1、查询订单支付状态

2、如果已经支付，直接返回结果

3、如果未支付，则支付扣款并且保存流水

4、返回支付结果

如果步骤4通信失败，用户再次发起请求，那么最终结果还是一样的

对于做过支付的朋友，幂等，也可以称之为冲正，保证客户端与服务端的交易一致性，避免多次扣款。

2、什么是幂等性

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

3、幂等性设计

幂等性一般应用于协议设计，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充值这个函数，可能在另一个进程中，那么整个业务的链路就会更长，可能回调成功了，但是充值失败。同理，只要充值接口保证幂等性，对于已经回调过但是充值结果未返回的请求，回调接收程序，应当重复发起充值请求。更深入更复杂的应用场景，在数据一致性中再细讲。

http协议的幂等性定义
本文所要探讨的正是HTTP协议涉及到的一种重要性质：幂等性(Idempotence)。在HTTP/1.1规范中幂等性的定义是：


Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request.

从定义上看，HTTP方法的幂等性是指一次和多次请求某一个资源应该具有同样的副作用。幂等性属于语义范畴，正如编译器只能帮助检查语法错误一样，HTTP规范也没有办法通过消息格式等语法手段来定义它，这可能是它不太受到重视的原因之一。但实际上，幂等性是分布式系统设计中十分重要的概念，而HTTP的分布式本质也决定了它在HTTP中具有重要地位。

分布式事务 vs 幂等设计

为什么需要幂等性呢？我们先从一个例子说起，假设有一个从账户取钱的远程API（可以是HTTP的，也可以不是），我们暂时用类函数的方式记为：

bool withdraw(account_id, amount)

withdraw的语义是从account_id对应的账户中扣除amount数额的钱；如果扣除成功则返回true，账户余额减少amount；如果扣除失败则返回false，账户余额不变。值得注意的是：和本地环境相比，我们不能轻易假设分布式环境的可靠性。一种典型的情况是withdraw请求已经被服务器端正确处理，但服务器端的返回结果由于网络等原因被掉丢了，导致客户端无法得知处理结果。如果是在网页上，一些不恰当的设计可能会使用户认为上一次操作失败了，然后刷新页面，这就导致了withdraw被调用两次，账户也被多扣了一次钱。如图1所示：

图1

这个问题的解决方案一是采用分布式事务，通过引入支持分布式事务的中间件来保证withdraw功能的事务性。分布式事务的优点是对于调用者很简单，复杂性都交给了中间件来管理。缺点则是一方面架构太重量级，容易被绑在特定的中间件上，不利于异构系统的集成；另一方面分布式事务虽然能保证事务的ACID性质，而但却无法提供性能和可用性的保证。

另一种更轻量级的解决方案是幂等设计。我们可以通过一些技巧把withdraw变成幂等的，比如：

int create_ticket() 
bool idempotent_withdraw(ticket_id, account_id, amount)

create_ticket的语义是获取一个服务器端生成的唯一的处理号ticket_id，它将用于标识后续的操作。idempotent_withdraw和withdraw的区别在于关联了一个ticket_id，一个ticket_id表示的操作至多只会被处理一次，每次调用都将返回第一次调用时的处理结果。这样，idempotent_withdraw就符合幂等性了，客户端就可以放心地多次调用。

基于幂等性的解决方案中一个完整的取钱流程被分解成了两个步骤：1.调用create_ticket()获取ticket_id；2.调用idempotent_withdraw(ticket_id, account_id, amount)。虽然create_ticket不是幂等的，但在这种设计下，它对系统状态的影响可以忽略，加上idempotent_withdraw是幂等的，所以任何一步由于网络等原因失败或超时，客户端都可以重试，直到获得结果。如图2所示：

图2

和分布式事务相比，幂等设计的优势在于它的轻量级，容易适应异构环境，以及性能和可用性方面。在某些性能要求比较高的应用，幂等设计往往是唯一的选择。