随着微服务的普及和推广，服务变得越来越多，多个服务之间的并发问题也给我们带来了新的技术挑战，因此我们需要一个分布式锁来解决服务跨进程之间 本地线程资源无法共享的问题 换而言之，分布式锁是解决分布式场景下的并发问题的一种方式。分布式锁是不是解决并发幂等的方式呢？又如何确保分布式场景下并发幂等性？
一、为什么需要保证服务的幂等？
如图所示，假如用户请求发起了退款，在进行一系列的规则校验和业务处理后，资金出账。但是由于涉及金钱的交易，如果用户同时发起多次相同的退款请求，也不能出现多次资金出账的操作，进而导致多次扣款
许多业务场景中，存在客服端发起重复提交或者服务端发起多次重试，我们需要保证 资源最后只会产生一个最终结果
因此，幂等性的核心就是保证资源的唯一性
二、如何保证幂等性机制呢？
首先要理解幂等是幂等，并发是并发，都不是一个东西。
幂等定义是多次执行和一次执行结果一样，不涉及数据修改，不用幂等
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
标签：场景,服务,请求,redis,并发,退款,分布式 来源： https://blog.csdn.net/belongtocode/article/details/117659366
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。