阅读 417

大白话聊聊秒杀系统的优化思路

        目录

       1、秒杀业务的难点

       2、秒杀业务的优化方向

       3.  常见的秒杀架构

       4.  秒杀业务的各层次优化细节
复制代码

大家好,我是四九城最豪横的小耳朵。

今天咱们来用大白话聊聊秒杀系统的优化思路。

1、 秒杀业务的难点 常见的秒杀场景:

京东、淘宝上手机商品的秒杀场景,可能手机只有10部,但瞬时进入的流量可能是几百、甚至几千万。

12306抢票场景,票是有限的,库存只有一份,但是瞬时流量非常多,都去读相同的库存。会造成读写冲突,锁异常严重,这是秒杀业务难的地方。

2、秒杀业务的优化方向 那怎么去优化呢?

(1)将请求尽量拦截在系统上游,不要让锁冲突落到数据库上去。传统秒杀系统之所以挂,是因为请求都压倒了后端数据层,数据读写锁冲突严重,并发高响应慢,几乎所有请求都超时,流量虽大,但是下单成功的有效流量甚小。比如我们常见的购票软件12306,一列火车其实只有2000张票,200w个人来买,基本没有人能买成功,请求有效率为0。

(2)充分利用缓存。秒杀买票,这是一个典型的读多写少的应用场景,大部分请求是车次查询,票查询,下单和支付才是写请求。一趟火车其实只有2000张票,200w个人来买,最多2000个人下单成功,其他人都是查询库存,写比例可能只有0.1%,读比例却占99.9%,这种场景非常适合使用缓存来优化。

3、常见的秒杀架构 常见的站点架构业务如下:

浏览器/手机 -----> 服务 -----> 数据

(1)浏览器/手机端,最上层,会执行到一些JS代码或安卓代码,发送请求给站点 (2)服务层,向上游屏蔽底层数据细节,提供数据访问 (3)数据层,最终的库存是存在这里的,mysql是一个典型

4、秒杀业务的各层次优化细节

第1层:浏览器层、APP层优化

(1)产品层面,用户点击“查询”或者“购票”后,按钮置灰,禁止用户重复提交请求;

(b)JS层面,限制用户在x秒之内只能提交一次请求;

APP层面,可以做类似的事情,虽然你疯狂的在摇微信,其实x秒才向后端发起一次请求。这就是所谓的“将请求尽量拦截在系统上游”,越上游越好,浏览器层,APP层就给拦住,这样就能挡住80%+的请求。

第2层 服务层优化

服务层怎么拦截?如果已经清楚的知道秒杀的手机只有100部,一列火车只有2500张车票,那么你放10w个请求去数据库又有什么意义呢?这种场景下可以使用请求队列来解决。对于写请求,做请求队列,每次只透有限的写请求去数据层。

比如100部手机,只透100个下单请求去db

2500张火车票,只透2500个下单请求去db

如果均成功再放下一批,如果库存不够则队列里的写请求全部返回“已售完”。

对于读请求,怎么优化?可以用缓存抗,redis单机抗个每秒10w完全没什么问题。

这种限流方案,只有非常少的写请求,和非常少的读缓存的请求会透到数据层去,而99.9%的无用请求被拦住了。

当然,业务规则上也可以做一些优化。比如12306的按时间段放票,可以将流量摊匀。

还有,数据粒度也可以做优化。比如你去购票,对于余票查询这个业务,票剩了500张,还是300张,你真的关注么,其实我们关心的是有票和无票罢了,流量大的时候,做一个粗粒度的“有票”“无票”缓存即可。

第3层 最后是数据库层

浏览器拦截了90%,服务层又做了写请求队列与数据缓存,每次透到数据库层的请求都是可控的。db基本就没什么压力了,单机也能扛得住。而且通过对第2次服务层的优化,也保证了请求的有效率。

以上,就是秒杀系统的优化思路。

                      End
复制代码

作者简介:豪横的小耳朵,一个豪横的程序员。想和大家一起在技术的世界里豪横,用技术的眼光去看待世界。欢迎扫描下方二维码,持续关注,一大波原创系列文章正在路上。

关注后回复“666”,可免费获取java高级工程师学习资料一份。

关注下面的标签,发现更多相似文章
评论