分布式系统中的幂等性（客户端与服务端的交易一致性，避免多次扣款）

原文Zookeeper与Dubbo | 什么是分布式系统中的幂等性

结合支付防重设计一起看

ZooKeeper是一种分布式协调服务，他用简单的架构和API，解决了在分布式环境中协调和管理服务的难题。

背景

分布式SOA，或者微服务，一套系统中包含了多个子系统服务，而一个子系统服务往往会去调用另一个服务，而服务调用服务无非就是使用RPC通信或者restful。
既然是通信，那么就有可能在服务器处理完毕后返回结果的时候挂掉，这个时候用户端发现很久没有反应，那么就会多次点击按钮，这样请求有多次，那么处理数据的结果是否要统一呢？那是肯定的！尤其在支付场景。

幂等性：就是用户对于【同一操作】发起的【一次请求或者多次请求】的【结果是一致的】，不会因为多次点击而产生了副作用。

举个最简单的例子，那就是支付，用户购买商品使用支付，支付扣款成功，但是返回结果的时候网络异常，此时钱已经扣了，用户再次点击按钮，此时会进行第二次扣款，返回结果成功，用户查询余额返发现多扣钱了，流水记录也变成了两条。

在单应用系统中，我们只需要把数据操作放入事务中即可，发生错误立即回滚，但是在响应客户端的时候也有可能出现网络中断或者异常等等。

在增删改查4个操作中，尤为注意就是增加或者修改。

• 查询对于结果是不会有改变的；
• 删除只会进行一次，用户多次点击产生的结果一样；
• 修改在大多场景下结果一样；
• 增加在重复提交的场景下会出现。

如何设计接口才能做到幂等

方法一

单次支付请求，也就是直接支付了，不需要额外的数据库操作了。

1. 发起异步请求创建一个唯一的ticketId，就是门票，（这张门票只能使用一次就作废）
2. 异步请求获取门票→调用支付，传入门票
3. 根据门票ID查询此次操作是否存在，如果存在则表示该操作已经执行过，直接返回结果；如果不存在，支付扣款，保存结果
4. 返回结果到客户端

如果步骤4通信失败，用户再次发起请求，那么最终结果还是一样的

方法二

分布式环境下各个服务相互调用

我们支付的时候先要扣款，然后更新订单，这个地方就涉及到了订单服务以及支付服务了。

用户调用支付—>扣款成功后—>更新对应订单状态—>然后再保存流水。

而在这个地方就没必要使用门票ticketId了，因为会比较闲的麻烦（支付状态：未支付，已支付）
步骤：

• 查询订单支付状态
• 如果已经支付，直接返回结果
• 如果未支付，则支付扣款并且保存流水
• 返回支付结果

如果步骤4通信失败，用户再次发起请求，那么最终结果还是一样的

对于做过支付的朋友，幂等，也可以称之为冲正，保证客户端与服务端的交易一致性，避免多次扣款。

然后呢咱们来看一下我们的订单流程，虽然不是很复杂，但是最后在支付环境是一定要实现幂等性的

分布式锁

另外，在这个订单过程中，我们也要考虑锁的问题，既然在分布式环境中，那这个锁就是分布式锁，我们可以很好的通过zookeeper来做好分布式锁，把我们的资源限定给用户。比方说，在支付的时候，由于多链路，假设一开始没有结账，最后结账单位和会计都来做支付，由于考虑并发的可能性，第一个用户发起的请求可能卡住，第二个用户发起的请求已经结束，你们第一个请求有可能也会支付成功，那么这个时候就需要zookeeper来做分布式锁的控制了。

同时，关于多链路，并发的时候对于业务肯定需要拆分的，那么不同的业务作为一个微服务，可以使用dubbo来做服务化，并且注册到zookeeper，让调用方来订阅，这样可以很好的做好业务分离以及微服务。