Original: aci https://segmentfault.com/a/1190000020970562
Foreword
Spike everyone is familiar with. Since 2011, for the first time, whether it is two-eleven shopping or 12306 grab votes, spike scene has been everywhere. In simple terms, the spike is at the same time a large number of requests scramble to buy the same goods and complete the transaction process. From an architectural perspective, the spike system is essentially a high-performance, high consistency, high availability of three high system. And to build and maintain a large traffic spike system which requires attention is the topic of this article.
1. Overall Thoughts
1.1 spike existing problems
For a smooth daily business system, if the opening of direct spike function, it will always be a lot of problems -
1.2 Design Thinking direction
Spike essentially requires a pressurized system under transient high incidence, which is different from its core business of other scenarios. Routine system problems spike generated by dismantling one by one classification, spike corresponds to architecture, in fact, high availability, consistency and performance requirements. Reflections on spike designed system, this paper is based on this three-layer sequentially advance, summarized as follows -
-
high performance. Involving high spike high read and write support, how to support high-concurrency, how to resist high IOPS? The core concept of optimization is actually similar: high reading as much as possible "less read" or "read less", high written data split. This article from the static and dynamic separation, hot spots and optimize server performance optimization three aspects Expand
-
consistency. The core concern is commodity inventory spike, limited commodity at the same time by multiple requests at the same deductions, but also to ensure accuracy, it is obvious a problem. How do neither more and a lot? This article from several industry-wide inventory reduction program to cut, to discuss the core logic design consistency
-
High availability. Large-scale distributed systems in the face of the actual operation condition is very complex, the sudden increase in traffic, the dependent services of instability, the application itself bottlenecks, damage to physical resources and other aspects of the system will bring big run the little big impact. How to ensure the applications are also efficient and stable operation in complex environmental conditions, how to prevent and face unexpected problems, the system design should start from what? Panoramic perspective of this article will focus on the architecture of landing think
2. High performance
2.1 static and dynamic separation
You may notice that you do not need to spike the process of refreshing the entire page, the only time in the stop beating. This is usually done because the system static transformation system for high-volume spike, that sense of movement on the data separation. Static and dynamic separation three steps: 1, split the data ; 2, static cache ; 3, data integration .
2.1.1 Data Split
Static and dynamic separation primary purpose is to transform into a dynamic page caching for static pages. Thus the first step is separated dynamic data, primarily from the following two aspects:
- user. User identity information includes login login status and portraits, the relevant elements can be split out separately, for obtaining dynamic request; recommendation level associated wide, such as user preferences, regional preferences, it can also be loaded asynchronously
- time. Spike time is set by the server unified management and control, can be obtained through dynamic request; here you can open a spike of electronic business platform page, take a look at this page in what are static and dynamic data.
2.1.2 static cache
After separating out the static data, static data the second step is reasonable cache, thus derived two questions: 1, how the cache; 2, where the cache
How cache:
A static characteristic is the direct transformation of the entire cache HTTP connections rather than merely static data cache, this way, the Web proxy server according to the URL request, the response can be taken directly to the corresponding body is then returned directly, without having to reorganize the HTTP protocol response process, and without parse HTTP request header. As a key cache, URL unification is essential, but for the commodity system, URL natural can be uniquely identified based on the commodity ID, such as Taobao https://item.taobao.com/item... ..
Where cache:
Static data cache to where? There are three ways: 1, the browser; 2, CDN; 3, service terminal.
Of course, the browser is the first choice, but the user's browser is not controllable, mainly in If you do not take the initiative to refresh, the system is difficult to take the initiative to push the message to the user (note that when discussing the static data, the subtext is "relatively unchanged ", implying that" may become "), such information may cause the user to see the end of a long period of time it is wrong. For spike system, the failure may be essential to ensure that the cache in the second level of time.
The main server dynamically load calculation and logic itself is not good at handling a large number of connections, each consuming more memory while parsing HTTP Servlet container is slow, easy occupation of logical computing resources; in addition, static data sink will pull this point request path length.
It is often static data cached in the CDN, which itself better at handling large static file concurrent requests, the initiative failed to do either, but from the user as close as possible, at the same time to avoid the Java language level weaknesses. It should be noted that the CDN has several problems to be solved:
- Failures. Any cache should be time-sensitive, especially for a spike scene. Therefore, the system needs to ensure that the country's failure CDN fall within the second level cache information in time, the system requirements for CDN actual failure is very high
- Hit rates. It is the most high hit the core of the system performance requirements cache, or the cache will lose its significance. If you put the data CDN around the country, will inevitably lead to the same request to reduce the possibility of a cache hit, then the hit rate becomes an issue
Therefore, all the data into the national CDN node is not realistic, failures, shooting problems will face bigger challenges. More feasible approach is to select a number of CDN nodes are selected static transformation, nodes typically needs to meet the following conditions:
- Approaching traffic concentrated areas
- Far from the main station area
- Inter-node network with the master of good quality regional
Based on the above factors, choose CDN secondary cache might be appropriate, because the number of secondary cache too few, capacity is greater, the relative concentration of traffic, so that you can better solve the problem of failures and cache hit rate, is the current ideal a CDN scheme. Deployment as shown below:
2.1.3 Data Integration
分离出动静态数据之后，前端如何组织数据页就是一个新的问题，主要在于动态数据的加载处理，通常有两种方案：ESI（Edge Side Includes）方案和 CSI（Client Side Include）方案。
- ESI 方案：Web 代理服务器上请求动态数据，并将动态数据插入到静态页面中，用户看到页面时已经是一个完整的页面。这种方式对服务端性能要求高，但用户体验较好
- CSI 方案：Web 代理服务器上只返回静态页面，前端单独发起一个异步 JS 请求动态数据。这种方式对服务端性能友好，但用户体验稍差
2.1.4 小结
动静分离对于性能的提升，抽象起来只有两点，一是数据要尽量少，以便减少没必要的请求，二是路径要尽量短，以便提高单次请求的效率。具体方法其实就是基于这个大方向进行的。
2.2 热点优化
热点分为热点操作和热点数据，以下分开进行讨论。
2.2.1 热点操作
零点刷新、零点下单、零点添加购物车等都属于热点操作。热点操作是用户的行为，不好改变，但可以做一些限制保护，比如用户频繁刷新页面时进行提示阻断。
2.2.2 热点数据
热点数据的处理三步走，一是热点识别，二是热点隔离，三是热点优化
热点识别：
热点数据分为静态热点和动态热点，具体如下：
- 静态热点：能够提前预测的热点数据。大促前夕，可以根据大促的行业特点、活动商家等纬度信息分析出热点商品，或者通过卖家报名的方式提前筛选；另外，还可以通过技术手段提前预测，例如对买家每天访问的商品进行大数据计算，然后统计出 TOP N 的商品，即可视为热点商品。
- 动态热点：无法提前预测的热点数据。冷热数据往往是随实际业务场景发生交替变化的，尤其是如今直播卖货模式的兴起——带货商临时做一个广告，就有可能导致一件商品在短时间内被大量购买。由于此类商品日常访问较少，即使在缓存系统中一段时间后也会被逐出或过期掉，甚至在db中也是冷数据。瞬时流量的涌入，往往导致缓存被击穿，请求直接到达DB，引发DB压力过大。
因此秒杀系统需要实现热点数据的动态发现能力，一个常见的实现思路是：
- 异步采集交易链路各个环节的热点 Key 信息，如 Nginx采集访问URL或 Agent 采集热点日志（一些中间件本身已具备热点发现能力），提前识别潜在的热点数据。
- 聚合分析热点数据，达到一定规则的热点数据，通过订阅分发推送到链路系统，各系统根据自身需求决定如何处理热点数据，或限流或缓存，从而实现热点保护。
需要注意的是：
- 热点数据采集最好采用异步方式，一方面不会影响业务的核心交易链路，一方面可以保证采集方式的通用性。
- 热点发现最好做到秒级实时，这样动态发现才有意义，实际上也是对核心节点的数据采集和分析能力提出了较高的要求。
热点隔离：
热点数据识别出来之后，第一原则就是将热点数据隔离出来，不要让 1% 影响到另外的 99%，可以基于以下几个层次实现热点隔离：
- 业务隔离。秒杀作为一种营销活动，卖家需要单独报名，从技术上来说，系统可以提前对已知热点做缓存预热。
- 系统隔离。系统隔离是运行时隔离，通过分组部署和另外 99% 进行分离，另外秒杀也可以申请单独的域名，入口层就让请求落到不同的集群中。
- 数据隔离。秒杀数据作为热点数据，可以启用单独的缓存集群或者DB服务组，从而更好的实现横向或纵向能力扩展。
当然，实现隔离还有很多种办法。比如，可以按照用户来区分，为不同的用户分配不同的 Cookie，入口层路由到不同的服务接口中；再比如，域名保持一致，但后端调用不同的服务接口；又或者在数据层给数据打标进行区分等等，这些措施的目的都是把已经识别的热点请求和普通请求区分开来。
热点优化：
热点数据隔离之后，也就方便对这 1% 的请求做针对性的优化，方式无外乎两种：
- 缓存：热点缓存是最为有效的办法。如果热点数据做了动静分离，那么可以长期缓存静态数据。
- 限流：流量限制更多是一种保护机制。需要注意的是，各服务要时刻关注请求是否触发限流并及时进行review。
2.2.3 小结
数据的热点优化与动静分离是不一样的，热点优化是基于二八原则对数据进行了纵向拆分，以便进行针对性地处理。热点识别和隔离不仅对“秒杀”这个场景有意义，对其他的高性能分布式系统也非常有参考价值。
2.3 系统优化
对于一个软件系统，提高性能可以有很多种手段，如提升硬件水平、调优JVM 性能，这里主要关注代码层面的性能优化——
- 少序列化：减少 Java 中的序列化操作可以很好的提升系统性能。序列化大部分是在 RPC 阶段发生，因此应该尽量减少 RPC 调用，一种可行的方案是将多个关联性较强的应用进行 “合并部署”，从而减少不同应用之间的 RPC 调用（微服务设计规范）。
- 直接输出流数据：只要涉及字符串的I/O操作，无论是磁盘 I/O 还是网络 I/O，都比较耗费 CPU 资源，因为字符需要转换成字节，而这个转换又必须查表编码。所以对于常用数据，比如静态字符串，推荐提前编码成字节并缓存，具体到代码层面就是通过 OutputStream() 类函数从而减少数据的编码转换；另外，热点方法toString()不要直接调用ReflectionToString实现，推荐直接硬编码，并且只打印DO的基础要素和核心要素。
- 裁剪日志异常堆栈：无论是外部系统异常还是应用本身异常，都会有堆栈打出，超大流量下，频繁的输出完整堆栈，只会加剧系统当前负载。可以通过日志配置文件控制异常堆栈输出的深度。
- 去组件框架：极致优化要求下，可以去掉一些组件框架，比如去掉传统的 MVC 框架，直接使用 Servlet 处理请求。这样可以绕过一大堆复杂且用处不大的处理逻辑，节省毫秒级的时间，当然，需要合理评估你对框架的依赖程度。
2.4 总结一下
性能优化需要一个基准值，所以系统还需要做好应用基线，比如性能基线（何时性能突然下降）、成本基线（去年大促用了多少机器）、链路基线（核心流程发生了哪些变化），通过基线持续关注系统性能，促使系统在代码层面持续提升编码质量、业务层面及时下掉不合理调用、架构层面不断优化改进。
3. 一致性
秒杀系统中，库存是个关键数据，卖不出去是个问题，超卖更是个问题。秒杀场景下的一致性问题，主要就是库存扣减的准确性问题。
3.1 减库存的方式
电商场景下的购买过程一般分为两步：下单和付款。“提交订单”即为下单，“支付订单”即为付款。基于此设定，减库存一般有以下几个方式：
- 下单减库存。买家下单后，扣减商品库存。下单减库存是最简单的减库存方式，也是控制最为精确的一种。
- 付款减库存。买家下单后，并不立即扣减库存，而是等到付款后才真正扣减库存。但因为付款时才减库存，如果并发比较高，可能出现买家下单后不能付款的情况，因为商品已经被其他人买走了。
- 预扣库存。这种方式相对复杂一些，买家下单后，库存为其保留一定的时间（如 15 分钟），超过这段时间，库存自动释放，释放后其他买家可以购买。
能够看到，减库存方式是基于购物过程的多阶段进行划分的，但无论是在下单阶段还是付款阶段，都会存在一些问题，下面进行具体分析。
3.2 减库存的问题
3.2.1 下单减库存
优势：用户体验最好。下单减库存是最简单的减库存方式，也是控制最精确的一种。下单时可以直接通过数据库事务机制控制商品库存，所以一定不会出现已下单却不能付款的情况。
劣势：可能卖不出去。正常情况下，买家下单后付款概率很高，所以不会有太大问题。但有一种场景例外，就是当卖家参加某个促销活动时，竞争对手通过恶意下单的方式将该商品全部下单，导致库存清零，那么这就不能正常售卖了——要知道，恶意下单的人是不会真正付款的，这正是 “下单减库存” 的不足之处。
3.2.2 付款减库存
优势：一定实际售卖。“下单减库存” 可能导致恶意下单，从而影响卖家的商品销售， “付款减库存” 由于需要付出真金白银，可以有效避免。
劣势：用户体验较差。用户下单后，不一定会实际付款，假设有 100 件商品，就可能出现 200 人下单成功的情况，因为下单时不会减库存，所以也就可能出现下单成功数远远超过真正库存数的情况，这尤其会发生在大促的热门商品上。如此一来就会导致很多买家下单成功后却不能付款，购物体验自然是比较差的。
3.2.3 预扣库存
优势：缓解了以上两种方式的问题。预扣库存实际就是“下单减库存”和 “付款减库存”两种方式的结合，将两次操作进行了前后关联，下单时预扣库存，付款时释放库存。
劣势：并没有彻底解决以上问题。比如针对恶意下单的场景，虽然可以把有效付款时间设置为 10 分钟，但恶意买家完全可以在 10 分钟之后再次下单。
3.2.4 小结
减库存的问题主要体现在用户体验和商业诉求两方面，其本质原因在于购物过程存在两步甚至多步操作，在不同阶段减库存，容易存在被恶意利用的漏洞。
3.3 实际如何减库存
业界最为常见的是预扣库存。无论是外卖点餐还是电商购物，下单后一般都有个 “有效付款时间”，超过该时间订单自动释放，这就是典型的预扣库存方案。但如上所述，预扣库存还需要解决恶意下单的问题，保证商品卖的出去；另一方面，如何避免超卖，也是一个痛点。
- 卖的出去：恶意下单的解决方案主要还是结合安全和反作弊措施来制止。比如，识别频繁下单不付款的买家并进行打标，这样可以在打标买家下单时不减库存；再比如为大促商品设置单人最大购买件数，一人最多只能买 N 件商品；又或者对重复下单不付款的行为进行次数限制阻断等
- 避免超卖：库存超卖的情况实际分为两种。对于普通商品，秒杀只是一种大促手段，即使库存超卖，商家也可以通过补货来解决；而对于一些商品，秒杀作为一种营销手段，完全不允许库存为负，也就是在数据一致性上，需要保证大并发请求时数据库中的库存字段值不能为负，一般有多种方案：一是在通过事务来判断，即保证减后库存不能为负，否则就回滚；二是直接设置数据库字段类型为无符号整数，这样一旦库存为负就会在执行 SQL 时报错；三是使用 CASE WHEN 判断语句：sql UPDATE item SET inventory = CASE WHEN inventory >= xxx THEN inventory-xxx ELSE inventory END
业务手段保证商品卖的出去，技术手段保证商品不会超卖，库存问题从来就不是简单的技术难题，解决问题的视角是多种多样的。
3.4 一致性性能的优化
库存是个关键数据，更是个热点数据。对系统来说，热点的实际影响就是 “高读” 和 “高写”，也是秒杀场景下最为核心的一个技术难题。
3.4.1 高并发读
秒杀场景解决高并发读问题，关键词是“分层校验”。即在读链路时，只进行不影响性能的检查操作，如用户是否具有秒杀资格、商品状态是否正常、用户答题是否正确、秒杀是否已经结束、是否非法请求等，而不做一致性校验等容易引发瓶颈的检查操作；直到写链路时，才对库存做一致性检查，在数据层保证最终准确性。
因此，在分层校验设定下，系统可以采用分布式缓存甚至LocalCache来抵抗高并发读。即允许读场景下一定的脏数据，这样只会导致少量原本无库存的下单请求被误认为是有库存的，等到真正写数据时再保证最终一致性，由此做到高可用和一致性之间的平衡。
实际上，分层校验的核心思想是：不同层次尽可能过滤掉无效请求，只在“漏斗” 最末端进行有效处理，从而缩短系统瓶颈的影响路径。
3.4.2 高并发写
高并发写的优化方式，一种是更换DB选型，一种是优化DB性能，以下分别进行讨论。
更换DB选型
秒杀商品和普通商品的减库存是有差异的，核心区别在数据量级小、交易时间短，因此能否把秒杀减库存直接放到缓存系统中实现呢，也就是直接在一个带有持久化功能的缓存中进行减库存操作，比如 Redis？
如果减库存逻辑非常单一的话，比如没有复杂的 SKU 库存和总库存这种联动关系的话，个人认为是完全可以的。但如果有比较复杂的减库存逻辑，或者需要使用到事务，那就必须在数据库中完成减库存操作。
优化DB性能
库存数据落地到数据库实现其实是一行存储（MySQL），因此会有大量线程来竞争 InnoDB 行锁。但并发越高，等待线程就会越多，TPS 下降，RT 上升，吞吐量会受到严重影响——注意，这里假设数据库已基于上文【性能优化】完成数据隔离，以便于讨论聚焦 。
解决并发锁的问题，有两种办法：
- 应用层排队。通过缓存加入集群分布式锁，从而控制集群对数据库同一行记录进行操作的并发度，同时也能控制单个商品占用数据库连接的数量，防止热点商品占用过多的数据库连接
- 数据层排队。应用层排队是有损性能的，数据层排队是最为理想的。业界中，阿里的数据库团队开发了针对InnoDB 层上的补丁程序（patch），可以基于DB层对单行记录做并发排队，从而实现秒杀场景下的定制优化——注意，排队和锁竞争是有区别的，如果熟悉 MySQL 的话，就会知道 InnoDB 内部的死锁检测，以及 MySQL Server 和 InnoDB 的切换都是比较消耗性能的。另外阿里的数据库团队还做了很多其他方面的优化，如 COMMIT_ON_SUCCESS 和 ROLLBACK_ON_FAIL 的补丁程序，通过在 SQL 里加入提示（hint），实现事务不需要等待实时提交，而是在数据执行完最后一条 SQL 后，直接根据 TARGET_AFFECT_ROW 的结果进行提交或回滚，减少网络等待的时间（毫秒级）。目前阿里已将包含这些补丁程序的 MySQL 开源：AliSQL
3.4.4 小结
高读和高写的两种处理方式大相径庭。读请求的优化空间要大一些，而写请求的瓶颈一般都在存储层，优化思路的本质还是基于 CAP 理论做平衡。
3.5 总结一下
当然，减库存还有很多细节问题，例如预扣的库存超时后如何进行回补，再比如第三方支付如何保证减库存和付款时的状态一致性，这些也是很大的挑战。
4. 高可用
盯过秒杀流量监控的话，会发现它不是一条蜿蜒而起的曲线，而是一条挺拔的直线，这是因为秒杀请求高度集中于某一特定的时间点。这样一来就会造成一个特别高的零点峰值，而对资源的消耗也几乎是瞬时的。所以秒杀系统的可用性保护是不可或缺的。
4.1 流量削峰
对于秒杀的目标场景，最终能够抢到商品的人数是固定的，无论 100 人和 10000 人参加结果都是一样的，即有效请求额度是有限的。并发度越高，无效请求也就越多。但秒杀作为一种商业营销手段，活动开始之前是希望有更多的人来刷页面，只是真正开始后，秒杀请求不是越多越好。因此系统可以设计一些规则，人为的延缓秒杀请求，甚至可以过滤掉一些无效请求。
4.1.1 答题
早期秒杀只是简单的点击秒杀按钮，后来才增加了答题。为什么要增加答题呢？主要是通过提升购买的复杂度，达到两个目的：
- 防止作弊。早期秒杀器比较猖獗，存在恶意买家或竞争对手使用秒杀器扫货的情况，商家没有达到营销的目的，所以增加答题来进行限制
- 延缓请求。零点流量的起效时间是毫秒级的，答题可以人为拉长峰值下单的时长，由之前的 <1s 延长到 <10s。这个时间对于服务端非常重要，会大大减轻高峰期并发压力；另外，由于请求具有先后顺序，答题后置的请求到来时可能已经没有库存了，因此根本无法下单，此阶段落到数据层真正的写也就非常有限了
4.1.2 排队
最为常见的削峰方案是使用消息队列，通过把同步的直接调用转换成异步的间接推送缓冲瞬时流量。除了消息队列，类似的排队方案还有很多，例如：
- 线程池加锁等待
- 本地内存蓄洪等待
- 本地文件序列化写，再顺序读
排队方式的弊端也是显而易见的，主要有两点：
- 请求积压。流量高峰如果长时间持续，达到了队列的水位上限，队列同样会被压垮，这样虽然保护了下游系统，但是和请求直接丢弃也没多大区别。
- 用户体验。异步推送的实时性和有序性自然是比不上同步调用的，由此可能出现请求先发后至的情况，影响部分敏感用户的购物体验
排队本质是在业务层将一步操作转变成两步操作，从而起到缓冲的作用，但鉴于此种方式的弊端，最终还是要基于业务量级和秒杀场景做出妥协和平衡。
4.1.3 过滤
过滤的核心结构在于分层，通过在不同层次过滤掉无效请求，达到数据读写的精准触发。常见的过滤主要有以下几层：
- 读限流：对读请求做限流保护，将超出系统承载能力的请求过滤掉
- 读缓存：对读请求做数据缓存，将重复的请求过滤掉
- 写限流：对写请求做限流保护，将超出系统承载能力的请求过滤掉
- 写校验：对写请求做一致性校验，只保留最终的有效数据
过滤的核心目的是通过减少无效请求的数据IO保障有效请求的IO性能。
4.1.4 小结
系统可以通过入口层的答题、业务层的排队、数据层的过滤达到流量削峰的目的，本质是在寻求商业诉求与架构性能之间的平衡。另外，新的削峰手段也层出不穷，以业务切入居多，比如零点大促时同步发放优惠券或发起抽奖活动，将一部分流量分散到其他系统，这样也能起到削峰的作用。
4.2 Plan B
当一个系统面临持续的高峰流量时，其实是很难单靠自身调整来恢复状态的，日常运维没有人能够预估所有情况，意外总是无法避免。尤其在秒杀这一场景下，为了保证系统的高可用，必须设计一个 Plan B 方案来进行兜底。
高可用建设，其实是一个系统工程，贯穿在系统建设的整个生命周期。
具体来说，系统的高可用建设涉及架构阶段、编码阶段、测试阶段、发布阶段、运行阶段，以及故障发生时，逐一进行分析：
（1）架构阶段：考虑系统的可扩展性和容错性，避免出现单点问题。例如多地单元化部署，即使某个IDC甚至地市出现故障，仍不会影响系统运转
（2）编码阶段：保证代码的健壮性，例如RPC调用时，设置合理的超时退出机制，防止被其他系统拖垮，同时也要对无法预料的返回错误进行默认的处理
（3）测试阶段：保证CI的覆盖度以及Sonar的容错率，对基础质量进行二次校验，并定期产出整体质量的趋势报告
（4）发布阶段：系统部署最容易暴露错误，因此要有前置的checklist模版、中置的上下游周知机制以及后置的回滚机制
（5）运行阶段：系统多数时间处于运行态，最重要的是运行时的实时监控，及时发现问题、准确报警并能提供详细数据，以便排查问题
（6）故障发生：首要目标是及时止损，防止影响面扩大，然后定位原因、解决问题，最后恢复服务
对于日常运维而言，高可用更多是针对运行阶段而言的，此阶段需要额外进行加强建设，主要有以下几种手段：
（1）预防：建立常态压测体系，定期对服务进行单点压测以及全链路压测，摸排水位
（2）管控：做好线上运行的降级、限流和熔断保护。需要注意的是，无论是限流、降级还是熔断，对业务都是有损的，所以在进行操作前，一定要和上下游业务确认好再进行。就拿限流来说，哪些业务可以限、什么情况下限、限流时间多长、什么情况下进行恢复，都要和业务方反复确认
（3）监控：建立性能基线，记录性能的变化趋势；建立报警体系，发现问题及时预警
（4）恢复：遇到故障能够及时止损，并提供快速的数据订正工具，不一定要好，但一定要有。在系统建设的整个生命周期中，每个环节中都可能犯错，甚至有些环节犯的错，后面是无法弥补的或者成本极高的。所以高可用是一个系统工程，必须放到整个生命周期中进行全面考虑。同时，考虑到服务的增长性，高可用更需要长期规划并进行体系化建设。
4.3 总结一下
高可用其实是在说 “稳定性”，稳定性是一个平时不重要，但出了问题就要命的事情，然而它的落地又是一个问题——平时业务发展良好，稳定性建设就会降级给业务让路。解决这个问题必须在组织上有所保障，比如让业务负责人背上稳定性绩效指标，同时在部门中建立稳定性建设小组，小组成员由每条线的核心力量兼任，绩效由稳定性负责人来打分，这样就可以把体系化的建设任务落实到具体的业务系统中了。
5. 个人总结
一个秒杀系统的设计，可以根据不同级别的流量，由简单到复杂打造出不同的架构，本质是各方面的取舍和权衡。当然，你可能注意到，本文并没有涉及具体的选型方案，因为这些对于架构来说并不重要，作为架构师，应该时刻提醒自己主线是什么。
同时也在这里抽象、提炼一下，主要是个人对于秒杀设计的提纲式整理，方便各位同学进行参考—!
