秒杀系统设计的学习

先看看秒杀场景特点。秒杀开始前几分钟，大量用户开始进入秒杀商品详情页面，很多人开始频繁刷新秒杀商品详情页，这时秒杀商品详情页访问量会猛增。秒杀开始，大量用户开始抢购，这时创建订单，扣库存压力会显著增大。实际上，秒杀场景基本都是秒杀参与人多，秒杀成功的人却寥寥无几，经常是几十万人或者更多人抢几百个商品库存。

那么我们应该怎么设计秒杀系统的呢？主要涉及以下几个方面：

本文参考文章https://www.jianshu.com/p/67138d889c39编写

一、秒杀业务流程上的考虑

由于参加秒杀的商品售卖价格非常低，基本都是“抢到即赚到”，成功下单后却不付款的情况非常少，所以我们采用下单减库存的方案，下单时扣减库存，然后再进行支付。假如真有个别订单不付款怎么办？没关系，秒杀好活动最主要的目的是吸引流量，个别订单不支付对秒杀活动本身影响不大。况且，没支付剩下的库存还可以作为普通商品继续售卖。不过要注意对机器人和自动脚本的防御，后面会详细介绍。

二、页面静态化

秒杀开始前几分钟，大量用户开始进入秒杀商品详情页面，很多人开始频繁刷新秒杀商品详情页，这时秒杀商品详情页访问量会猛增。如果请求全部打到后端服务，那后端服务的压力会非常大（后端服务要处理业务逻辑，而且还要访问数据库，吞吐量比较低）。

考虑到秒杀是运营人员提前安排的活动，要秒杀哪些商品、商品价格等信息在秒杀活动开始前已经确定下来，所以我们可以把秒杀商品详情页做成静态页面，把商品详情、商品价格等参数、评论评价等信息全部放在这个静态页面里，然后把这个静态页面上传到 CDN 上预热（CDN 是内容分发网络，可以简单理解成互联网上巨大的缓存，用于存放静态页面、图片、视频等，可以显著提高访问速度），用 CDN 扛流量，这样大量的商品详情页的访问请求就不用访问自己的网站（源站）。这样既可以提高访问速度，也没有给网站增加压力，同时也减少了网站带宽压力。

三、请求拦截

1.前端页面

前端页面相关按钮点击后置灰，防止重复提交。

2.网关（zuul，nginx）层

为了避免前端恶意请求，比如一些攻击脚本，在网关层要对下单等接口按 userID 限流，几秒钟只能访问一次。考虑到秒杀场景参与人多，秒杀成功的人极少，我们可以把绝大部分抢购下单请求在网关层直接拒掉，按秒杀失败处理。这样就极大减少了后端服务的压力。

假设秒杀库存是 200 个，我们可以只放行 200 个请求到后端服务。要注意，为了尽量避免库存被机器人和自动脚本抢走，200 个请求不能在秒杀开始瞬间同时放行，可以分段放行，比如秒杀开始后随机选取 100ms 内的 5 个请求放行（这 100ms 内的其他请求直接拒掉，按秒杀失败处理），之后每隔 100ms 放行 5 个请求，4 秒钟可以放行完 200 个请求。分段放行，除了限制了机器人和自动脚本，把请求分散在各个时间段，还进一步缓解了后端服务的压力。

分段放行总时间不能太长，假如每 100ms 放行 1 个请求，放行完所有 200 个请求需要 20 秒时间，这样用户就会明显感知到下单早的人没秒杀成功，下单晚的人反而秒杀成功了，用户体验会变差。

另外，秒杀过程网关压力会比较大，网关可以做成集群，多节点分摊访问压力。

三、后端服务设计

如果秒杀库存只有 200，经过网关拦截，再加上采用分段放行的方式，对于后端服务基本没什么压力了，日常的后端服务就完全可以支撑秒杀活动了。不用再做更复杂的设计。不过，假如秒杀库存有几万个，放行的下单请求就有几万个，为了用户体验放行总时间也不能太长，这时后端服务该怎么设计呢？

1.Redis缓存

Redis的优势：

• 性能极高 – Redis能读的速度是110000次/s,写的速度是81000次/s 。
• 丰富的数据类型 – Redis支持二进制案例的 String, List, Hashe, Set 及 ZSet 数据类型操作。
• 原子 – Redis的所有操作都是原子性的，同时Redis还支持对几个操作合并后的原子性执行。（事务）
• 丰富的特性 – Redis还支持 publish/subscribe, 通知, key 过期等等特性。

这时主要压力就在数据库了，扣减库存压力，创建订单压力。库存可以放到 Reids 缓存中，来提高扣减库存吞吐能力。对于热点商品的库存可以利用 Redis 分片存储。

2.消息队列

消息队列的优点：

• 解耦：将消息写入消息队列，需要消息的系统自己从消息队列中订阅，从而系统不需要做任何修改。
• 异步：将消息写入消息队列，非必要的业务逻辑以异步的方式运行，加快响应速度。
• 削峰：系统慢慢的按照数据库能处理的并发量，从消息队列中慢慢拉取消息。在生产中，这个短暂的高峰期积压是允许的。

创建订单可以走异步消息队列。后端服务接到下单请求，直接放进消息队列，监听服务取出消息后，先将订单信息写入 Redis，每隔 100ms 或者积攒 100 条订单，批量写入数据库一次。前端页面下单后定时向后端拉取订单信息，获取到订单信息后跳转到支付页面。用这种批量异步写入数据库的方式大幅减少了数据库写入频次，从而明显降低了订单数据库写入压力。

四、隔离

1.业务隔离

从业务上把秒杀和日常的售卖区分开来，把秒杀做为营销活动，要参与秒杀的商品需要提前报名参加活动，这样我们就能提前知道哪些商家哪些商品要参与秒杀，可以根据提报的商品提前生成静态页面并上传到 CDN 预热，提报的商品库存也需要提前预热，可以将商品库存在活动开始前预热到 Redis，避免秒杀开始后大量的缓存穿透。

Redis缓存穿透：短时间出现大量请求的key不在Redis缓存（未命中）的情况，这时会产生大量的数据库读取操作，导致数据库压力急剧上升。

2.部署隔离

秒杀相关服务和日常服务要分组部署，不能因为秒杀出问题影响日常售卖业务。可以申请单独的秒杀域名，从网络入口层就开始分流。网关也单独部署，秒杀走自己单独的网关，从而避免日常网关受到影响。秒杀可以复用订单，库存，支付等日常服务，只是需要一些小的改造（比如下单流程走消息队列，批量写入订单库，以及在 Redis 中扣减库存）。

3.数据隔离

为了避免秒杀活动影响到日常售卖业务，Redis 缓存需要单独部署，甚至数据库也需要单独部署！数据隔离后，秒杀剩余的库存怎么办？秒杀活动结束后，剩余库存可以归还到日常库存继续做为普通商品售卖。数据隔离后，秒杀订单和日常订单不在相同的数据库，之后的订单查询怎么展示？可以在创建秒杀订单后发消息到消息队列，日常订单服务采取拉的方式消费消息，这时日常订单服务是主动方，可以采用线程池的方式，根据机器的性能来增加或缩小线程池的大小，控制拉取消息的速度，来控制订单数据库的写入压力。

五、网络

秒杀前要和网络运营商、CDN 服务商提前申请带宽。

六、还有哪些细节要考虑

1.如何避免超卖

• 如果在 redis 中扣减库存，可以利用 decr 命令扣减库存，decr 是原子操作，在分布式环境下也不会有并发问题，decr 扣减库存后，判断返回值，如果返回值小于 0，扣减库存失败，秒杀也就失败了；如果在数据库中扣减库存可以在 where 后面加上库存大于 0 的条件，来避免库存被减成负值。这样就可以避免超卖情况发生了。
• 也可以使用Redis事务实现，使用乐观锁解决这个问题。通过监视Redis中库存的key并且在修改库存时判断key是否改变，如果没有改变则进行修改，反之则修改失败。但是使用Redis事务虽然解决了超卖问题，但是会产生另一个问题（库存遗留问题），这是因为当有一个请求改变了库存key时，由于乐观锁的存在，其他请求全部修改key失败，结果会出现库存没有被抢光的情况。比如一共500个库存数量，现在有2000个人要抢，这时就会产生2000个请求，假设这2000个请求同时生成要求服务器处理，其中有一个请求改变了库存，则其他1999个请求受到乐观锁的限制就不能修改库存，所以最终库存还有499个，导致了库存遗留问题。
• 超卖和上面提到的库存遗留问题可以通过lua脚本解决，lua脚本可以将Redis的几个操作一起执行，中间不受其他操作的影响（实现了原子性）。

2.接口防刷

前面已经提到过，在网关层对下单等接口按 userID 限流。

3.整体限流

网关层除了对 userID 做限流外，还要做整体限流。在实际访问量超过预估访问量时，整体限流可以起到保护作用，避免系统被压垮。

4.防止重复下单

按 userID 限流已经起到了防止重复下单的作用。假如限制同一个用户 10 分钟能下一次单，一般情况下 10 分钟内，商品早已经被抢光了，用户也就没有再次下单的机会了。

5.防止网络攻击

可以在网关层上面再加一层防火墙或者高防服务，来防御 DDos 等分布式网络攻击。

6.连接超时

由于同一时间请求太多，Redis处理不过来，导致有些请求一直等待产生连接超时问题。这个问题可以通过连接池解决。

假设Redis服务器与客户端分处在异地，虽然基于内存的Redis数据库有着超高的性能，但是底层的网络通信却占用了一次数据请求的大量时间，因为每次数据交互都需要先建立连接，假设一次数据交互总共用时30ms，超高性能的Redis数据库处理数据所花的时间可能不到1ms，也即是说前期的连接占用了29ms，连接池则可以实现在客户端建立多个链接并且不释放，当需要使用连接的时候通过一定的算法获取已经建立的连接，使用完了以后则还给连接池，这就免去了数据库连接所占用的时间。