秒杀系统的思考方式与设计思路--左手隔离，右手分层

你们好，我是崔皓。
很高兴有这样一个机会和你们认识。我在IT行业从事软件开发工做十余年了，足迹涵盖企业服务，互联网，企业数字化转型等。工做之余热爱阅读和学习，但愿能经过这个专栏和你们成为朋友。

开篇

本次专栏要给你们分享的是“如何设计秒杀系统”，专栏共包括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 服务降级与开关机制--张弛有度，随心切换