幂等性及技术解决方案

文章目录

  1. 定义幂等性

  2. 为什么需要幂等性
  3. 幂等性设计注意事项
  4. 幂等性的范围
  5. 分布式锁解决幂等性
    1. 设计
  6. 延伸阅读


定义幂等性

简单地说,我们可以多次执行幂等运算而不改变结果或者使用相同的输入参数中被调用多次,则不具有额外效果的操作,也就是多次执行的结果都是一致的。

为什么需要幂等性

 幂等性确保相同的请求会导致相同的系统状态,并且不会有任何动作被无意地执行多次。
  • 无幂等性的情况

    比如 P给C转100元,P将转账的指令成功发送到B并且B把指令发送C了,B再发确认消息到P的时候,由于网络问题,P没有收到确认的消息,经过一段时间,P发起重试,C认为这个是条新的消息,会再次发送到C。这种情况会出现P转了200元到C。

    大致的流程如下图

幂等性设计注意事项

上面问题可以采用幂等性Key来解决,在设计幂等性Key的时候需要考虑如下几种情况

  1. Key的唯一性,
  2. Redis 高可用(如果用Redis用存储Key)
  3. 接口执行成功了要删除Key
  4. 有些操作是天然幂等就不要做幂等性校验,幂等性的实现需要耗一定的资源
  5. 分布式锁的互斥性,安全性,对称性,可靠性以及锁的NPC问题(高并发下的幂等性设计)

幂等性的范围

  1. 请求层面的幂等性

    1. 用户重复操作
    2. 网络波动,可能会引起重复请求
    3. Nginx,Zuul,GateWay网关等中间件的重试机制
    4. 定时任务重复执行
    5. 微服务之间的重试
    6. 第三方回调比如微信的支付回调接口
    7. 对外提供的OpenAPI
  2. 业务层面

    1. MQ重复消费

    2. 一定时间内不能给同一种账号转相同金额

    3. 并行执行

      在多个服务冗余部署的情况下,请求是并发消费的,所以需要将请求从并行转换为串行。

  3. 数据库层面

    1. INSERT不是幂等性的
    2. UPDATE–通过WHERE条件控制幂等性,并尽可能少地使用相对值进行操作。
    3. DELETE–类似地由WHERE条件控制,最大限度地减少相对值的使用

分布式锁解决幂等性

              分布式锁通常用于分布式群集中,以提高系统性能和并发性。在分布式系统中,请求通过分布式锁从并行处理转化为串行处理,它用于确保在不同系统中的多过程环境中互斥的特定共享资源。其本质是通过序列化对该资源的请求来避免重复处理,然而,它不能解决请求的幂等性问题,仍然需要控制业务代码中的幂等性。需要在系统外部创建共享存储服务器来存储锁信息

设计

  1. 互斥锁: 任何时候只有一个客户端可以持有相同的锁。也就是说,锁的存在是全局强一致的。

  2. 无死锁 :具有锁定失败机制,首先,提供锁服务的系统具有很高的可用性和健壮性。

    多节点服务,任何节点停机或网络分区不影响锁的获取;第二个是客户端自动续租和释放锁

  3. 对称:对于任何锁,锁和解锁必须是同一个客户端。

  4. 容错:高可用性、高性能。服务本身具有高可用性,系统也很健壮。多节点服务,任何节点停机或网络分区都不会影响锁的获取。

  5. 可重入:它可以有效地减少死锁的发生。

  6. 客户端调用很简单。锁的代码高度抽象。

  7. 提供锁注册的服务本身的稳定性和一致性

  8. 需要处理锁未能按计划续订租约。例如心跳更新失败、服务启动GC、GC期间的服务暂停时间超过锁的有效时间等。

  9. 出现假死,TTL 仍在继续。

  10. 锁的登记。确保锁的注册是原子的,也就是说,确定锁是否存在,并序列化注册。

  11. 如何在对业务代码的入侵最小的情况下更新锁的租约? CAS 原子性。


    延伸阅读

设计模式——责任链模式-CSDN博客文章浏览阅读1.2k次,点赞22次,收藏11次。链上的每个处理者都有一个成员变量来保存对于下一处理者的引用。如果请求中包含正确的数据, 所有处理者都将执行自己的主要行为, 无论该行为是身份验证还是数据缓存。在这种情况下, 叶组件接收到请求后, 可以将请求沿包含全体父组件的链一直传递至对象树的底部。收到请求后, 每个处理者均可对请求进行处理, 或将其传递给链上的下个处理者。2 . 为了在具体处理者中消除重复的样本代码, 你可以根据处理者接口创建抽象处理者基类。在这种情况下, 你可以对由请求代表的同一个上下文对象执行许多不同的操作。https://blog.csdn.net/qq_30621637/article/details/142657894

如何设计 API: 基本指南 + 最佳实践-CSDN博客文章浏览阅读41次。系统接口是不同组件子系统或系统之间的交互和交换点。它们对于任何系统工程项目的功能、性能和可靠性都是必不可少的。然而,在数字生态系统中,软件解决方案的指数级增长凸显了API在实现无缝集成方面的关键作用,如何设计API带来了常见的挑战,设计系统接口并不是一项简单的任务。它需要仔细考虑系统生命周期中所有利益相关者的需求、期望和约束。在本文中,您将学习为所有利益相关者设计系统接口的最佳实践和方法。设计系统接口的第一步是确定谁是利益相关者即谁调用/使用接口,以及他们接口要求是什么。https://blog.csdn.net/qq_30621637/article/details/142684588

金融行业业务流程指南-三级模型-CSDN博客文章浏览阅读1.3k次,点赞42次,收藏12次。业务事件定义事件名称填写事件名称事件描述对业务事件进行描述触发点描述事件触发所涉及的利益相关方事件类型描述具体的事件类型频率描述事件发生的频率年增长率描述该事件每年发生的预计增长率触发的活动描述事件所触发的活动2. 业务事件与活动映射关系事件填写事件的名称事件触发点填写该事件所需要的触发点事件类型填写事件所属的事件类型触发的活动填写事件所触发的活动,如果触发多个活动,则需全部填写3. 三级模型定义信息。https://blog.csdn.net/qq_30621637/article/details/142486470

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

fajianchen

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值