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

目录

       一、秒杀业务的难点

       二、秒杀业务的优化方向

       3.  常见的秒杀架构

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

你们好，我是四九城最豪横的小耳朵。

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

一、 秒杀业务的难点 常见的秒杀场景：

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

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

二、秒杀业务的优化方向 那怎么去优化呢？

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

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

三、常见的秒杀架构 常见的站点架构业务以下：

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

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

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

第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高级工程师学习资料一份。