浙江网站备案加急,网站开发教程流程,品牌建设 网站,商标设计创意架构
秒杀系统需要单独部署#xff0c;如果说放在订单服务里面#xff0c;秒杀的系统压力太大了就会影响正常的用户下单。 常用架构#xff1a;
Redis 数据倾斜问题 第一步扣减库存时 假设现在有 10 个商品需要秒杀#xff0c;正常情况下#xff0c;这 10 个商品应该均…架构
秒杀系统需要单独部署如果说放在订单服务里面秒杀的系统压力太大了就会影响正常的用户下单。 常用架构
Redis 数据倾斜问题 第一步扣减库存时 假设现在有 10 个商品需要秒杀正常情况下这 10 个商品应该均匀的分布在 Redis 集群的每个主节点上。商品是通过下图的算法通过商品 id 计算出自己应当在哪个分片并定位到 Redis 的但是可能由于分片算法不太均匀导致这 10 个商品都落到了某一个节点上去。
解决因此我们需要给 Redis 的 key 加一个 hashtag{redis1}这样 Redis 计算分片时就会用 {} 里的数据来计算。
依旧会有问题热点 key 问题假设商品 1 非常火爆10w 个请求都去秒杀商品 1 就会导致其对应的 Redis 扛不住压力。
解决像这种热门商品应当有预判如原价 2000 的商品现在只要 500提前将该商品的库存均匀的分片在多个 Redis 主节点上。当第一个请求进入时先判断该商品是不是热点商品如果是请求第一个分片。当第二个请求进入时先判断该商品是不是热点商品如果是请求第二个分片。
MQ 消息丢失问题 第二步扣减库存后将订单消息发送到 MQ 不同的 MQ 解决方案不同一个简单通用的方案是加一张消息发送表先在消息发送表中记录“待处理”然后再给 MQ 发消息消费者下单服务收到消息生成完订单后回调发送者抢购服务将记录改为“已处理”。
设置一个定时任务隔一段时间去扫描消息发送表如果发现有消息一直没有被处理消息很有可能丢失了那就重发该消息。但是这种方案可能导致消息的重复发送消费者需要做幂等处理。 分布式事务方案 – 最终一致性seata 比较重很多中小型公司采用这种方案 分布式事务方案 – 最终一致性seata 比较重很多中小型公司采用这种方案 消费者如何做幂等处理
如果消费者收到消息时订单号已经生成了那只需要判断一下该订单号是否存在即可如果消费者收到消息时没有订单号订单号是消费者处理消息时通过一些算法雪花生成的就不能直接判断订单号是否存在。 可以生成一个标识唯一消息的业务 id可以在下单逻辑处理的第一行代码加上一把分布式锁。直接用 Redis 实现执行 setnx 命令关键在于 key 的设计。setnx(userId productId, value)同一个用户秒杀同一件商品 key 是一样的。
MQ 消息积压怎么解决
生产者的生产速度远远大于消费者的消费速度就会导致 MQ 消息积压。
增加消费者数量增加消息队列的容量 依旧有可能消息积压因为 Redis 扣减库存的速度比数据库高几个量级。
解决假设消费者拿到一条消息先判断消息的发送时间如果这条消息的发送时间和当前时间已经超过了一个阈值1 分钟那么就认为出现了消息积压则将这些消息直接放入 Redis。用户查询订单信息会先查 Redis再查数据库在 Redis 查到就可以直接返回了。
该消息最终还是得同步到数据库中生成订单同步完后再从 Redis 里面删除。
如果说超时了太久依旧没有被处理就直接丢弃掉该消息提示用户下单失败。
Redis 集群崩溃了如何保证高可用
操作 Redis 时网络不稳定出现瞬断 – 降级 在减库存代码上套一层 try-catch在 catch 里面重试 1、2 次 如果网络瞬断比较长或者 Redis 集群真的崩溃了 – 本地缓存 解决在抢购服务设置一个本地高速缓存 rocksDB将下单请求临时存到 rocksDB 里面。然后设置一个定时任务定时去扫描这个缓存将下单请求重新发送到 Redis 里面。前提是 Redis 集群能够快速恢复
库存超卖
主节点扣减库存成功了但是在同步到从节点前主节点宕机了从节点被选为了新的主节点Redis 与数据库数据也不一致了。
将 Redis 主从异步同步改为同步同步不使用 Redis 主从只用 Redis 集群数据库的数据已经为 0 了生成订单不成功
回答
使用并发控制来确保扣减的原子性 — 影响性能在高并发场景下可以将库存提前预热到 Redis 中利用 Redis 的原子操作指令扣减库存后续对于库存的扣减只操作 Redis如果某个商品的访问量比较大我们可以对这个商品的库存进行拆分把不同的库存放进不同的库里面后续对单个数据加锁
