设计一个秒杀系统架构的关键点

前言：

秒杀现在大家一点都不陌生，例如淘宝天猫双11、618秒杀活动等，春节前12306网上抢票系统等，其实就是一个时间点，大量用户来抢购一样商品，用专业术语说就是同一时间拥有大量读数据和写数据。你如何设计面对如此高并发操作，服务器又完好无损？如何做到数据一致性？

• 快 ：高性能。

  • 面对高并发操作（主要解决并发读和并发写），要扛得住高流量，不仅服务器要快，访问的整个请求链都要快
  • 解决方案：设计数据库的动静分离，热点的发现与隔离，请求削峰与分层过滤，服务器要做到极致优化。

• 准：一致性。

  • 面对大量的客流量，秒杀多少东西，就交易多少数量，一定要保证数据一致性。
  • 解决方案：针对商品减库存来说：包括（拍下减库存，付款减库存、预扣等），在高并发更新过程中，要保持数据一致。

• 稳：高可用。

  • 整个系统架构要hold的住，最初的目的就是多卖产品，在高并发的情况下也能保住服务器不蹦，厉害！

1.初步想法？

1，限流：前后端都要设置限流，5秒内只能提交一个请求，静态资源可以存放在CDN？
2，后端redis对uuid限流，同样5秒一个请求
3，用户请求放入队列，列队的长度为多少？如果初次下单不成功如何解决？
4，队列满员后如何处理？
5，消费的过程如何处理？线程？当用户下单后，库存是如何消减的？
6，如果支付超时，订单如何处理？

2.高并发系统的几大方向？

1，尽量减少请求数据，目的：减少cpu消耗
2，缩短访问链接，为了减少节点消耗
3，减少强依赖，减少加载时间
4，不要单点操作，要设置集群，防止数据丢失
5，尽量减少页面的数据，减轻服务器压力，避免过多没必要的请求

3.淘宝第一个秒杀实现方式案例：

v1.0:在商品购买页面新添了一个定时上架功能，只有到时间了，用户才能看到购买按钮，直到商品被购空为止。

当用户量从1w/s到10w/s时，服务器就出现瓶颈，如何解决？

v2.0: 打造独立系统、添加集群、设置缓存

修改方案：
1，把秒杀系统独立开发，抽离出来单独打造一个系统，这样就可以有针对性的优化，可以大大减少页面的装修和复杂度。
2，在系统部署上单独做一个机器集群，这样秒杀的大流量就不会影响到正常售卖的商品。
3，设置缓存，将一些热点数据放入缓存系统中，以提高读性能。

修改后的方案可能还是不满足100w/s的请求量，继续修改：方案如下：

v3.0: 在2.0的基础上，采用动静分离

v3.0版：
1，页面动静分离，使得秒杀时不需要刷新整个页面，只需要向服务器请求很少的数据，用户只需要点击抢购按钮就行了。
2，把秒杀的商品存入缓存中，这样用户访问商品时，就不用每次都调用数据库，甚至不需要去缓存集群中查找。
3，增加限流系统保护，时刻防止最坏的事情发生。

---

疑问点？

1，本地缓存，用什么方案？

本地缓存一般是用内存实现，使用java集合类型

2，通过什么方式，往缓存写数据？

订阅的方式，在初始化时加载到内存

3，把库存写入缓存，如何做到即时更新？

一是定时更新
二是主动更新，要接借助组件

4，秒杀的时候，客户端与服务器，集群与服务器之间，结束的时间如何保持同步？

一般由服务端时间为准，服务器也是需要依赖一个时间组件。如ntp（NTP是网络时间协议(Network Time Protocol)，它是用来同步网络中各个计算机的时间的协议。）

6，如何内存数据过多，数据会不会出现溢出情况？

数据不会溢出，一般都会有内存保护机制，一般超过内存空间都会淘汰一部分数据，那淘汰的机制是什么？

优化：实现动静分离，
就是把一些不常用到的数据静态化，当用户发出请求时，访问只是静态页面，而只有点击抢购商品按钮时，才请求到服务器动态数据。
静态数据可以保存在浏览器，也可以保存在CDN，或者服务器都行。
如果数据保存在CDN上，数据是可以主动失效的，而存在浏览器上不行，如果用户不刷新的话，数据不会更新

---

可参考https://blog.csdn.net/u014231523/article/details/82975822