一个秒杀系统的设计思考

前言

秒杀你们都不陌生。自2011年首次出现以来，不管是双十一购物仍是 12306 抢票，秒杀场景已随处可见。简单来讲，秒杀就是在同一时刻大量请求争抢购买同一商品并完成交易的过程。从架构视角来看，秒杀系统本质是一个高性能、高一致、高可用的三高系统。而打造并维护一个超大流量的秒杀系统须要进行哪些关注，就是本文讨论的话题。

总体思考

首先从高维度出发，总体思考问题。秒杀无外乎解决两个核心问题，一是并发读，一是并发写，对应到架构设计，就是高可用、一致性和高性能的要求。关于秒杀系统的设计思考，本文即基于此 3 层依次推动，简述以下——

• 高性能。 秒杀涉及高读和高写的支持，如何支撑高并发，如何抵抗高IOPS？核心优化理念实际上是相似的：高读就尽可能"少读"或"读少"，高写就数据拆分。本文将从动静分离、热点优化以及服务端性能优化 3 个方面展开
• 一致性。 秒杀的核心关注是商品库存，有限的商品在同一时间被多个请求同时扣减，并且要保证准确性，显而易见是一个难题。如何作到既很少又很多？本文将从业界通用的几种减库存方案切入，讨论一致性设计的核心逻辑
• 高可用。 大型分布式系统在实际运行过程当中面对的工况是很是复杂的，业务流量的突增、依赖服务的不稳定、应用自身的瓶颈、物理资源的损坏等方方面面都会对系统的运行带来大大小小的的冲击。如何保障应用在复杂工况环境下还能高效稳定运行，如何预防和面对突发问题，系统设计时应该从哪些方面着手？本文将从架构落地的全景视角进行关注思考

高性能

1 动静分离

你们可能会注意到，秒杀过程当中你是不须要刷新整个页面的，只有时间在不停跳动。这是由于通常都会对大流量的秒杀系统作系统的静态化改造，即数据意义上的动静分离。动静分离三步走：一、数据拆分；二、静态缓存；三、数据整合。

1.1 数据拆分

动静分离的首要目的是将动态页面改形成适合缓存的静态页面。所以第一步就是分离出动态数据，主要从如下 2 个方面进行：

1. 用户。用户身份信息包括登陆状态以及登陆画像等，相关要素能够单独拆分出来，经过动态请求进行获取；与之相关的广平推荐，如用户偏好、地域偏好等，一样能够经过异步方式进行加载
2. 时间。秒杀时间是由服务端统一管控的，能够经过动态请求进行获取

这里你能够打开电商平台的一个秒杀页面，看看这个页面里都有哪些动静数据。

1.2 静态缓存

分离出动静态数据以后，第二步就是将静态数据进行合理的缓存，由此衍生出两个问题：一、怎么缓存；二、哪里缓存

1.2.1 怎么缓存

静态化改造的一个特色是直接缓存整个 HTTP 链接而不是仅仅缓存静态数据，如此一来，Web 代理服务器根据请求 URL，能够直接取出对应的响应体而后直接返回，响应过程无需重组 HTTP 协议，也无需解析 HTTP 请求头。而做为缓存键，URL惟一化是必不可少的，只是对于商品系统，URL 自然是能够基于商品 ID 来进行惟一标识的，好比淘宝的 https://item.taobao.com/item....。

1.2.2 哪里缓存

静态数据缓存到哪里呢？能够有三种方式：一、浏览器；二、CDN ；三、服务端。

浏览器固然是第一选择，但用户的浏览器是不可控的，主要体如今若是用户不主动刷新，系统很难主动地把消息推送给用户（注意，当讨论静态数据时，潜台词是 “相对不变”，言外之意是 “可能会变”），如此可能会致使用户端在很长一段时间内看到的信息都是错误的。对于秒杀系统，保证缓存能够在秒级时间内失效是不可或缺的。

服务端主要进行动态逻辑计算及加载，自己并不擅长处理大量链接，每一个链接消耗内存较多，同时 Servlet 容器解析 HTTP 较慢，容易侵占逻辑计算资源；另外，静态数据下沉至此也会拉长请求路径。

所以一般将静态数据缓存在 CDN，其自己更擅长处理大并发的静态文件请求，既能够作到主动失效，又离用户尽量近，同时规避 Java 语言层面的弱点。须要注意的是，上 CDN 有如下几个问题须要解决：

1. 失效问题。任何一个缓存都应该是有时效的，尤为对于一个秒杀场景。因此，系统须要保证全国各地的 CDN 在秒级时间内失效掉缓存信息，这实际对 CDN 的失效系统要求是很高的
2. 命中率问题。高命中是缓存系统最为核心的性能要求，否则缓存就失去了意义。若是将数据放到全国各地的 CDN ，势必会致使请求命中同一个缓存的可能性下降，那么命中率就成为一个问题

所以，将数据放到全国全部的 CDN 节点是不太现实的，失效问题、命中率问题都会面临比较大的挑战。更为可行的作法是选择若干 CDN 节点进行静态化改造，节点的选取一般须要知足如下几个条件：

1. 临近访问量集中的地区
2. 距离主站较远的地区
3. 节点与主站间网络质量良好的地区

基于以上因素，选择 CDN 的二级缓存比较合适，由于二级缓存数量偏少，容量也更大，访问量相对集中，这样就能够较好解决缓存的失效问题以及命中率问题，是当前比较理想的一种 CDN 化方案。部署方式以下图所示：

1.3 数据整合

分离出动静态数据以后，前端如何组织数据页就是一个新的问题，主要在于动态数据的加载处理，一般有两种方案：ESI（Edge Side Includes）方案和 CSI（Client Side Include）方案。

1. ESI 方案：Web 代理服务器上请求动态数据，并将动态数据插入到静态页面中，用户看到页面时已是一个完整的页面。这种方式对服务端性能要求高，但用户体验较好
2. CSI 方案：Web 代理服务器上只返回静态页面，前端单独发起一个异步 JS 请求动态数据。这种方式对服务端性能友好，但用户体验稍差

1.4 小结

动静分离对于性能的提高，抽象起来只有两点，一是数据要尽可能少，以便减小不必的请求，二是路径要尽可能短，以便提升单次请求的效率。具体方法其实就是基于这个大方向进行的。

2 热点优化

热点分为热点操做和热点数据，如下分开进行讨论。

2.1 热点操做

零点刷新、零点下单、零点添加购物车等都属于热点操做。热点操做是用户的行为，很差改变，但能够作一些限制保护，好比用户频繁刷新页面时进行提示阻断。

2.2 热点数据

热点数据的处理三步走，一是热点识别，二是热点隔离，三是热点优化。

2.2.1 热点识别

热点数据分为静态热点和动态热点，具体以下：

1. 静态热点：可以提早预测的热点数据。大促前夕，能够根据大促的行业特色、活动商家等纬度信息分析出热点商品，或者经过卖家报名的方式提早筛选；另外，还能够经过技术手段提早预测，例如对买家天天访问的商品进行大数据计算，而后统计出 TOP N 的商品，便可视为热点商品
2. 动态热点：没法提早预测的热点数据。冷热数据每每是随实际业务场景发生交替变化的，尤为是现在直播卖货模式的兴起——带货商临时作一个广告，就有可能致使一件商品在短期内被大量购买。因为此类商品平常访问较少，即便在缓存系统中一段时间后也会被逐出或过时掉，甚至在db中也是冷数据。瞬时流量的涌入，每每致使缓存被击穿，请求直接到达DB，引起DB压力过大

所以秒杀系统须要实现热点数据的动态发现能力，一个常见的实现思路是：

1. 异步采集交易链路各个环节的热点 Key 信息，如 Nginx采集访问URL或 Agent 采集热点日志（一些中间件自己已具有热点发现能力），提早识别潜在的热点数据
2. 聚合分析热点数据，达到必定规则的热点数据，经过订阅分发推送到链路系统，各系统根据自身需求决定如何处理热点数据，或限流或缓存，从而实现热点保护

须要注意的是：

1. 热点数据采集最好采用异步方式，一方面不会影响业务的核心交易链路，一方面能够保证采集方式的通用性
2. 热点发现最好作到秒级实时，这样动态发现才有意义，实际上也是对核心节点的数据采集和分析能力提出了较高的要求

2.2.2 热点隔离

热点数据识别出来以后，第一原则就是将热点数据隔离出来，不要让 1% 影响到另外的 99%，能够基于如下几个层次实现热点隔离：

1. 业务隔离。秒杀做为一种营销活动，卖家须要单独报名，从技术上来讲，系统能够提早对已知热点作缓存预热
2. 系统隔离。系统隔离是运行时隔离，经过分组部署和另外 99% 进行分离，另外秒杀也能够申请单独的域名，入口层就让请求落到不一样的集群中
3. 数据隔离。秒杀数据做为热点数据，能够启用单独的缓存集群或者DB服务组，从而更好的实现横向或纵向能力扩展

固然，实现隔离还有不少种办法。好比，能够按照用户来区分，为不一样的用户分配不一样的 Cookie，入口层路由到不一样的服务接口中；再好比，域名保持一致，但后端调用不一样的服务接口；又或者在数据层给数据打标进行区分等等，这些措施的目的都是把已经识别的热点请求和普通请求区分开来。

2.2.3 热点优化

热点数据隔离以后，也就方便对这 1% 的请求作针对性的优化，方式无外乎两种：

1. 缓存：热点缓存是最为有效的办法。若是热点数据作了动静分离，那么能够长期缓存静态数据
2. 限流：流量限制更可能是一种保护机制。须要注意的是，各服务要时刻关注请求是否触发限流并及时进行review

2.2.4 小结

数据的热点优化与动静分离是不同的，热点优化是基于二八原则对数据进行了纵向拆分，以便进行针对性地处理。热点识别和隔离不只对“秒杀”这个场景有意义，对其余的高性能分布式系统也很是有参考价值。

3 系统优化

对于一个软件系统，提升性能能够有不少种手段，如提高硬件水平、调优JVM 性能，这里主要关注代码层面的性能优化——

1. 减小序列化：减小 Java 中的序列化操做能够很好的提高系统性能。序列化大部分是在 RPC 阶段发生，所以应该尽可能减小 RPC 调用，一种可行的方案是将多个关联性较强的应用进行 “合并部署”，从而减小不一样应用之间的 RPC 调用（微服务设计规范）
2. 直接输出流数据：只要涉及字符串的I/O操做，不管是磁盘 I/O 仍是网络 I/O，都比较耗费 CPU 资源，由于字符须要转换成字节，而这个转换又必须查表编码。因此对于经常使用数据，好比静态字符串，推荐提早编码成字节并缓存，具体到代码层面就是经过 OutputStream() 类函数从而减小数据的编码转换；另外，热点方法toString()不要直接调用ReflectionToString实现，推荐直接硬编码，而且只打印DO的基础要素和核心要素
3. 裁剪日志异常堆栈：不管是外部系统异常仍是应用自己异常，都会有堆栈打出，超大流量下，频繁的输出完整堆栈，只会加重系统当前负载。能够经过日志配置文件控制异常堆栈输出的深度
4. 去组件框架：极致优化要求下，能够去掉一些组件框架，好比去掉传统的 MVC 框架，直接使用 Servlet 处理请求。这样能够绕过一大堆复杂且用处不大的处理逻辑，节省毫秒级的时间，固然，须要合理评估你对框架的依赖程度

4 总结一下

性能优化须要一个基准值，因此系统还须要作好应用基线，好比性能基线（什么时候性能忽然降低）、成本基线（去年大促用了多少机器）、链路基线（核心流程发生了哪些变化），经过基线持续关注系统性能，促使系统在代码层面持续提高编码质量、业务层面及时下掉不合理调用、架构层面不断优化改进。

一致性

秒杀系统中，库存是个关键数据，卖不出去是个问题，超卖更是个问题。秒杀场景下的一致性问题，主要就是库存扣减的准确性问题。

1 减库存的方式

电商场景下的购买过程通常分为两步：下单和付款。“提交订单”即为下单，“支付订单”即为付款。基于此设定，减库存通常有如下几个方式：

1. 下单减库存。买家下单后，扣减商品库存。下单减库存是最简单的减库存方式，也是控制最为精确的一种
2. 付款减库存。买家下单后，并不当即扣减库存，而是等到付款后才真正扣减库存。但由于付款时才减库存，若是并发比较高，可能出现买家下单后付不了款的状况，由于商品已经被其余人买走了
3. 预扣库存。这种方式相对复杂一些，买家下单后，库存为其保留必定的时间（如 15 分钟），超过这段时间，库存自动释放，释放后其余买家能够购买

可以看到，减库存方式是基于购物过程的多阶段进行划分的，但不管是在下单阶段仍是付款阶段，都会存在一些问题，下面进行具体分析。

2 减库存的问题

2.1 下单减库存

优点：用户体验最好。下单减库存是最简单的减库存方式，也是控制最精确的一种。下单时能够直接经过数据库事务机制控制商品库存，因此必定不会出现已下单却付不了款的状况。

劣势：可能卖不出去。正常状况下，买家下单后付款几率很高，因此不会有太大问题。但有一种场景例外，就是当卖家参加某个促销活动时，竞争对手经过恶意下单的方式将该商品所有下单，致使库存清零，那么这就不能正常售卖了——要知道，恶意下单的人是不会真正付款的，这正是 “下单减库存” 的不足之处。

2.2 付款减库存

优点：必定实际售卖。“下单减库存” 可能致使恶意下单，从而影响卖家的商品销售， “付款减库存” 因为须要付出真金白银，能够有效避免。

劣势：用户体验较差。用户下单后，不必定会实际付款，假设有 100 件商品，就可能出现 200 人下单成功的状况，由于下单时不会减库存，因此也就可能出现下单成功数远远超过真正库存数的状况，这尤为会发生在大促的热门商品上。如此一来就会致使不少买家下单成功后却付不了款，购物体验天然是比较差的。

2.3 预扣库存

优点：缓解了以上两种方式的问题。预扣库存实际就是“下单减库存”和 “付款减库存”两种方式的结合，将两次操做进行了先后关联，下单时预扣库存，付款时释放库存。

劣势：并无完全解决以上问题。好比针对恶意下单的场景，虽然能够把有效付款时间设置为 10 分钟，但恶意买家彻底能够在 10 分钟以后再次下单。

2.4 小结

减库存的问题主要体如今用户体验和商业诉求两方面，其本质缘由在于购物过程存在两步甚至多步操做，在不一样阶段减库存，容易存在被恶意利用的漏洞。

3 实际如何减库存

业界最为常见的是预扣库存。不管是外卖点餐仍是电商购物，下单后通常都有个 “有效付款时间”，超过该时间订单自动释放，这就是典型的预扣库存方案。但如上所述，预扣库存还须要解决恶意下单的问题，保证商品卖的出去；另外一方面，如何避免超卖，也是一个痛点。

1. 卖的出去：恶意下单的解决方案主要仍是结合安全和反做弊措施来制止。好比，识别频繁下单不付款的买家并进行打标，这样能够在打标买家下单时不减库存；再好比为大促商品设置单人最大购买件数，一人最多只能买 N 件商品；又或者对重复下单不付款的行为进行次数限制阻断等
2. 避免超卖：库存超卖的状况实际分为两种。对于普通商品，秒杀只是一种大促手段，即便库存超卖，商家也能够经过补货来解决；而对于一些商品，秒杀做为一种营销手段，彻底不容许库存为负，也就是在数据一致性上，须要保证大并发请求时数据库中的库存字段值不能为负，通常有多种方案：一是在经过事务来判断，即保证减后库存不能为负，不然就回滚；二是直接设置数据库字段类型为无符号整数，这样一旦库存为负就会在执行 SQL 时报错；三是使用 CASE WHEN 判断语句——

UPDATE item SET inventory = CASE WHEN inventory >= xxx THEN inventory-xxx ELSE inventory END

业务手段保证商品卖的出去，技术手段保证商品不会超卖，库存问题历来就不是简单的技术难题，解决问题的视角是多种多样的。

4 一致性性能的优化

库存是个关键数据，更是个热点数据。对系统来讲，热点的实际影响就是 “高读” 和 “高写”，也是秒杀场景下最为核心的一个技术难题。

4.1 高并发读

秒杀场景解决高并发读问题，关键词是“分层校验”。即在读链路时，只进行不影响性能的检查操做，如用户是否具备秒杀资格、商品状态是否正常、用户答题是否正确、秒杀是否已经结束、是否非法请求等，而不作一致性校验等容易引起瓶颈的检查操做；直到写链路时，才对库存作一致性检查，在数据层保证最终准确性。

所以，在分层校验设定下，系统能够采用分布式缓存甚至LocalCache来抵抗高并发读。即容许读场景下必定的脏数据，这样只会致使少许本来无库存的下单请求被误认为是有库存的，等到真正写数据时再保证最终一致性，由此作到高可用和一致性之间的平衡。

实际上，分层校验的核心思想是：不一样层次尽量过滤掉无效请求，只在“漏斗” 最末端进行有效处理，从而缩短系统瓶颈的影响路径。

4.2 高并发写

高并发写的优化方式，一种是更换DB选型，一种是优化DB性能，如下分别进行讨论。

4.2.1 更换DB选型

秒杀商品和普通商品的减库存是有差别的，核心区别在数据量级小、交易时间短，所以可否把秒杀减库存直接放到缓存系统中实现呢，也就是直接在一个带有持久化功能的缓存中进行减库存操做，好比 Redis？

若是减库存逻辑很是单一的话，好比没有复杂的 SKU 库存和总库存这种联动关系的话，我的认为是彻底能够的。但若是有比较复杂的减库存逻辑，或者须要使用到事务，那就必须在数据库中完成减库存操做。

4.2.2 优化DB性能

库存数据落地到数据库实现实际上是一行存储（MySQL），所以会有大量线程来竞争 InnoDB 行锁。但并发越高，等待线程就会越多，TPS 降低，RT 上升，吞吐量会受到严重影响——注意，这里假设数据库已基于上文【性能优化】完成数据隔离，以便于讨论聚焦 。

解决并发锁的问题，有两种办法：

1. 应用层排队。经过缓存加入集群分布式锁，从而控制集群对数据库同一行记录进行操做的并发度，同时也能控制单个商品占用数据库链接的数量，防止热点商品占用过多的数据库链接
2. 数据层排队。应用层排队是有损性能的，数据层排队是最为理想的。业界中，阿里的数据库团队开发了针对InnoDB 层上的补丁程序（patch），能够基于DB层对单行记录作并发排队，从而实现秒杀场景下的定制优化——注意，排队和锁竞争是有区别的，若是熟悉 MySQL 的话，就会知道 InnoDB 内部的死锁检测，以及 MySQL Server 和 InnoDB 的切换都是比较消耗性能的。另外阿里的数据库团队还作了不少其余方面的优化，如 COMMIT_ON_SUCCESS 和 ROLLBACK_ON_FAIL 的补丁程序，经过在 SQL 里加入提示（hint），实现事务不须要等待实时提交，而是在数据执行完最后一条 SQL 后，直接根据 TARGET_AFFECT_ROW 的结果进行提交或回滚，减小网络等待的时间（毫秒级）。目前阿里已将包含这些补丁程序的 MySQL 开源：AliSQL

4.3 小结

高读和高写的两种处理方式截然不同。读请求的优化空间要大一些，而写请求的瓶颈通常都在存储层，优化思路的本质仍是基于 CAP 理论作平衡。

5 总结一下

固然，减库存还有不少细节问题，例如预扣的库存超时后如何进行回补，再好比第三方支付如何保证减库存和付款时的状态一致性，这些也是很大的挑战。

高可用

盯过秒杀流量监控的话，会发现它不是一条蜿蜒而起的曲线，而是一条挺拔的直线，这是由于秒杀请求高度集中于某一特定的时间点。这样一来就会形成一个特别高的零点峰值，而对资源的消耗也几乎是瞬时的。因此秒杀系统的可用性保护是不可或缺的。

1 流量削峰

对于秒杀的目标场景，最终可以抢到商品的人数是固定的，不管 100 人和 10000 人参加结果都是同样的，即有效请求额度是有限的。并发度越高，无效请求也就越多。但秒杀做为一种商业营销手段，活动开始以前是但愿有更多的人来刷页面，只是真正开始后，秒杀请求不是越多越好。所以系统能够设计一些规则，人为的延缓秒杀请求，甚至能够过滤掉一些无效请求。

1.1 答题

早期秒杀只是简单的点击秒杀按钮，后来才增长了答题。为何要增长答题呢？主要是经过提高购买的复杂度，达到两个目的：

1. 防止做弊。早期秒杀器比较猖獗，存在恶意买家或竞争对手使用秒杀器扫货的状况，商家没有达到营销的目的，因此增长答题来进行限制
2. 延缓请求。零点流量的起效时间是毫秒级的，答题能够人为拉长峰值下单的时长，由以前的 <1s 延长到 <10s。这个时间对于服务端很是重要，会大大减轻高峰期并发压力；另外，因为请求具备前后顺序，答题后置的请求到来时可能已经没有库存了，所以根本没法下单，此阶段落到数据层真正的写也就很是有限了

须要注意的是，答题除了作正确性验证，还须要对提交时间作验证，好比<1s 人为操做的可能性就很小，能够进一步防止机器答题的状况。

答题目前已经使用的很是广泛了，本质是经过在入口层削减流量，从而让系统更好地支撑瞬时峰值。

1.2 排队

最为常见的削峰方案是使用消息队列，经过把同步的直接调用转换成异步的间接推送缓冲瞬时流量。除了消息队列，相似的排队方案还有不少，例如：

1. 线程池加锁等待
2. 本地内存蓄洪等待
3. 本地文件序列化写，再顺序读

排队方式的弊端也是显而易见的，主要有两点：

1. 请求积压。流量高峰若是长时间持续，达到了队列的水位上限，队列一样会被压垮，这样虽然保护了下游系统，可是和请求直接丢弃也没多大区别
2. 用户体验。异步推送的实时性和有序性天然是比不上同步调用的，由此可能出现请求先发后至的状况，影响部分敏感用户的购物体验

排队本质是在业务层将一步操做转变成两步操做，从而起到缓冲的做用，但鉴于此种方式的弊端，最终仍是要基于业务量级和秒杀场景作出妥协和平衡。

1.3 过滤

过滤的核心结构在于分层，经过在不一样层次过滤掉无效请求，达到数据读写的精准触发。常见的过滤主要有如下几层：

一、读限流：对读请求作限流保护，将超出系统承载能力的请求过滤掉
二、读缓存：对读请求作数据缓存，将重复的请求过滤掉
三、写限流：对写请求作限流保护，将超出系统承载能力的请求过滤掉
四、写校验：对写请求作一致性校验，只保留最终的有效数据

过滤的核心目的是经过减小无效请求的数据IO保障有效请求的IO性能。

1.4 小结

系统能够经过入口层的答题、业务层的排队、数据层的过滤达到流量削峰的目的，本质是在寻求商业诉求与架构性能之间的平衡。另外，新的削峰手段也层出不穷，以业务切入居多，好比零点大促时同步发放优惠券或发起抽奖活动，将一部分流量分散到其余系统，这样也能起到削峰的做用。

2 Plan B

当一个系统面临持续的高峰流量时，实际上是很难单靠自身调整来恢复状态的，平常运维没有人可以预估全部状况，意外老是没法避免。尤为在秒杀这一场景下，为了保证系统的高可用，必须设计一个 Plan B 方案来进行兜底。

高可用建设，实际上是一个系统工程，贯穿在系统建设的整个生命周期。

具体来讲，系统的高可用建设涉及架构阶段、编码阶段、测试阶段、发布阶段、运行阶段，以及故障发生时，逐一进行分析：

1. 架构阶段：考虑系统的可扩展性和容错性，避免出现单点问题。例如多地单元化部署，即便某个IDC甚至地市出现故障，仍不会影响系统运转
2. 编码阶段：保证代码的健壮性，例如RPC调用时，设置合理的超时退出机制，防止被其余系统拖垮，同时也要对没法预料的返回错误进行默认的处理
3. 测试阶段：保证CI的覆盖度以及Sonar的容错率，对基础质量进行二次校验，并按期产出总体质量的趋势报告
4. 发布阶段：系统部署最容易暴露错误，所以要有前置的checklist模版、中置的上下游周知机制以及后置的回滚机制
5. 运行阶段：系统多数时间处于运行态，最重要的是运行时的实时监控，及时发现问题、准确报警并能提供详细数据，以便排查问题
6. 故障发生：首要目标是及时止损，防止影响面扩大，而后定位缘由、解决问题，最后恢复服务

对于平常运维而言，高可用更可能是针对运行阶段而言的，此阶段须要额外进行增强建设，主要有如下几种手段：

1. 预防：创建常态压测体系，按期对服务进行单点压测以及全链路压测，摸排水位
2. 管控：作好线上运行的降级、限流和熔断保护。须要注意的是，不管是限流、降级仍是熔断，对业务都是有损的，因此在进行操做前，必定要和上下游业务确认好再进行。就拿限流来讲，哪些业务能够限、什么状况下限、限流时间多长、什么状况下进行恢复，都要和业务方反复确认
3. 监控：创建性能基线，记录性能的变化趋势；创建报警体系，发现问题及时预警
4. 恢复：遇到故障可以及时止损，并提供快速的数据订正工具，不必定要好，但必定要有

在系统建设的整个生命周期中，每一个环节中均可能犯错，甚至有些环节犯的错，后面是没法弥补的或者成本极高的。因此高可用是一个系统工程，必须放到整个生命周期中进行全面考虑。同时，考虑到服务的增加性，高可用更须要长期规划并进行体系化建设。

3 总结一下

高可用实际上是在说 “稳定性”，稳定性是一个平时不重要，但出了问题就要命的事情，然而它的落地又是一个问题——平时业务发展良好，稳定性建设就会降级给业务让路。解决这个问题必须在组织上有所保障，好比让业务负责人背上稳定性绩效指标，同时在部门中创建稳定性建设小组，小组成员由每条线的核心力量兼任，绩效由稳定性负责人来打分，这样就能够把体系化的建设任务落实到具体的业务系统中了。

我的总结

一个秒杀系统的设计，能够根据不一样级别的流量，由简单到复杂打造出不一样的架构，本质是各方面的取舍和权衡。固然，你可能注意到，本文并无涉及具体的选型方案，由于这些对于架构来讲并不重要，做为架构师，应该时刻提醒本身主线是什么。

同时也在这里抽象、提炼一下，主要是我的对于秒杀设计的提纲式整理，方便各位同窗进行参考——
**