幂等，你造吗？

什么是幂等？

幂等在软件开发中，是一个非常重要的设计考量点。在实际开发中越来越多的 REST API 被采用，正确的实现幂等，对很多 API 尤其是涉及金融业务的 API 来说非常重要。

幂等（idempotency）在实际开发中是指：一个操作，多次任意执行或一次执行，所产生的结果相同。

幂等重要么？

例如在实际开发中，我们要请求微信支付处理一笔收/付款交易。当客户端向微信支付发送付款请求后，理想状态下，微信收到请求，处理支付业务，完成并返回给客户端一个 HTTP 200 的状态码，这样即表示交易成功。

但实际业务场景中，我们要考虑的场景很多，例如，请求超时。
当客户端发出请求后，并没有收到服务端的响应，这个时候客户端该怎么做呢？

这种场景下，有很多种可能情况：

1. 这个请求在到达微信支付端前就已经发生超时。即：微信支付从来没有收到这样的请求。
2. 这个请求到达微信支付端，但是支付交易失败，这时发生超时。即：微信支付收到这样的请求，但是没有处理成功。
3. 这个请求到达微信支付端，且支付交易成功，这时发生超时。即：微信支付收到这样的请求，处理成功，但是没有回执。
4. 这个请求到达微信支付端，并且交易成功，并且发回回执，然而因为网络原因回执丢失，客户端超时。即：微信支付收到这样的请求，处理成功，发出回执，但是客户端没有收到。

在面对以上四种不同的业务场景的时候，如果我们直接重新提交一次支付请求， 就会存在一个潜在的问题：会不会引起多次支付的可能性？

这就涉及到系统中幂等是如何实现的了。

幂等如何实现？

根据幂等的定义多次执行所产生的影响均与一次执行的影响相同。所以，我们需要一个去重机制。有很多方法可以实现，但是有两个很关键的因素。

因素一：幂等令牌（Idempotency Key）。

客户端和服务端通过什么方式来识别，这实际上是同一个请求或者同一个请求的多次尝试。这往往许要双方有一个既定的协议，比如订单号或者交易令牌，这些订单号或者交易令牌是唯一标识的元素，这种元素通常由客户端生成。

因素二：确保唯一性（Uniqueness Guarantee）

服务端用什么机制去确保同一个请求不会被处理两次？
最常见的作法是利用数据库，比如把幂等令牌所在的数据库表的列作为唯一性索引，这样，当我们试图存储含有两个相同令牌的请求时，会报错。注意：简单的读建查并不一定成功，因为读与读之间会有竞争条件（Race Condition），因此还是可能出错。

一个系统能正确处理和实现上面两个要素，基本就实现了幂等的要求，那么，在实际业务中常见的问题都会出在哪里呢？

1. 幂等令牌什么时候产生，怎样产生。
2. 是令牌有没有可能被误删的可能。
3. 是各种竞争条件。
4. 是对请求重试的处理。
5. 系统中许要多层幂等。

这是什么意思呢？A 发送请求给 B，B　处理的一部分是要发送请求给另一个系统 C，C同理需要请求另外一个系统 D 。在请求与响应的过程中（A—>B—>C—>D—>C—>B—>A ）如果 ABCD 中任何一个系统没有正确的实现幂等性，也就是出现了“幂等漏洞”，那么一次请求还是有可能被多次执行的。