引入

秒杀就是在同一个时刻有大量的请求争抢购买同一个商品并完成交易的过程。

从整体上看，秒杀主要是要解决两个问题：一个是并发读，一个是并发写

• 并发读的核心优化理念是尽量减少用户到服务端来读数据，或者让它们读更少的数据
• 并发写的处理原则也是一样，它要求我们在数据库层面独立出来一个库，做特殊的处理、

另外，我们还要针对秒杀系统做一些保护，针对意料之外的情况设计兜底方案，以防止最坏的情况发生。

从架构师的角度来看，要想打造并维护一个超大流量并发读写、高性能、高可用的系统，在整个用户请求路径上从浏览量到服务端我们要遵循几个原则，就是要保证用户请求的数据尽量少、请求数尽量少、路径尽量短、依赖尽量少，并且不要有单点。

秒杀的整体架构可以概况为“稳、准、快”

• “稳”，就是整个系统架构要满足高可用，流量符合预期时要稳定，就是超出预期也不能掉链子
• “准”，就是秒杀 10 台 iPhone，那就只能成交 10 台，多一台少一台都不行。一旦库存不对，那平台就要承担损失，所以“准”就是要求保证数据的一致性。
• “快”，就是系统的性能足够高，否则你怎么支撑这
  么大的流量呢？不光是服务端要做极致的性能优化，而且在整个请求链路上都要做协同的优化，每个地方快一点，整个系统就完美了。

所以从技术角度来看“稳、准、快”就对应了架构上的高可用、一致性、高性能的要求。秒杀系统本质上就是一个满足大并发、高性能和高可用的分布式系统

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

要想构建一个超大流量并发读写、高性能以及高可用的系统，需要满足“4要1不要”这几个要素

数据要尽量少

所谓“数据要尽量少”，首先是用户请求的数据能少就少。请求的数据包括上传给系统的数据和系统返回给用户的数据。

为何“数据要尽量少”？因为首先这些数据在网络上传输需要时间，其次不管是请求数据还是返回数据要需要服务器做处理，而服务器在写网络时通常需要压缩和字符编码，这些都非常消耗CPU，所以减少传输的数据量可以尽量减少CPU的使用。比如我们可以简化秒杀页面的大小，去掉不必要的页面装修效果，等等。

其次，“数据要尽量少”还要求系统依赖的数据能少则少，包括系统完成某些业务逻辑需要读取和保存的数据，这些数据一般是和后台服务以及数据库打交道的。调度其他服务会涉及到数据的序列化和反序列化，这也是CPU的一大杀手，同样也会增加延时。而且，数据库本身也容易成为一个瓶颈，所以和数据库打交道越少越好，数据越简单，越小越好

请求数据要尽量少

用户请求的页面返回后，浏览器渲染这个页面还有包含其他额外请求，比如，这个页面依赖的CSS、图片等都是额外请求，这些额外请求要尽量少。因为浏览器每发出一个请求都多少会有一些消耗，比如建立连接需要三次握手，可能有页面依赖或者连接数限制、如果不同请求你域名不一样的话还会涉及DNS解析等。所以，减少请求数可以显著减少资源消耗

路径经历短

所谓“路径”，就是用户发出请求到返回数据这个过程中，需要经过的中间的节点数。

标签：架构设计,请求,系统,并发,秒杀,尽量少,数据
来源： https://blog.csdn.net/zhizhengguan/article/details/121316512