幂等性概念认知

释义

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. 《rfc2616 - 9.1.2 Idempotent Methods》

以上是摘自HTTP1.1标准中有关幂等性的介绍，大体内容为，除开网络错误以及请求超时的问题，请求同一个接口屡次和单次，对资源所形成的影响是一致的。

这里须要注意的是，幂等性关注的是对资源形成的影响，而非请求返回的结果。

例如咱们设计了一个GET接口api/getSystemTime，用于返回服务器的实时时间，虽然每次返回的结果都是不同的，可是对服务器来讲并无发生资源变更，因此也是幂等的。

通常来讲，GET、OPTIONS、HEAD、DELETE这些请求方法都是幂等的，由于对服务器资源都是没有影响的，或是产生的影响是一致的。像POST、PUT、PATCH这些请求方法通常都是非幂等的。

固然，有一些业务场景下，咱们须要用到POST接口，同时也要保证幂等性，咱们也能够本身实现接口的幂等性。

场景

通常咱们定义幂等性接口的使用场景是防止出现请求屡次而致使的服务结果不一致的状况。例如付款接口，用户在前端可能由于点击屡次，发起了屡次请求，若是这个时候接口不作好幂等性的话，可能会出现屡次付款的状况。

思路

Token方式

实现幂等性能够从控制资源访问的次数下手。

即便有多个请求过来须要请求支付，咱们只须要容许其中一次请求进行完整的支付流程，其余请求均放弃便可。

这样咱们能够延伸出token的概念。

假设咱们的系统由订单系统和支付系统两部分组成，当咱们提交订单后，由订单系统向支付系统申请一个token，支付系统在生成后返回这个token，同时将token存至Redis缓存中。这样当咱们向支付系统发起支付请求时，带上这个token，支付系统须要先判断一下在缓存中是否存在这个token，若是存在则删除这个token，同时继续执行支付逻辑；若是缓存中不存在这个token，则返回业务错误。

这里的token相似于一个信物，只有持有这个信物的人才容许被放行，放行后，这个信物也不被信任，下次即便有携带相同信物来的人，也不给放行。

题外话

写到最后，忽然想起来为啥要研究这个幂等性来着。

当时是在一个客户现场出现的生产问题，咱们的应用程序，经过nginx往算法服务发送一个POST请求后，在通过大概10分钟，算法忽然又被调用了一次，且收到的参数和第一次一摸同样。一开始觉得是应用程序的问题，在公司的测试环境模拟了一遍，没有复现，后来怀疑多是nginx作的鬼，问了现场，才知道现场使用的nginx版本是1.8.1（吐槽一下版本有点老）。而后在网上查阅资料，得知1.9.13之前版本的nginx默认会将POST等非幂等请求作超时重试处理。虽然咱们的应用程序在往算法发起请求后，就不会再作什么后续处理，但坑的是算法会保持这个请求也不返回数据，致使nginx认为请求超时了，又发起了一波请求，血与泪哦。

因为不能让现场升级nginx，因此咱们只能让现场在nginx中加大了那个算法接口的超时时间。

下面摘自nginx官方文档。

normally, requests with a non-idempotent method (POST, LOCK, PATCH) are not passed to the next server if a request has been sent to an upstream server (1.9.13); enabling this option explicitly allows retrying such requests;