Tag: 微信支付

什么是幂等（Idempotency）？简单来说，一个操作如果具有任意多次执行所产生的影响均与一次执行的影响相同，我们就称之为幂等。 这样说来，似乎很容易理解。但要知道，这样的定义，其实是一个语义范畴对行为结果的定义。如何用语法和规则去确保行为能达到这个结果，往往需要很谨慎的设计和实现。实际系统中，幂等是一个极为重要的概念。无论是在大型互联网应用还是企业级架构中，我们都见到 REST API 被越来越多的采用。而正确实现幂等，往往是 API 中最难的技术点之一。 先说为什么重要。举一个简单易懂的例子。 比如你要处理一次电商网站收款或者付款的交易。当你给微信支付发送这个付款请求后，一个顺利的场景，是没有任何错误发生，微信支付收到你的付款请求，处理所有转账，然后返回一个 HTTP 200 消息表示交易完成。 那如果发出请求后，有个请求超时，你再也没有收到关于这个请求是成功还是失败的的回执，又该如何呢？ 这里就有很多种可能情况： 这个请求在到达微信支付端前就已经发生超时，微信支付从来没有收到这样的请求。 这个请求到达微信支付端，但是支付交易失败，这时发生超时，微信支付收到这样的请求，但没有处理成功。 这个请求到达微信支付端，并且支付交易成功，这时发生超时，微信支付收到这样的请求，处理成功，但是没有回执。 这个请求到达微信支付端，并且支付交易成功，并且发回回执，然而因为网络原因回执丢失，客户端超时，微信支付收到这样的请求，处理成功，发出回执，但是客户没有收到。 很直观的一个想法，也是现实中用户最常见的做法，是重新提交一次支付请求。但是这样就有一个潜在的问题：请求超时是上面的哪一种情况？会不会引发多次支付的可能性？ 这就涉及到系统中的幂等是如何实现的了。 那么幂等又该如何实现呢？“多次执行所产生的影响均与一次执行的影响相同”，简而言之，我们需要一个 Dedup（去重）的机制。这往往有很多不同的实现方法，但是有两个很关键的因素： 一是Idempotency Key（幂等令牌）。也就是客户端和服务器端通过什么来识别这实际上是同一个请求，或是同一个请求的多次 retry（尝试）。这往往需要双方又一个既定的协议。往往是类似账单号或者交易 token（令牌）这样一个可以唯一标识同一个请求意愿的元素。通常由客户端生成。 二是Uniqueness Guarantee（确保唯一性）。服务器端用什么机制去确保同一个请求一定不会被处理两次，也就是微信支付怎么确保同一笔交易不会因为客户端发送两次请求就被处理多次。最通常的做法是利用数据库。比如把幂等令牌所在的数据库表的 Column（列）作为 unique indexed。这样，当你试图存储两个含有同样令牌的请求时，必定有一个会报错。注意，简单的读检查并不一定行，因为读与读之间会有 Race Condition（竞争条件），因此还是有可能出错。 如果一个系统可以正确的处理和实现上面的两个要素，那么基本就能达到幂等的需求。那么现实系统中常见的问题都出在哪里呢？ 一是幂等令牌什么时候产生，怎么产生？这一点很重要。拿上面的例子来说。就算微信支付可以保证每一个请求对应的支付交易一定只会被处理一次。但是这个请求的多次重复，一定要共有某一个微信可以识别的标识。假如客户端对同一笔交易的多次请求，产生的幂等令牌并不相同，那不论你别的地方多么完美，都没有可能保证 “一个操作如果具有任意多次执行所产生的影响均与一次执行的影响相同”。 二是有没有令牌被误删的可能。这是上面的问题的一个特殊情况。幂等令牌是由客户端生成的。那么如果生成的令牌在被使用后（一次微信支付请求中使用了），不小心因为 DB rollback 等原因被删除了。那么客户端就不知道自己其实已经发过一次请求。就有可能生成一个新的账单，并产生全新的令牌，而服务端将对此一无所知。 三是各种竞争条件。上面说的用 DB 读来确保唯一性经常因为竞争而不工作。其实一个需要幂等的系统中，保证唯一性的各个环节和实现，都要考虑 Race Condition。 四是对请求 Retry 的处理。这大部分是服务器端要做的。一个常见的方法是区分正在处理的请求、和处理成功、处理失败的请求。这样当客户端重试的时候，根据情况或者直接返回，或者再次处理。就好像前面说的微信支付的例子。微信支付服务上，需要知道每一笔交易的处理情况，才能正确处理在此转账请求时，是不是需要进行任何动作。 五是一个系统中需要多层幂等。什么意思呢？A 发送请求给 B，B 处理的一部分是要发送请求给另一个系统 C，C 在处理的过程中还可能需要发请求给另一个系统 D………