程序幂等性设计

幂等的含义

一句话定义：一个操作如果任意多次执行所产生的结果与一次执行的结果相同，这个操作就是幂等的

在数学里，幂等有两种主要的定义：

1.在某二元运算下，幂等元素是指被自己重复运算的结果等于它自己的元素。例：乘法下两个幂等实数为0和1

2.某一元运算为幂等的时候，其作用在任意元素两次后会和其作用一次的结果相同。例：高斯符号

在编程中，一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。幂等函数或幂等方法，是指可以使用相同参数重复执行，并能获得相同结果的函数。这些函数不会影响系统状态，也不用担心重复执行会对系统造成改变。例：“setTrue()”,更复杂的操作幂等保证是利用唯一交易号（流水号）实现

为什么需要幂等性呢？

我们先从一个例子说起，假设有一个从账户取钱的远程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

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

如何保证幂等

在数据库增删改查四种操作中，查询和删除是天然幂等的，修改和增加不是幂等的。

以支付举例，保证幂等的两个重要条件：

1.一个幂等的令牌，支付请求发起时，创建一个唯一的token，token使用一次就作废

2.确保唯一性，指的是要确保同一笔交易不会因为两次请求而处理多次，通常利用数据库实现，比如把存储token的列设定为唯一的索引，这样当试图存储两个同样的token，会报错，简单的读检查不一定可行，因为读与读之间会有竞争，还是有可能出错。

支付的具体业务流程如下：

1.获取token

2.使用token调用支付

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

4.给客户端返回结果

这时如果有超时情况出现，多次请求的结果依然是幂等的