转载

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

目录

       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