IT评测·应用市场-qidao123.com

标题: 2 秒杀系统架构 [打印本页]

作者: 铁佛    时间: 2025-1-3 05:39
标题: 2 秒杀系统架构
第一步 思考面对的问题和业务场景
秒杀系统面对的问题: 短时间内并发非常高,如果按照秒杀的并发做相应的承载会造成大量资源的浪费。第二解决超卖的问题。
第二步 思考现在的处境息争决方案
因为秒杀系统属于短时间内的高并发问题,我们不可能使用那么多的硬件资源去摆设对应的承载。而且还有个问题,我们实在并卖不到那么多的商品,只是做一个商品促销的噱头吸引用户到我们的平台来,让他们知道我们的平台并记下我们的平台。
那么也就是说实在大部分用户买不到商品是正常行为,以是我们可以通过这个特性把大部分的用户在服务的上游就过滤掉,而不是公平的竞争有限的商品。基于这个头脑我们对我们的计划举行一些优化。
当我们做了上面的工作之后,还是会有大量的请求涌入到后台服务。因为要解决超卖的问题,我们在买入操作的时候肯定是要给商品的数量加锁。如果请求并发太高,会造成redis分布式锁设置的失效时间失效,也会造成超卖的问题。
我们可以在购买商品,锁库存数量之前再过滤掉一部分请求。例如我们用不加锁的缓存下商品数量,当涌入的人数高出一定数量的时候好比高出商品库存的时候,大概商品库存N倍的时候,后面的请求就不会再进入到后面的处置惩罚逻辑。
我们在一个用户点击购买时,就给用户数量+1,高出一定数量就不让后面的人进入。这个时候有个问题,就是我们的缓存并未加锁,好比我商品库存是100件,由于未加锁,这个时候可能同时涌入300个用户进入购买流程。实在这个问题很轻易解决,我们在这300个人进入购买流程后再加分布式锁,这个时候就能包管加锁的redis不会处问题。
上面的头脑根本上是基于把用户进入到购买流程前只管过滤掉,到真正购买的流程后实在没有那么多的竞争压力,对服务器的压力也减小很多。上面我们用到了很多缓存战略,我们还需要考虑缓存穿透的问题,雪崩的问题等等。这些细节我们在后面的文章中再做讨论,我们接着讲后面的计划
第三 不怕一万就怕万一,我们对系统的可用性做到只管的好
如果我们在秒杀系统中有一些关键的点没考虑到,秒杀系统崩了。结果影响到其他正常的服务怎么办?
我们的解决方案是隔离。把秒杀系统的服务和正常的服务隔离开。我们知道秒杀活动是需要商家参与的,当商家参加秒杀活动的时候,我们在秒杀服务建立和正常业务同样的库表布局,商家参与秒杀的商品数量等信息同步到秒杀系统的库中,这样可以做到完全的物理隔离,即时秒杀系统崩了,其他的业务也能正常运行。
以上是秒杀服务计划中比力重要的几个点。具体的细节涉及到太多,我们不做穷究。

免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。




欢迎光临 IT评测·应用市场-qidao123.com (https://dis.qidao123.com/) Powered by Discuz! X3.4