引言
互联网时代以来，基于HTTP协议提供Web API的方式几乎成了约定俗成的规范，再加上近年来分布式SOA、微服务的流行，服务的粒度越来越细，服务间的依赖调用关系也越来越复杂，如何保证分布式服务的可靠性、正确性、事务性已成为开发者的重点关注问题。
本篇探讨的幂等性正是HTTP协议、分布式系统中的重要性质，一个优秀的分布式系统的服务务必需要保证幂等性！接下来就介绍什么是幂等性、HTTP中幂等性的体现、分布式事务与幂等设计的优缺比较、实际的幂等设计案例。
幂等性定义
其实幂等性最早源自HTTP/1.1，它要求一次和多次请求某一个资源应该具有同样的副作用。这句话听起来比较晦涩，最简单明了的例子还是支付场景：比如我们在购物网站选好东西后，进入支付页面点击支付，此时支付请求发送给银行后端，然后从数据库中成功扣除了金钱，并将成功扣钱的消息返回至前端，问题来了，如果在返回途中网络发生异常，消息丢失，那么前端将无任何反应，这体现在用户身上很可能就是再次点击“支付按钮”进行支付！按照正常逻辑，此时支付请求发送给银行后端后是不应该再次扣除金钱的，但由于HTTP协议的无状态性，它不关心前一次是否扣除了金钱这个条件，只一视同仁地认定这一次是要扣除金钱的，所以最终必然会多扣一次钱！
这个例子就是因为不具备幂等性导致的，对同一订单提交多次支付请求，应该最多只被扣除一次钱，当某次的支付请求成功后，之后对该订单的所有请求都不再应该再生效。
HTTP幂等性
HTTP协议处于应用层，通常对其使用分为两种：一种是纯粹的基于RESTful的面向资源的方式，比较忠实地遵守了HTTP规范；另一种是基于SOA的方式，在HTTP协议之上又建立了一层通信协议，以此再去提供API，比如SOAP、RPC。但幂等性并不属于某个特定方式，它是分布式系统设计中的特性，无论是基于RESTful的还是SOA的都应该遵循这个特性。接下来要讨论的就是更接近原生HTTP的RESTful调用形式中的方法：GET、POST、PUT、DELETE的幂等性。
- GET：语义上是从服务器获取资源，虽然数据可能随时都在变动，获取到的结果可能每次不一样，但幂等性强调的是1次操作和N次操作不会对数据造成副作用，因此是满足幂等的。
- DELETE：资源只要被成功删除一次后将不复存在，之后N次的重复删除将是徒劳和等效的，因此也是满足幂等的。
比较模糊的是POST和PUT方法，在开发过程中，我们通常采用POST去添加或插入新的数据，而PUT用于后期对数据的更新，即容易被误认为是“POST创建资源，PUT更新资源”，而事实上两者均可用于创建和更新资源，更为鲜明的不同是幂等性。下面我们以要在www.shopping.com下创建和更新book为例进行说明。 - POST：根据RESTful规范，POST的URI应该是www.shopping.com/book， 而另将请求参数写入JSON中再传至后端。如果是创建book，那么它很显然是不具有幂等性的，因为在资源还未创建前前端通常是拿不到book的主键的，因而只能携带book的若干属性参数，主键的生成是在后端完成，那么一旦发送多次，必然会造成book的重复创建（仅主键不同）。而如果是非要将POST用于更新book（通常不这么做），那么显然JSON中就可以携带主键信息了，这样无论是1次还是N次操作的效果都是一样的，即具有幂等性。
- PUT：更新book的URI应该是www.shopping.com/book/{id}这样的，显然同上面更新一样，是具有幂等性的，因为它的语义非常精准，是更新某个特定资源。
分布式事务还是幂等设计？
从上面可以看出，其实幂等性与否最重要的就是能否“找到唯一地标识操作的办法”，让操作具有ACID(原子性、一致性、隔离性、持久性)四要素。那么通过借鉴数据库中事务的概念，对于分布式系统（SOA、微服务），很容易想到的就是把事务应用其中。但由于分布式本身的困难性、复杂性，使得要完成事务并非像在单机上那么容易，因为在一个机器上执行完对应服务后，已经成功commit，而此时再想回滚就必须进行业务的逆操作了，而不同业务的你操作又各不相同，复杂性指数型上涨。
目前解决分布式事务通常是引入一个中间件来保证withdraw功能的事务性，往往是采用二阶提交协议（2PC）完成，比较成熟的解决方案是支付宝的XTS和DTS，关于其原理本篇就不详细展开了。引入中间件确实可以保证ACID，而且对于调用者透明友好，复杂性都交由中间件完成了。缺点是架构重量级，需要迎合该中间件的规范，不利于异构系统的集成，更重要的是为了完成事务很可能在性能上要牺牲很多。
幂等设计
条条大路通罗马，仔细想想其实并非所有场景下我们都需要幂等设计，只有一些数据敏感、需要保证强一致性的场景下才会需要，那么如果我们能专门为其设计一套幂等的方案，不仅可以达到功能性要求，性能也一定是比分布式事务中间件要好。下面就之前的支付场景给出幂等的设计方案。
幂等在概念上很抽象，但设计起来还是有迹可循，那就是之前提到的能够“唯一标识操作”：
如果1次携带了这个标识的操作成功执行
那么之后N次操作再携带这个标识，都自动忽略或无效化处理
那么对于这个支付例子：当用户需要支付时，首先不急于完成支付业务，而是先由后端下发一个token唯一标识这笔订单的支付号，前端收到后，再携带该token请求支付api，后端通过查询数据库识别这个token是否已支付成功过，若是立即返回，若不是才进入支付流程。支付流程完成后，需要在数据库里对token进行标识（如已支付），然后将支付成功的消息返回至前端，此时就算消息丢失了也没问题啦，因为我们已经在后端数据库标识了token的完成与否。
具体的Client和Sever交互的时序图如下：
上述的支付例子中两处需要说明：
- 不一定生成token：仔细想想其实token只要唯一标识这次交易即可，因此倒不必一定要刻板地生成token，完全可以采用订单号、交易号充当这个token。
- token不必下发：请求生成token是必要的，但token不必再传回前端，而是把它存放于session中，当下次请求支付的时候，读取session中是否有token，若有则进入支付流程，待支付完成后从session中删除token保证幂等。
虽说可以采用session，但其实目前更推崇的还是本文所述的无状态性的token令牌实现，因为传统的session在分布式集群下不好同步，特别是在负载均衡场景下更是明显：请求下发时负载到服务器A，在它上面的session中存放了token，而下次一旦负载到非A服务器，其上session中是没有任何与token相关的信息的。目前也有分布式场景下对session进行同步的解决方案，但远远没有token来得简单、方便和快速。当然如果只是想在单台服务器上完成上述幂等设计，采用session是完全可以的。
结语
幂等性不仅是HTTP协议的一个特性，在分布式系统中也有着重要意义，好的幂等设计更是保证系统可靠性、正确性的一大法宝，在达到功能需求的同时，性能上也能提升许多。
