幂等设计及应用

为了更深入地理解幂等，我们先来看看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.

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

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

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

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

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