## 什么是幂等性
一次和多次请求某一个资源应该具有同样的副作用（对资源变更带来连锁反应或影响）：f(x) = f(f(x))。

## 为什么要幂等性设计
系统解耦后，系统间服务调用存在三种状态：
    * 成功
    * 失败
    * 超时（中间状态）
前面两种是明确的，超时是不知道什么状态，一般引起原因:
    * 请求没有到达服务方（网络延时或丢失）
    * 请求达到了服务方，服务方处理超时
    * 请求到达了服务方并且处理完返回结果，但接收方没有收到
相关例子：订单创建、库存扣减、订单支付
## 怎么做幂等性设计
* 下游提供查询接口，上游对于状态疑异订单进行查询
* 下游系统坐幂等性设计：确保不会重复
    * 全局ID：Twitter的Snowflake算法/UUID
    * 存储冲突来解决（唯一约束）
        * 插入重复无效，`insert into … values … on DUPLICATE KEY UPDATE …`
        * 更新状态：`update table set status = “paid” where id = xxx and status = “unpaid”;`
- HTTP幂等性
    - 只有POST需要特殊处理，其他都具有幂等性：
        - 前端生成token，后端存（唯一约束）
        - PRG模式

冥等性，从字面意思很好理解，在前面也有类似概念。函数是无副作用，函数是无状态的，请求都依赖外部参数。
从这个角度放大到业务请求，就是一个请求是无副作用或者多次调用副作用一致。
请求可以有成功，失败，超时三种。
POST请求通常无法保持冥等。
要确保请求的冥等，需要通过一些手段来记录，追踪请求。通过一个全局的ID是比较合理的。该ID可通过算法生成，可以在不同阶段生成，但要全局唯一且足够高效，用中间的生成器不合理。
可以采用分布式的long类型生成算法，以时间，机器号，进程号，生成编号等方式生成。
最后，要保障存储id系统是可靠的，避免后续追踪查询问题

"幂等性设计"产生的大背景是: 服务请求方相对于被请求方的等待超(不明确请求结果)而多次发送同一个请求，从而导致返回多个不同的处理结果，而实际的多个请求只为返回一个明确处理结果的情况。由此，我们导出幂等设计的含义是，使得服务被调用方对于多个相同的请求能够返回一个相同的处理结果。但本文中很巧妙地使用：”副作用“这个词汇，即文中的含义是："一个服务被多次调用和第一次调用所产生的副作用是一样的"。这里，我个人的理解是，幂等设计原本就是针对于不正常的服务调用(等待超时)的一种预防手段，一般正常情况下，这种"手段"是要带来一定的"副作用"的，如，为了判定多次请求的是同一个目的，我们得在系统中额外添加一个能够产生全局唯一 id 的功能，每个相同的请求都得附上该 id，然后，服务被调用方的服务相应每次都得获得该 id，根据处理情况对应地进行结果返回或丢弃等，为了防止每次服务被调用都需要查询该 id 的操作，文中推荐使用的存储冲突报错的机制，及通过多次存储同一个 id 报错的方式实现服务的高效幂等性设计。
以上，可以推出幂等性设计的关键技术要点是：生成全局唯一 id 及其存储(读写)。这里的若是分布式系统中服务，由于其要求系统中的服务要设计成"无状态"的，所以，其幂等设计也得是"分布式"的。关于全局 id 的生成，这里推荐使用的是Twitter 的开源项目 Snowflake，其设计初衷就是面向分布式的唯一 id 生成算法;关于全局 id 的存储，这里给出的参考方案是采用关系性数据库或key-value的 NoSQL(MongoDB)。