幂等设计及应用

百度百科/HTTP中定义                                                                                                                

幂等（idempotent、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.

这里不讨论学术上如何定义幂等性，而是重点在于如何在分布式环境中提供对外幂等性的接口。对外提供的接口承诺幂等性，其要表达的含义是：只要调用接口成功，外部对接口的多次调用得到的结果是相同的。即执行多次和一次的效果是一样的。

 

应用场景

在实际的生产环境中，我们不时还是会遇到防重或者幂等问题。例如有些老的订单系统，可能因为某个中间节点阻塞超时，触发了重发机制，最终导致多个相同ID的交易请求同时到达系统后台。由于老订单系统只提供了简单的串行防重，并没有充分考虑高并发幂等，结果将同一个用户的交易请求执行了多次，导致该用户的前后端的资产份额不一致，最终不得不人工介入解决。

 

解决方案

1、最简单的，需要通过唯一的业务单号来保证幂等。也就是说相同的业务单号，认为是同一笔业务。使用这个唯一的业务单号来确保，后面多次的相同的业务单号的处理逻辑和执行效果是一致的。以支付为例，在不考虑并发的情况下，实现幂等很简单：①先查询一下订单是否已经支付过，②如果已经支付过，则返回支付成功；如果没有支付，进行支付流程，修改订单状态为‘已支付’。

2、上述的保证幂等方案是分成两步的，第②步依赖第①步的查询结果，无法保证原子性的。在高并发下就会出现下面的情况：第二次请求在第一次请求第②步订单状态还没有修改为‘已支付状态’的情况下到来。既然得出了这个结论，余下的问题也就变得简单：把查询和变更状态操作加锁，将并行操作改为串行操作。

3、但是，在某些场景，你可能又想提供无锁的高并发幂等，那么你可以选择为业务单号加上唯一的索引或者组合索引，在并发的场景中，只有第一笔插入的交易请求能够成功，后续的请求哪怕是慢1ms或者更短时间，都会触发数据库的唯一索引异常而失败，那么你可以捕获这个异常。

4、又或者你想把幂等放在服务的最前端，减少实际服务处理的资源浪费，在请求一到达时就提前去重，不让他有执行的机会，那么你可以考虑引入一个redis或类似的组件，将业务请求单号缓存在这个分布式锁的组件内。那么，每当订单发起交易请求，交易系统会去Redis缓存中查询是否存在该订单号的Key，如果不存在，则向Redis增加Key为订单号。查询订单是否已经执行，如果没有则转发到交易系统，执行完成后删除该订单号的Key。当然，Redis是提供分布式节点下的原子事务操作的。