我对分布式的思考

本文探讨了在高并发场景下,如何通过实现幂等性和使用分布式锁来防止重复消费和资源抢占,确保系统的稳定性和一致性。以扣库存操作和锁座为例,详细解释了如何利用数据库唯一索引和Redis的setnx操作来实现这一目标。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

如何保证重复消费?

保证服务的幂等性

 

例如扣库存操作:

购物车下单接口会扣库存,会传一个sign(唯一的一个数字)。库存会在库存记录表里记录此sign

对于重试的操作,就根据sign从数据库里查询是否有此记录了 就是判断不为空说明是重试操作,就打个日志就可以了,然后返回成功

如果有多个实例同事去扣库存咋办?这就用到了分布式锁了,redis.setnx操作,保证同时只有一个线程(进程)去扣库存

这里的sign一定在数据库里建成唯一的索引

 

包括锁座也要考虑幂等性(重试),多人同时抢占一个座位的情况

每次锁座,都会在锁座 表里插入一条记录,并生成operateId,如果同时锁定多个座位,会在锁座表里生成三条记录,oprateID相同

如何判定重试的情况(幂等性)?在锁座表里 cinemaId,sessionId和seatId是一个唯一的索引,如果重试插入数据库就会catch住这个异常,并根据operateId去锁座表里查是否有数据,有的话就说明是一个请求过来的这是个校验幂等性的操作,就把根据operateId查到的锁座信息返回就行了,如果没查到数据,就说明是不同的请求(不同的线程)锁座的,就报座位已被锁定的异常就可以了)

 

对于抢占的情况,一定要考虑两种情况

1.校验幂等性(我理解的就是同一请求里的重试)

2.资源强占(锁)

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值