开篇

本次专栏要给大家分享的是“如何设计秒杀系统”，专栏共包括15章，本章是第一章。
今天会给大家介绍以下内容：

• 秒杀场景的特征
• 隔离的设计思路
• 分层设计思路
  本章的讲解思路是，提出秒杀场景的特征，也就是理解什么是秒杀。然后介绍在秒杀系统设计的底线，有了底线才能保证进可攻退可守。最后介绍使用哪些方法和手段实现秒杀系统的架构设计，以及本专栏的章节脉络和主要内容。

  秒杀场景的特征

秒杀通常是电商网站定期举办的活动，这个活动有明确的开始和结束时间，而且参与互动的商品是事先定义好的，商品的个数也是有限制的。同时会提供一个秒杀的入口，让用户通过这个入口进行抢购。

总结一下秒杀场景的特点：

• 定时开始，秒杀时大量用户会在同一时间段，抢购同一商品，网站瞬时流量激增。
• 库存有限，秒杀下单数量远远大于库存数量，只有少部分用户能够秒杀成功。
• 操作可靠，秒杀业务流程比较简单，一般就是下订单减库存。库存就是用户争夺的“资源”，实际被消费的“资源”不能超过计划要售出的“资源”，也就是不能被“超卖”。因此要保证数据的一致性，也就是操作可靠。
• 并发量高，在同一时刻访问系统的用户数急剧增加，主要表现在同时读和同时写数据。如何同时处理这些请求，以及如何处理哪些无法响应的请求是对系统的考验。
  如果把上面四个特征进行总结，那就是在很短的时间内，需要支持对稀缺资源进行海量并发读写操作，还要保证这些读写操作的可靠性。

秒杀场景的特征就决定了，秒杀系统与日常系统的不一样。秒杀系统是大流量请求在短时间内集中处理，而日常系统的请求处理更加平滑和平均。秒杀场景不会经常发生，它有实效性，有具体的开始和结束时间。再者秒杀系统是针对具体的商品或者商品分类进行的，资源的范围相对于日常系统来说也比较小。鉴于这些不同点，秒杀系统需要和日常系统需要分开考虑，这就是下面要提到的隔离的设计思路。

隔离的设计思路

由于秒杀活动是有计划的，并且在短时间内会爆发大量的请求。为了不影响日常业务系统的正常运行，我们需要把它和现有的系统做隔离。这样即便秒杀系统出现了问题，也不会影响日常系统的正常工作。要不就“偷鸡不成反失一把米了”，因此在设计秒杀系统的时候可以从以下几个方面来思考隔离的问题。

• 业务隔离
  既然秒杀是一场活动，那它一定和常规的业务不同，我们可以把它当成一个单独的项目来看。在活动开始之前，最好设计一个“热场”。“热场”的形式多种多样，例如：分享活动领优惠卷，领秒杀名额等等。“热场”的形式不重要，重要的是通过它获取一些准备信息。例如：有可能参与的用户数，他们的地域分布，他们感兴趣的商品。为后面的技术架构提供数据支持。别小看这些数据，通过这些数据可以预估出秒杀当天的流量，并发数等信息。而且可以作为压力测试数据来源的一部分，协助测试系统的可用性。

• 应用隔离
  现在应用的部署多采用分布式或者微服务的架构，通过容器和服务编排的方式部署方式比较常见。建议分配给秒杀系统专门的系统资源，来应对高并发。我们可以将原来日常系统中的服务在秒杀系统中复用，也可以为秒杀系统设计专门的服务。众所周知一个系统中包含服务数量，少则几十个，多则上百个。如果为了秒杀系统复制一套，恐怕成本太高。这里需要区分，核心功能、支撑功能和通用功能。对于需要并发读写的功能就是秒杀系统的核心功能，例如：商品详情，下单等。这些功能的服务可以专门提供一套，做水平扩展。针对一些支撑功能和通用功能的服务，例如配置信息，用户评论。建议不做扩展，只需要做好熔断和降级的准备，使之不影响核心功能就好。

• 流量隔离
  前面的特征分析中提到了，秒杀系统会在短时间内迎来巨大流量。如果秒杀系统和日常系统共用一个接入层，那么对应的负载均衡器也会接受海量的请求。无论是硬件负载均衡还是软件负载均衡，其能够承受的流量都是有限制的。超过了这个流量，系统会进行限流操作，将多余的流量置之门外。如果此时因为秒杀系统的流量增加，导致日常系统的流量瓶颈是得不偿失的。所以这里需要对流量进行隔离，如果共用负载均衡需要设置秒杀系统使用的流量上限。根据秒杀系统特有的请求头判断流入的请求是来自秒杀请求还是日常系统请求。同时也可以根据用户ID，请求IP、请求的地域来做隔离。

• 数据隔离
  秒杀活动持续时间短，瞬时数据量大。为了不影响现有数据库的正常业务，可以建立新的库或者表来处理。在秒杀结束以后，需要把这部分数据同步到主业务系统中，或者查询表中。如果数据量特别巨大，到千万级别甚至上亿，建议使用分表或者分库。
  隔离的工作是为了保证日常系统的可用性，是秒杀系统设计的底线，因为谁也不知道海量请求到达的时候会发生什么。即使再有经验的团队都需要了明白系统总是会出问题的，我们要做的就是将问题产生的机率降到最低，让问题的影响范围降到最小。有了隔离做保证，再才能谈如何设计一个秒杀系统。
  
  业务隔离、应用隔离、流量隔离和数据隔离

分层设计思路

说了完了隔离的思路，再来聊聊如何设计秒杀系统。由于秒杀的场景不同，面向的用户数量不同，参与秒杀的资源数量不同，每个公司的现有系统架构千差万别，并且硬件配置和网络环境也各有不同。无法提出一个统一的架构，只能针对秒杀系统中出现的问题进行解决。回到秒杀场景的特征，实际上我们要解决的就是短时间对稀缺资源，高并发读写和结果可靠性的问题。解决这些问题的方法，在平时的系统架构中也会用到，只是在秒杀系统中会更有代表性、更极端。总结下来主要是缓存、限流、熔断、分布式服务、分布式存储、数据一致性、分布式可靠性、系统的监控。但是这些问题涉及到系统架构的方方面面，单独来讲大家都能理解，如何通过系统的方式给大家介绍，能够从架构的角度去看秒杀系统需要考虑哪些问题。这里我们通过架构分层的方式，逐层讲解如何解决秒杀系统的问题。专题总共分来7个部分共15个章节来讲述。最后总结为四横三纵。

• 用户触点：客户端设计。客户端页面设计需要ESI和CSI方法论作为支撑。前端秒杀页面使用专门的页面，这些页面包括静态的HTML和动态的JS，以及如何使用HTTP和CDN缓存减少对应用服务器的访问。
• 流量入口：代理层设计。即使我们扩展再多的应用，使用再多的应用服务器，部署再多的负载均衡器，都会遇到支撑不住海量请求的时候。所以，在这一层我们要考虑的是如何做好流量扩展和流量限制，当超过系统承受范围的时候，需要果断阻止请求的涌入。同时在业务层面可以根据IP，用户名，商品ID对流入秒杀系统的请求进行筛选和控制。并且能够对恶意请求大胆说“不”。并且包括负载均衡算法，限流算法，Nginx实现限流的最佳实践以及OpenResty实现代理层缓存的最佳实践。
• 核心服务：应用层设计。瞬时的海量请求好比请求的“高峰”，我们架构系统的目的就是“削峰”。需要使用服务集群和水平扩展，让“高峰”请求分流到不同的服务器进行处理。同时，还会利用缓存和队列技术减轻应用处理的压力，通过异步请求的方式做到最终一致性。由于是多线程操作，而且商品的额度有限，为了解决超卖的问题，需要考虑进程锁的问题。 同时也会可以使用进程内的缓存保存一些热点数据，针对分布式缓存提供算法和最佳实践。在遇到服务挂掉的情况，需要有检测和熔断机制。
• 数据存储：数据层设计。秒杀活动持续时间短，瞬时数据量大。为了不影响现有数据库的正常业务，可以建立新的库或者表来处理。在秒杀结束以后，需要把这部分数据同步到主业务系统中，或者查询表中。如果数据量特别巨大，到千万级别甚至上亿，建议使用分表或者分库。同时做到读写分离，利用分布式的选举机制保证服务器的高可用。
• 压力测试：当系统上线之前我们需要未雨绸缪，针对即将出现的高并发场景进行演练。根据QPS、TPS、BPS对系统设定运行指标，通过压力测试的方式论和测试工具，探查系统的承载底线。
• 监控系统：系统上线运行以后，需要时刻监控系统的情况并且作出响应的反映。我们会针对监控系统的功能、分类、分层进行详细介绍。而且会针对Zabbix和ELK的最佳实践，让理论结合实践。
• 服务降级：如果说服务一定会遇到问题，那么服务降级就是让问题造成的影响最小化。针对服务不可用的情况设置开关，并且通过ZooKeeper实现开关功能。
  把上面7个方面的描述总结为四横三纵。按照用户请求从外到内，从上到下的方向分别是：客户端、代理层、应用层、数据层。压力测试、监控系统、服务降级作为高可用的保障贯穿四层之中形成三纵。
  
  四横三纵架构设计图

  专栏讲述思路

  专栏每章都会按照提出问题，讲解原理，实践落地的方式进行推进。说白了就是是什么->为什么->怎么办。尽量用大白话讲解复杂的问题。每段理论分析的部分会配上图解的方式帮助大家理解和记忆。因为上面提到的这些知识点，可能在目前还用不上，不过可以先了解，作为知识储备。等需要的时候在回看文章，那么图就是记忆的最好媒介，俗话说一图胜千言。下面我就把每个章节的主题列出来供大家查阅。

  章节目录

• 01 秒杀系统的思考方式与设计思路--左手隔离，右手分层
• 02 秒杀系统的客户端设计需要注意什么？--近水楼台，唾手可得
• 03 如何处理负载均衡和流量过滤？--分而治之，明察秋毫
• 04 详解限流算法和Nginx的最佳实践--月盈则亏，水满则溢
• 05 拒绝超卖！如何解决数据一致性问题？--百舸争流，恰到好处
• 06 订单处理流程详解--队列缓存，竞相登场
• 07 如何加入进程内缓存？--孤芳自赏，百花齐放
• 08 分布式缓存算法与实践--数据分片，最佳体验
• 09 如何妙用熔断机制？--当断则断，不受其乱
• 10 数据存储之读写分离与选举机制--主次有别，日月更迭
• 11 数据分表分库与扩展--纵横分布，有序扩展
• 12 压力测试--盯准目标，挑战极限
• 13 监控系统的分类与分层--天网恢恢，疏而不漏
• 14 ELK与Zabbix的监控最佳实践--软硬结合，密不透风
• 15 服务降级与开关机制--张弛有度，随心切换