一.简介
现如今系统大多为分布式SOA或者微服务，一套系统中包含多个子系统，子系统之间互相调用。
而服务调用服务无非就是使用RPC通信或者restful，既然是通信，那么就有可能在服务器处理完毕后返回结果的时候挂掉，这个时候用户端发现很久没有反应，那么就会多次点击按钮，这样请求有多次，那么处理数据的结果是否要统一呢？那是肯定的！尤其在支付场景。
幂等性：就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用。
非幂性：在这种情况下，如果出现多个客户端操作共享资源，就可能意味着数据不一致，数据丢失。
二.举例
举个最简单的例子，那就是支付，用户购买商品支付购买，支付扣款成功，但是返回结果的时候网络异常，此时钱已经扣了，用户再次点击按钮，此时会进行第二次扣款，返回结果成功，用户查询余额返发现多扣钱了，流水记录也变成了两条。
在以前的单应用系统中，我们只需要把数据操作放入事务中即可，发生错误立即回滚，但是再响应客户端的时候也有可能出现网络中断或者异常等等。
三.幂等性设置
操作分析
在增删改查4个操作中，尤为注意就是增加或者修改
查询对于结果是不会有改变的 删除只会进行一次，用户多次点击产生的结果一样 修改在大多场景下结果一样 增加在重复提交的场景下会出现
方法一：门票
单次支付请求，也就是直接支付了，不需要额外的数据库操作了，这个时候发起异步请求创建一个唯一的ticketId，就是门票，这张门票只能使用一次就作废，具体步骤如下：
异步请求获取门票 调用支付，传入门票 根据门票ID查询此次操作是否存在，如果存在则表示该操作已经执行过，直接返回结果；如果不存在，支付扣款，保存结果 返回结果到客户端
如果步骤4通信失败，用户再次发起请求，那么最终结果还是一样的
方法二：订单状态
这边就要举例我们的系统了，我们支付的时候先要扣款，然后更新订单，这个地方就涉及到了订单服务以及支付服务了。
1、查询订单支付状态（未支付，已支付） 2、如果已经支付，直接返回结果 3、如果未支付，则支付扣款并且保存流水 4、返回支付结果
如果步骤4通信失败，用户再次发起请求，那么最终结果还是一样的
