随着微服务的普及和推广，服务变得越来越多，多个服务之间的并发问题也给我们带来了新的技术挑战，因此我们需要一个分布式锁来解决服务跨进程之间 本地线程资源无法共享的问题 换而言之，分布式锁是解决分布式场景下的并发问题的一种方式。分布式锁是不是解决并发幂等的方式呢？又如何确保分布式场景下并发幂等性？
一、为什么需要保证服务的幂等？
如图所示，假如用户请求发起了退款，在进行一系列的规则校验和业务处理后，资金出账。但是由于涉及金钱的交易，如果用户同时发起多次相同的退款请求，也不能出现多次资金出账的操作，进而导致多次扣款
许多业务场景中，存在客服端发起重复提交或者服务端发起多次重试，我们需要保证 资源最后只会产生一个最终结果
因此，幂等性的核心就是保证资源的唯一性
二、如何保证幂等性机制呢？
-
数据库的唯一索引方案
需要在数据库中针对需要约束的资源字段创建唯一索引。假设有两个服务，一个退款服务，一个支付服务，可以将退款订单编号作为唯一的索引，当退款服务发起一条退款请求时，会请求支付服务进行扣款操作，支付服务需要判断这笔退款是否存在已支付的出账流水记录，然后判断订单号是否在数据库中存在，如果存在则表示已经退款，拒绝执行退款逻辑，如果不存在，则插入数据然后执行退款操作，但是当遇到分库分表的时候，唯一索引就变得不实用了，这个时候该如何操作呢？这就需要使用方案2了
-
先执行select,后执行insert方案
在进行退款服务的是，先select 查询是否存在这条退款记录，如果存在则拒绝，如果不存在则insert，但是这种方法会存在并发的问题，假如有两个服务A、B，同时向服务C发起请求
if(约束资源字段不存在){
执行业务逻辑操作
}
那么可能就会同时进入if判断的代码中，从而导致重复数据写入，为了避免并发安全问题，因此引入了方案3 分布式锁方案
-
分布式锁方案
分布式锁的实现方案常用的有两种，一种是Redis另一种是使用Zookeeper。Zookeeper实现方式就是使用临时的有序节点实现，具体可以自行搜索。我们这里分析下Redis的实现方式，如下图所示，redis的分布式锁机制就是通过获取锁令牌来对约束的资源进行写操作
假如现在有一个退款服务和三个支付服务，退款服务重复发起多次调用，分别落到每个支付服务上，支付服务会通过redis的setnx命令对约束的资源进行操作，如果没有则插入，如果有，则不做操作，从而实现幂等操作。另外为了防止死锁，需要设置一个过期时间，进行自动锁销毁
是不是分布式锁就完美的解决了并发幂等的方式呢？并不是，还是使用上面的一个退款服务和三个支付服务做假设，如下图。
设置 redis分布式锁设置的过期时间是10分钟，假如退款服务同时发起了5个退款请求，这5个请求分别进入Mq中，第一个请求成功，资金出账成功了。但是由于网路原因或者服务限流等其他原因，导致mq请求支付服务失败，不断重试，在重试了30分钟后，请求支付服务成功了，但是由于之前的redis分布式锁10分钟就过期了，所以导致第二此退款的请求也成功了，这就导致了资金受损。所以 redis分布式锁只是为了 避免并发安全的问题，保证临界资源的唯一性， 但是仅仅使用分布式锁是没办法保证 分布式场景下并发幂等性的。
解决：
- redis分布式锁的过期时间需要大于重试机制的
- 使用分布式锁+数据持久化
- 状态机
