幂等性及技术解决方案
文章目录
-
定义幂等性
- 为什么需要幂等性
- 幂等性设计注意事项
- 幂等性的范围
- 分布式锁解决幂等性
- 设计
-
延伸阅读
定义幂等性
简单地说,我们可以多次执行幂等运算而不改变结果或者使用相同的输入参数中被调用多次,则不具有额外效果的操作,也就是多次执行的结果都是一致的。
为什么需要幂等性
幂等性确保相同的请求会导致相同的系统状态,并且不会有任何动作被无意地执行多次。
-
无幂等性的情况
比如 P给C转100元,P将转账的指令成功发送到B并且B把指令发送C了,B再发确认消息到P的时候,由于网络问题,P没有收到确认的消息,经过一段时间,P发起重试,C认为这个是条新的消息,会再次发送到C。这种情况会出现P转了200元到C。
大致的流程如下图
幂等性设计注意事项
上面问题可以采用幂等性Key来解决,在设计幂等性Key的时候需要考虑如下几种情况
- Key的唯一性,
- Redis 高可用(如果用Redis用存储Key)
- 接口执行成功了要删除Key
- 有些操作是天然幂等就不要做幂等性校验,幂等性的实现需要耗一定的资源
- 分布式锁的互斥性,安全性,对称性,可靠性以及锁的NPC问题(高并发下的幂等性设计)
幂等性的范围
-
请求层面的幂等性
- 用户重复操作
- 网络波动,可能会引起重复请求
- Nginx,Zuul,GateWay网关等中间件的重试机制
- 定时任务重复执行
- 微服务之间的重试
- 第三方回调比如微信的支付回调接口
- 对外提供的OpenAPI
-
业务层面
-
MQ重复消费
-
一定时间内不能给同一种账号转相同金额
-
并行执行
在多个服务冗余部署的情况下,请求是并发消费的,所以需要将请求从并行转换为串行。
-
-
数据库层面
- INSERT不是幂等性的
- UPDATE–通过WHERE条件控制幂等性,并尽可能少地使用相对值进行操作。
- DELETE–类似地由WHERE条件控制,最大限度地减少相对值的使用
分布式锁解决幂等性
分布式锁通常用于分布式群集中,以提高系统性能和并发性。在分布式系统中,请求通过分布式锁从并行处理转化为串行处理,它用于确保在不同系统中的多过程环境中互斥的特定共享资源。其本质是通过序列化对该资源的请求来避免重复处理,然而,它不能解决请求的幂等性问题,仍然需要控制业务代码中的幂等性。需要在系统外部创建共享存储服务器来存储锁信息
设计
-
互斥锁: 任何时候只有一个客户端可以持有相同的锁。也就是说,锁的存在是全局强一致的。
-
无死锁 :具有锁定失败机制,首先,提供锁服务的系统具有很高的可用性和健壮性。
多节点服务,任何节点停机或网络分区不影响锁的获取;第二个是客户端自动续租和释放锁
-
对称:对于任何锁,锁和解锁必须是同一个客户端。
-
容错:高可用性、高性能。服务本身具有高可用性,系统也很健壮。多节点服务,任何节点停机或网络分区都不会影响锁的获取。
-
可重入:它可以有效地减少死锁的发生。
-
客户端调用很简单。锁的代码高度抽象。
-
提供锁注册的服务本身的稳定性和一致性
-
需要处理锁未能按计划续订租约。例如心跳更新失败、服务启动GC、GC期间的服务暂停时间超过锁的有效时间等。
-
出现假死,TTL 仍在继续。
-
锁的登记。确保锁的注册是原子的,也就是说,确定锁是否存在,并序列化注册。
-
如何在对业务代码的入侵最小的情况下更新锁的租约? CAS 原子性。
延伸阅读
原文地址:https://blog.csdn.net/qq_30621637/article/details/142695109
免责声明:本站文章内容转载自网络资源,如本站内容侵犯了原著者的合法权益,可联系本站删除。更多内容请关注自学内容网(zxcms.com)!