【今日话题】
处理秒杀活动的解决方案
1、1限流,2库存放在缓存中,b散到N台机器,分散压力 3 每台机器使用concurrentHashmap,4 抢中后,放入队列,异步处理
某台机器挂掉,只影响一部分,不会超发 - 召阳
2、redis也不是万能灵药吧,怎么保证redis可靠性?如果是主从,考虑了延迟造成的数据不一致吗?redis存不下怎么办?redis怎么落地? - tiyee
3、库存预分配。集中处理肯定出问题 - sky
4、秒杀时,总量是确定的,redis容量应该可预估 - 召阳
5、主从? - 菜鸟
6、可以集群,每个节点主从 - 召阳
7、一般先保证容量够存 - 菜鸟
8、我觉得数据一致性这个问题,没必要时刻一致。除非库存是个位数 - sky
9、秒杀也不是只存商品信息啊,用户信息怎么存?怎么保证用户信息跟队列里的用户标识是一致的?万一扛不住了,怎么降级处理?怎么记录日志?- tiyee
10、我们是写入文件中 - 召阳
11、那么写日志文件不就成了瓶颈了吗? - tiyee
12、日志也是异步写吗?- 菜鸟
13、当时怕给生产库造成压力,扔队列的同时,写入文件 - 召阳
14、我的意思是,搞技术不能大而化之,一体秒杀就抛个队列,抛个redis出来就完事了 - tiyee
15、最核心的肯定是redis队列, 要不容易超售, redis只存商品id。 没有单实例扛, 一主多从。 关键是抢, 抢到之后的记录不直接写库, 写异步消息。 - Orc_LaoT
16、redis挂了呢? - tiyee
17、这跟一说分布式存储有人就说一致性hash一样 - 随风而过
18、降级方案当时的设计是 mysql,mc 加锁,每次放多少人过来,先update 再select。>时还是申请的 ssd 的myslq,最后没有用上 - Orc_LaoT
19、一主多存在加redis的sentinel - 随风而过
20、秒杀主要是写,写的是master,再多从也没用 - tiyee
21、挂了自动选主吧 - 随风而过
22、写操作高的时候应该用啥呢 ? - Orc_LaoT
23、归并 - tiyee
24、缓存类的就知道 mc redis pika , mc不落地,pika 纯硬盘还是比 redis 差一点儿。 - Orc_LaoT
25、redis如果数据多,挂了加载非常慢 - tiyee
26、比如秒杀场景 分多个实例分别存一部分商品? 用户来了随机分配? 这样多写? - Orc_LaoT
27、redis的话可以用Twemproxy/Codis方案,pre-sharding+proxy+haproxy - star
28、秒杀的应该数据量有限吧 要不也不叫秒杀了 ,方便说下归并么 或者给个再详细的关键字? 只知道归并排序 - Orc_LaoT
29 、@tiyee 你说的归并具体怎么应用到场景,数据i构是怎样。 - star
30、写入时分配数据标识,均衡或按特征写到不同的实例,后台再异步把实例统一起来,每个实例可以双写 - tiyee
31、实例统一起来 指的是? - Orc_LaoT
32、扫描,根据唯一标识,把数据统一起来 - tiyee
33、写入时分配数据标识,均衡或按特征写到不同的实例->其实就分片,对吧。后台再异步把实例统一起来->聚合? - star
34、每个实例可以双写,是什么意思。你的实例是只单个redis实例还是单个Redis服务实例。 - star
35、其实就是想办法降维 - tiyee
36、后台异步聚合数据不现实吧、聚合之后肯定要进行数据审查。就相当于分而后聚,又要统一处理了。 - star
37、就是漏斗模型、我也比较菜,抛砖引玉了 - tiyee
38、我做过的是codis桶福先分片,再做proxy,再加haproxy。由于加了Proxy的原因,单机性能会下降40%,不过由于本身redis的性能出色和集群的扩展性,方案还是可行的。 - star
39、分片么 ?假设1千万人抢1万商品,将1屯蛉朔值10个片,每个片上分配1000个商品去抢,有可能一个片抢完了另一个片还有货,但是实际上那么短的时间里是察觉不到的,如果有钱多分几片,全用数据库都能 - Paris
40、这个只是收集部停业务处理是收集后处理的 - tiyee
41、redis是弱事务的。不能把秒杀业务放里面。进入redis只是一个队列,表示他有机会买到,最终点击生成订单的时候要做强一致性审查。就好像以前淘宝秒杀,能进偷ト啡弦趁妫但是你手慢点确认订单的时候就提示你已经被秒光啦。- star
42、还有流氓作法,随机踢掉部分用户,直接返回秒光提示 - tiyee
43、判断队列多少么?- 大宋
44、一个点击队列,后期数据审查。一个确认队列。一个商品总库存,一个当前库存。总库存防止确认队列超出情况。当前库存方便停止添加确认队列。 - star
45、还是不理解为什么秒杀会存在超卖的情况。。。。秒杀这种无非是业务层抗不住太大的并发,在业务层之上加一个缓冲区保护壳,慢慢放流量。感觉总是在重复讨论这个。业务层的逻辑限制了,根本不存在超卖的情况 - 廖强
46、秒杀主要是秒杀前的自动扩容以及秒杀后的自动减容,流量预估和预案,涉及整个运维自动化的问题,有的电商公司把秒杀作为一个常态的,对运维的考验很高 - 廖
47、有些超卖是有业务上的考虑的,因为秒到和实际付钱下单之间是有一定数量的差别。而如果人是因为营销手段招揽来的,而不是产品本身好,那这个差别还是不小的。所以有时候业务上会要求超卖 - Paris
48、这是后面处理的,稳定了冲击,慢慢处理 - tiyee
49、强哥 能多说点儿 自动扩容和减容的么? 扩a的对象是什么? --常用的工具有哪些? - Orc_LaoT
50、没有需求谈技术就是空屋建瓴。大家讨论的有一个隐含前题:秒杀之前就已经确定要秒的商品数量,如果要求开始秒之后,能实时看到秒的状a,还能控制秒的频率,再根据这个状况决定商品的数量,怎么做?抛个砖 - Paris
51、收集请求是并行的,再把这些信息变成串行,然后根据业务需求处理 - tiyee