秒杀架构-01秒杀架构设计5原则

秒杀架构-01秒杀架构设计5原则

01 | 秒杀的定义和本质

1、定义

1）秒杀是在同一时刻有大量的请求争抢同一个商品并完成交易的过程，用技术的行话来说就是大量的并发读和并发写。

2、本质

1）秒杀系统本质上就是一个满足大并发、高性能和高可用的分布式系统。

02 | 架构原则：“4要1不要”

1、导读

1）构建一个超大流量并发读写、高性能，以及高可用的系统需要考虑一些要素，现将这些要素总结为“4 要 1 不要”。

2、数据要尽量少

1. 首先是指用户请求的数据能少就少。
	1）请求的数据包括上传给系统的数据和系统返回给用户的数据(通常就是网页)。
2. 其次，还要求系统依赖的数据能少就少。
	2）包括系统完成某些业务逻辑需要读取和保存的数据，这些数据一般是和后台服务以及数据库打交道的。

3、请求数要尽量少

1）用户请求的页面返回后，浏览器渲染这个页面还要包含其他的额外请求（例如，CSS/JS、图片、Ajax）
2）减少请求数最常用的实践就是合并 CSS 和 JS 文件，把多个 JS 文件合并成一个文件。

4、路径要尽量短

1）路径：指用户发出请求到返回数据这个过程中，需要经过的中间节点数。
2）每增加一个连接都会增加新的不确定性。
3）缩短请求路径不仅可以增加可用性，同样可以有效提升性能（减少中间节点可以减少数据的序列化与反序列化），并减少延时（可以减少网络传输耗时）。
4）缩短路径访问的一种方法：将多个相互强依赖的应用合并部署在一起，把远程过程调用（RPC）变成 JVM 内部之间的方法调用。

5、依赖要尽量少

1）依赖：指要完成一次用户请求必须依赖的系统或者服务，这里的依赖指的是强依赖。
2）尽量减少核心系统对非核心系统的强依赖，防止核心系统被非核心系统拖垮。

6、不要有单点

1）单点是系统架构的大忌，单点意味着没有备份、风险不可控。
2）如何避免单点？避免将服务的状态和机器绑定，即把服务无状态化。

7、小结

1）架构是一种平衡的艺术，而最好的架构一旦脱离他所适应的场景，一切都将是空谈。

03 | 不同场景下的不同架构案例

1、不同请求体量下，秒杀系统架构的演进路线

2、简单秒杀系统

1）商品购买页面增加一个“定时上架”功能，仅在秒杀期间可以看到购买按钮。

3、复杂秒杀系统（请求量10w/s）

1）单独打造秒杀系统，方便优化
2）系统部署在独立的集群，防止影响正常商品集群的机器负载
3）热点数据（如库存）放缓存系统
4）增加秒杀答题，防止有秒杀器抢单

4、更加复杂秒杀系统（请求量100w/s）

1）页面进行动静分离
2）服务端对秒杀商品的静态数据（如商品描述信息）进行本地缓存
3）增加系统限流保护，防止最坏情况发生

04 | 小结

1、通用优化思路—“4要1不要”

1）数据要尽量少
2）请求数要尽量少
3）路径要尽量短
4）依赖要尽量少
5）不要有单点

2、注意

1）在不同性能要求的情况下，系统架构应该从哪几个方面去做取舍。
2）越追求极致性能，系统定制开发就会越多，同时系统的通用性也就会越差。
3）架构升级的逻辑要具体问题具体分析，做架构升级主要是分析在预估 QPS 下，整个系统的瓶颈会在什么地方，要针对这些瓶颈重新设计架构方案。
4）10w/s 级别可能瓶颈在数据读取上，增加缓存一般能解决；100w/s 级别可能瓶颈在服务端网络传输上，所以要把大部分的静态数据放到cdn上，甚至缓存在浏览器里。

参考文献：

[1] 许令波. 如何设计一个秒杀系统[M]. 极客时间, 2018.
[2] 图片取自《如何设计一个秒杀系统》专栏