秒杀下单再思考 - 由reids数据倾斜问题如何解决引发的思考

问题背景：用db扣减库存+redis.lock解决超卖问题，并发量并不能提很高，考虑redis中扣减库存，秒杀方案：redis.get(productId)得到商品库存，库存小于1，秒杀失败；redis.decr(key,1)，lockCount<0，redis.incr(key)+秒杀失败，redis集群，这个时候假设数据在redis主结点均匀分配，我们的方案是redis读写混合，单结点撑死可以承受2-3w/s并发，那redis的主结点足够多，是可以达到每秒10w的并发量，但是会有数据倾斜问题，那如何解决数据倾斜问题？
所以今天文章探讨：
1：基于redis与mq实现秒杀下单
2：解决mq下单消费幂等机制
3：线上百万秒杀订单发生积压如何处理
4：redis集群崩溃时如何保证秒杀系统高可用
5：redis主从切换导致库存异常以及超卖问题
6：mq集群崩溃时如何保证秒杀系统高可用
7：秒杀系统中redis和mq如何保证事务一致性
8：秒杀系统限流防刷防攻击静态页面等方案

八股文解决方案：

针对秒杀商品，说白了，针对预热商品分配不集中的情况，缓存预热的时候，每个热点商品要放到哪个结点，是要解决的，结点数据迁移命令把数据挪均匀，超高秒发的商品，保证不会数据倾斜。简易解决方法是：正常商品分布时，slot=CRC16(key)%16384,在key上加一个hashTag，hashTag参与计算定位redis槽点，后面我会更新redis集群架构。还有一种情况，针对单个热点商品，10w并发集中在一个商品上，怎么提高并发量呢？假设这个热点商品，库存1000，在做缓存预热的时候，直接把库存的缓存拆开来，不同的分片放到不同的redis结点上，第一片库存333，第二片333，第三片333，做负载均衡策略，第一个请求到第一个分片所在的redis主结点，依次类推，请求的地方要实现负载均衡的策略，key要再拼接1、2、3这种，实现一个简易的负载均衡，这个架构可以抗住更高的并发。

mq问题：
1.mq不丢消息+mq消费幂等：根据mq方案来，每种mq都有消息0丢失的方案，rocketMQ保证消息0丢失的方案，最简单的是发送MQhalf方案，本地存放消息发送表，发送订单消息成功了，本地消息表写上：库存扣减成功，订单生成待处理，mq的发送方起一个定时任务，轮询本地消息表，存在订单生成待处理状态的消息，就向mqserver发送half消息，当mqconsumer接收到这条消息，去生成订单，记录生成订单的动作到本地消息表，记录已生成订单，再去向mqserver回复执行结果，如果comsumer执行成功，mqserver就给producer发送执行成功的结果，producer修改本地消息表的对应记录状态为：库存扣减成功，订单生成已处理。–待核实
2：幂等性其他保证方案：
消息id
业务主键：用户id+商品id+场次id 构成一个业务主键
配合使用setnx ，保证幂等性，并设置过期时间，半个小时差不多了
3：消息积压：
如果是rabbitMQ
设置参数能够在一定程度上调整每个消费者实例的吞吐量

# 单次推送消息数量
spring.rabbitmq.listener.simple.prefetch=1
# 消费者的消费线程数量
spring.rabbitmq.listener.simple.concurrency=5

紧急情况：紧急上线一个消费者组，专门用来将消息快速转录。保存到数据库或者Redis，然后再慢慢进行处理
如果是rocketMQ，
1：追踪mq消息是否积压除了web控制台看，还可以可以通mqadmin指令在后台检查各个Topic的消息延迟情况。另外还有RocketMQ也会在他的 ${storePathRootDir}/config 目录下落地一系列的json文件，也可以用来跟踪消息积压情况
2：消息发送的时间和当前接收消息处理的时间相差1分钟的，对这种消息，不再往db插了，直接插redis，redis通过定时任务同步到db去；取订单信息的时候先从db取，db取不到就从redis取。
3：从产品设计角度来说，当消息发送时间和当前接收消息处理的事件超过一分钟，消息直接丢掉，redis同步把库存恢复，前端轮询时间设置成2分钟，轮询不到订单信息，直接提示下单失败，请重试，实现一个快速失败

[redis集群架构 ] redis集群如何给预热数据分片
[half消息] half消息处理扣减库存和生成订单提高mq如何处理
[MQ服务异常宕机] 恢复索引文件,同步刷盘以及异步刷盘机制

【秒杀下单再思考】相关推荐

重读GPDB 和 TiDB 论文引发的 HTAP 数据库再思考
为什么要再思考? 大家好,我是阿福,之前我在社区 Paper Reading 活动中分享了 Greenplum 团队在 2021年 SIGMOD 上发表的论文:<Greenplum: A Hyb ...
Redis实战11-实现优惠券秒杀下单
本篇,咱们来实现优惠券秒杀下单功能.通过本篇学习,我们将会有如下收获: 1:优惠券领券业务逻辑: 2:分析在高并发情况下,出现超卖问题产生的原因: 3:解决超卖问题两种方案:版本号法及CAS法 4:乐 ...
EventBus/EventQueue 再思考
EventBus/EventQueue 再思考 Intro 之前写过两篇文章,造轮子系列的 EventBus/ EventQueue,回想起来觉得当前的想法有点问题,当时对 EvenStore 可能有 ...
2d 蓝图_“蓝图”卷积--对深度可分离卷积的再思考
论文:Rethinking Depthwise Separable Convolutions: How Intra-Kernel Correlations Lead to Improved Mobil ...
任何举动之前，先思考，思考，再思考
任何举动之前,先思考,思考,再思考--<Windows用户态程序高效排错>之读书笔记之所以会读<Windows用户态程序高效排错>这本书,是因为某个卖存储的技术大拿不停地给我 ...
论文解读二十七：文本行识别模型的再思考
摘要:本文研究了两个解码器(CTC[1]和 Transformer[2])和三个编码器模块(双向LSTM[3].Self-Attention[4]和GRCL[5]),通过大量实验在广泛使用的场景和手写 ...
SPOOLing技术的再思考
SPOOLing技术的再思考 @(OS) 首先看什么是SPOOLing. Simultaneous Peripheral Operation On-Line 通过这个名称基本上就可以知道很多事情.外部 ...
光通信的再思考：5G流量爆发下的数据密度革命
来源:未来智库 1.投资要件区别于市场的观点: (1)市场对 5G 时代流量爆发的认知不足.市场认为当前大带宽高流量新应用的爆发趋势尚不明显,当前流量增长需求不清.我们认为,5G 时代的流量的爆发将 ...
关于第一型曲面积分的再思考
关于第一型曲面积分的再思考 @(微积分) 有些问题,看着复杂,却很好解.同样,有些问题看着很简单,但是却很难下手.举一个关于第一型曲面积分计算的例子. 第一型曲面积分基础解法要干三件事: 投影代入 ...

【秒杀下单再思考】

秒杀下单再思考 - 由reids数据倾斜问题如何解决引发的思考

【秒杀下单再思考】相关推荐

最新文章

热门文章

【秒杀下单再思考 】

秒杀下单再思考 - 由reids数据倾斜问题如何解决引发的思考

【秒杀下单再思考 】相关推荐

最新文章

热门文章

【秒杀下单再思考】

【秒杀下单再思考】相关推荐