如何保证分布式场景下的并发幂等性

随着微服务的普及和推广，服务变得越来越多，多个服务之间的并发问题也给我们带来了新的技术挑战，因此我们需要一个分布式锁来解决服务跨进程之间 本地线程资源无法共享的问题 换而言之，分布式锁是解决分布式场景下的并发问题的一种方式。分布式锁是不是解决并发幂等的方式呢？又如何确保分布式场景下并发幂等性？

一、为什么需要保证服务的幂等？

如图所示，假如用户请求发起了退款，在进行一系列的规则校验和业务处理后，资金出账。但是由于涉及金钱的交易，如果用户同时发起多次相同的退款请求，也不能出现多次资金出账的操作，进而导致多次扣款

许多业务场景中，存在客服端发起重复提交或者服务端发起多次重试，我们需要保证 资源最后只会产生一个最终结果

因此，幂等性的核心就是保证资源的唯一性

二、如何保证幂等性机制呢？

首先要理解幂等是幂等，并发是并发，都不是一个东西。

幂等定义是多次执行和一次执行结果一样，不涉及数据修改，不用幂等

1、数据库的唯一索引方案

需要在数据库中针对需要约束的资源字段创建唯一索引。假设有两个服务，一个退款服务，一个支付服务，可以将退款订单编号作为唯一的索引，当退款服务发起一条退款请求时，会请求支付服务进行扣款操作，支付服务需要判断这笔退款是否存在已支付的出账流水记录，然后判断订单号是否在数据库中存在，如果存在则表示已经退款，拒绝执行退款逻辑，如果不存在，则插入数据然后执行退款操作，但是当遇到分库分表的时候，唯一索引就变得不实用了，这个时候该如何操作呢？这就需要使用方案2了

2、先执行select,后执行insert方案

在进行退款服务的是，先select 查询是否存在这条退款记录，如果存在则拒绝，如果不存在则insert，但是这种方法会存在并发的问题，假如有两个服务A、B，同时向服务C发起请求

if(约束资源字段不存在){
     执行业务逻辑操作
    }

那么可能就会同时进入if判断的代码中，从而导致重复数据写入，为了避免并发安全问题，因此引入了方案3 分布式锁方案

3、分布式锁方案

分布式锁的实现方案常用的有两种，一种是Redis另一种是使用Zookeeper。Zookeeper实现方式就是使用临时的有序节点实现，具体可以自行搜索。我们这里分析下Redis的实现方式，如下图所示，redis的分布式锁机制就是通过获取锁令牌来对约束的资源进行写操作

假如现在有一个退款服务和三个支付服务，退款服务重复发起多次调用，分别落到每个支付服务上，支付服务会通过redis的setnx命令对约束的资源进行操作，如果没有则插入，如果有，则不做操作，从而实现幂等操作。另外为了防止死锁，需要设置一个过期时间，进行自动锁销毁

是不是分布式锁就完美的解决了并发幂等的方式呢？并不是，还是使用上面的一个退款服务和三个支付服务做假设，如下图。

设置 redis分布式锁设置的过期时间是10分钟，假如退款服务同时发起了5个退款请求，这5个请求分别进入Mq中，第一个请求成功，资金出账成功了。但是由于网路原因或者服务限流等其他原因，导致mq请求支付服务失败，不断重试，在重试了30分钟后，请求支付服务成功了，但是由于之前的redis分布式锁10分钟就过期了，所以导致第二此退款的请求也成功了，这就导致了资金受损。所以 redis分布式锁只是为了 避免并发安全的问题，保证临界资源的唯一性， 但是仅仅使用分布式锁是没办法保证 分布式场景下并发幂等性的。

解决：

• redis分布式锁的过期时间需要大于重试机制的
• 使用分布式锁+数据持久化

4、状态机

通过引入状态机进行状态约束和状态流转，这里假设是一个订单业务，我们可以对当前状态进行验证，判断当前状态是不是‘待支付’，如果状态没有达到预期，则采取拒绝操作；而如果达到了预期，程序会执行响应的支付逻辑；

因此我们在一个业务执行过程中，状态机确保同一个业务的流程化执行，从而实现数据幂等

状态机这个处理，如果只是在程序里面，先判断状态在操作的话，应该会存在问题。一般的状态流转，在sql都是做条件更新，也就是乐观锁的方式。

程序可以先判断一下，否则每次请求都会打到db，打到db后sql再做个乐观锁

三、总结

首先我们需要了解幂等机制的核心，而它对于防止重复消费特别有帮助，例如我们经常遇到的超卖与重复出账，那我们又如何确保分布式场景下的并发幂等性呢

总共有以下四种方案：

1、创建数据库的唯一索引

2、对于分布式数据存储(分库分表),第1种不适用，我们采用另一种“先执行select后执行insert”策略

不适用的情况：
比如我们的分表策略，如果hash用id，那么约束字段不是id，那么可以就在不同的表里面，那么唯一索引就不会生效。另外，要考虑并发安全。
这里主要针对是约束字段不是主键的情况。如果是主键，那单机和分片都可以保证唯一约束。

3、第2种可能会遇到并发安全问题，因此为了避免这个问题，可以引入分布式锁来解决，但是分布式锁只是为了避免并发安全问题，如果超过它的存活，就存在业务风险了，因此我们前面采用了一些方案来优化这个重试超时的问题

4、最后，我们引入了状态机，通过状态机，进行状态约束和状态流转。

思考：是否所有的接口都需要保证幂等

• select查询天然幂等
• delete删除也是幂等,删除同一个多次效果一样
• update直接更新某个值的,幂等
• update更新累加操作的,非幂等
• insert非幂等操作,每次新增一条

主要还是要针对业务场景，比如本来就是写入redis，天生就是幂等的；比如查询接口，也不需要保证幂等，但为避免qps过高，可能要考虑引入限流

所以假设对于以相同的请求调用这个接口一次或多次，需要给调用方返回一致的结果时，就要考虑将这个接口设计成幂等接口。

参考文章：根据极客时间每日一课进行整理
https://time.geekbang.org/dailylesson/detail/100044036