分布式幂等性如何设计?

在高并发场景的架构里,幂等性是必须得保证的。比如说支付功能,用户发起支付,如果后台没有做幂等校验,刚好用户手抖多点了几下,于是后台就可能多次受到同一个订单请求,不做幂等很容易就让用户重复支付了,这样用户是肯定不能忍的。
解决方案:增改

  • 1,查询和删除不在幂等讨论范围,查询肯定没有幂等的说,删除:第一次删除成功后,后面来删除直接返回0,也是返回成功。
  • 2, 建唯—索引:唯—索引或唯—组合索引来防止新增数据存在脏数据(当表存在唯—索引,并发索时新增异常时,再查询一次就可以了,数据应该已经存在了,返回结果即可)。
  • 3,token机制:由于重复点击或者网络重发,或者nginx重发等情况会导致数据被重复提交。前端在数据提交前要向后端服务的申请token,token放到 Redis 或 JVM 内存,token有效时间。提交后后台校验token,同时删除token,生成新的token返回。redis要用删除操作来判断token,删除成功代表token校验通过,如果用select+delete来校验token,存在并发问题,不建议使用。
  • 4,悲观锁悲观锁使用时一般伴随事务一起使用,数据锁定时间可能会很长,根据实际情况选用(另外还要考虑id是否为主键,如果id不是主键或者不是 InnoDB 存储引擎,那么就会出现锁全表)。
分布式系统中的幂等性是指无论对同一个操作进行多次调用,最终的结果都是一致的。设计分布式系统的幂等性有几种常见的方法: 1. 唯一标识符:为每个操作生成一个唯一的标识符,并将该标识符与操作关联起来。在处理请求之前,先检查该标识符是否已经存在,如果存在则说明该操作已经执行过,可以直接返回之前的结果,否则执行操作并保存结果。 2. 乐观锁:在执行操作之前,先查询相关数据的版本号或时间戳。在更新数据时,比较当前版本号或时间戳与之前查询到的版本号或时间戳是否一致,如果一致则执行更新操作,否则拒绝更新。 3. 幂等性检测:在执行操作之前,先查询相关数据的状态。如果数据已经处于目标状态,直接返回结果;如果数据不处于目标状态,则执行相应的操作将其转变为目标状态。这种方法通常需要事务支持。 4. 重试机制:对于幂等性操作,即使发生了网络故障或其他异常情况导致请求失败,也可以通过重试来保证最终结果的一致性。在进行重试时,需要确保请求是幂等的,即多次重试不会产生额外的副作用。 以上方法可以根据具体的业务场景选择适合的方式来设计分布式系统的幂等性。在设计时需考虑并发访问和数据一致性等因素,并合理选择适用的方法来确保系统的正确性和可靠性。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值