幂等性（HTTP）

1、幂等性定义

HTTP协议涉及到的一种重要性质：幂等性(Idempotence)。在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.

从定义上看，HTTP方法的幂等性是指一次和多次请求某一个资源应该具有同样的副作用。

实际上，幂等性是分布式系统设计中十分重要的概念，而HTTP的分布式本质也决定了它在HTTP中具有重要地位。

2、HTTP请求方法的幂等性

假如在不考虑诸如错误或者过期等问题的情况下，若干次请求的副作用与单次请求相同或者根本没有副作用，那么这些请求方法就能够被视作 “幂等” 的。

HTTP 方法中：

• GET 方法用于获取资源，不会影响到资源的变化，所以是幂等的。
• HEAD 方法向服务器索要与GET请求相一致的响应，只不过响应体将不会被返回，所以是幂等的。
• PUT 方法表示更新资源，而PUT所对应的URI是要创建或更新的资源本身，对同一URI进行多次PUT的副作用和一次PUT是相同的；因此，PUT方法具有幂等性。
• DELETE 方法用于删除资源，有副作用，但它应该满足幂等性。
• OPTIONS 方法返回服务器针对特定资源所支持的HTTP请求方法，所以是幂等的。
• TRACE 方法可以回显服务器收到的请求，主要用于测试或诊断，所以是幂等的。
• POST 方法表示创建资源，两次相同的POST请求会在服务器端创建两份资源，它们具有不同的URI，所以不具备幂等性。

假如某个由若干个请求做成的请求串行产生的结果在重复执行这个请求串行或者其中任何一个或多个请求后仍没有发生变化，则这个请求串行便是“幂等” 的。但是，可能出现若干个请求做成的请求串行是“非幂等”的，即使这个请求串行中所有执行的请求方法都是幂等的。例如，这个请求串行的结果依赖于某个会在下次执行这个串行的过程中被修改的变量。

3、分布式事务 vs 幂等设计

（1）示例

假设订单支付过程，如果操作成功，则账户余额减少对应的金额；如果操作成功，则账户余额不变。
如果用户重复多次点击支付按钮，或者是网络异常导致订单已经支付成功了但没有及时反馈给用户，用户再次点击支付按钮，就可能造成重复扣款，造成严重后果。

这个问题的解决方案：采用分布式事务，幂等设计

（2）分布式事务

通过引入支持分布式事务的中间件来保证支付功能的事务性。

分布式事务的优点是对于调用者很简单，复杂性都交给了中间件来管理。缺点则是一方面架构太重量级，容易被绑在特定的中间件上，不利于异构系统的集成；另一方面分布式事务虽然能保证事务的ACID性质，而但却无法提供性能和可用性的保证。

（3）幂等设计

服务器端生成的唯一的处理号，将它用于标识后续的操作，一个处理号表示的操作至多只会被处理一次，每次调用都将返回第一次调用时的处理结果，这样就符合幂等性。

幂等设计是一种更轻量级的解决方案，容易适应异构环境，以及性能和可用性方面。在某些性能要求比较高的应用，幂等设计往往是唯一的选择。