秒杀技术选型

钟主华 发布于 2016/06/30 18:23
阅读 1K+
收藏 17
一、控制库存的技术选型有五个选择
(1)mysql乐观锁
(2)mysql悲观锁
(3)redis的原子操作incr
(4)redis的watch(redis乐观锁)
(5)redis执行lua脚本
二、测试结果(8核16G,300个线程并发,每次消耗一个库存)
库存(个) redis的LUA(ms)   redis的INCR(ms)    redis的WATCH(ms)  mysql悲观锁(ms)  mysql乐观锁(ms)
1000 126       105.2 8659.8        1710        92260
10000 522       290.6 89410        6934        1368600
100000 3677       1912.4 941079      62875  耗时太长,没测试到具体数据
三、推荐方案
推荐使用redis+LUA的方式实现。
(1)mysql乐观锁,在高并发的情况下会导致大量的无效请求,同时对mysql数据库的性能造成影响,导致系统吞吐的急剧下降。
(2)mysql悲观锁,在高并发下虽然执行的总体耗时不会太长,但是会导致用户长时间等待,并且不释放数据库的连接,导致其他业务拿不到数据库连接。
(3)redis的watch跟mysql的乐观锁有同样的问题,会导致大量无效的请求,进而导致正常请求。
(4)redis的原子操作,incr在压测看起来是效果最好的。但是因为是先减库存然后不过库存不足的时候再回滚当前操作,所以会造成库存抖动,用户体验会不太好。主要原始是incr和lua的方式其实原理是相同的,会比lua快是因为它只执行单一的incr操作,判断在client端,并且client端是多线程去执行的,但是redis确实单线程执行。
(5)redis+LUA,这个是最理想的状态。
加载中
0
skyim
skyim
1.最后一种redis+LUA 不太明白,能够详细解释一下 还有上面的时间是库存减到零的时间吗?
0
bastetwang
bastetwang
这种还是用sql吧,有事务保证,锁的话分表分库减少冲突即可。
钟主华
钟主华
库存没法分表分库,如果分了逻辑会剧复杂,而且速度也跟不上!
0
sss6666
sss6666
我开发的一个秒杀系统就是采用了redis incr的方式。另外之前研究了nginx+lua+redis的方式,感觉也挺靠谱,而且性能更高。
sss6666
sss6666
BTW,mysql可能扛不住啊
0
IdleMan
IdleMan
求教 常规的秒杀 库存量上限能达到多少?
IdleMan
IdleMan
回复 @钟主华 : ok
钟主华
钟主华
不同业务差别会很远的,譬如小米手机抢购可能一批是10万,京东的秒杀可能一次就100个库存的商品。主要看业务是什么!
0
乌龟壳
乌龟壳
秒杀不用每次都查数据库吧,网页给个随机概率不查数据库直接返回失败,也不失公平性。
0
geminiblue
geminiblue
秒杀这种不都是前端库存预分配,然后后端异步操作么?
0
geminiblue
geminiblue

当然这个前端不是指什么html ajax之类的,指redis,ssdb等,秒杀前读redis加库存判断,秒杀指令扔队列

钟主华
钟主华
跟你说的基本差不多,库存确实是通过redis控制,防止超发。
0
巴林的狗尾草
巴林的狗尾草
看到你有个数据库,那么你的秒杀的设计就有问题,这种高并发的资源竞争,最好采用预分配
巴林的狗尾草
巴林的狗尾草
回复 @钟主华 : 不会存在热点机器的问题的吧,按说请求应该是基本均匀的,只要数据足够大,市面上常见的loadblance方案都是均衡的啊
钟主华
钟主华
这只是在做几种方式技术选型的对比,并不是说一定要用数据库,预分配不利于总库存的显示,会出现热点机器消耗比非热点机器消耗快的问题。
0
h
ht307
秒杀吗,一句话,抢到了不一定下单,下单不一定付款,计算这么严格的库存有用吗?
钟主华
钟主华
不排除有这可能,秒杀的两个话题,1是高并发,2是防外挂。你说的是防外挂的问题。
返回顶部
顶部