订单交易系统中的幂等设计

在一个典型的订单交易系统中，防重和幂等设计是重要而又非常基本的概念。防重是指重复多次提交同样的交易指令或者订单请求到后台，系统必须能够去重，防止重复执行；而幂等，则是在多个同样的交易指令或请求同时或者先后到达后台，即使重复执行，系统也必须始终提供与一致的状态，而不能有其他的副作用。看起来，防重与幂等似乎在说同一件事情，但其实又有不同的概念区分。例如幂等其实可以通过防重设计来达到提供一致的系统状态，而防重却不如幂等那样开放承诺，允许被执行多次而达到一致状态，这其实要求在防重的基础上做出更多的设计工作，特别是在分布式环境中。

为了更深入地理解幂等，我们先来看看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的交易请求同时到达系统后台。由于老订单系统只提供了简单的串行防重，并没有充分考虑高并发幂等，结果将同一个用户的交易请求执行了多次，导致该用户的前后端的资产份额不一致，最终不得不人工介入解决。

所以，有了这个前车之鉴，在我们的X订单系统开发中，幂等设计第一时间便提上日程，最终完美地解决了老系统的这个设计缺陷。

常见的幂等实现方案，有这么几种，可以供大家探讨：

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

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

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

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

这里只简单地罗列了几种常见的幂等方案，更加精密、优雅的方案欢迎大家一起来分享、讨论。

原文地址：http://www.sohu.com/a/209828540_505901