故事开始的地方——一次'系统崩溃'引发的思考

第 1 章 故事开始的地方——一次"系统崩溃"引发的思考

2012 年 11 月 11 日凌晨 0 点 0 分，淘宝商城（彼时还叫这个名字）的大屏幕上，数字开始疯狂跳动。一分钟，一个亿；六分钟，突破十个亿；全天结束后，定格在 191 亿。这个数字让无数人欢呼雀跃——商家赚到了钱，平台拿到了名声，消费者"剁手"剁得心满意足。

但在这场狂欢的背后，有一群人彻夜未眠，眼眶通红地盯着监控大屏上的另一组数字：服务器 CPU 使用率 99%、数据库连接池告警、消息队列积压超过 1000 万条、订单系统响应时间从 200 毫秒飙升到 30 秒。他们是阿里巴巴的技术团队，正在用血肉之躯扛住这场"数字洪水"。

这并不是个例。事实上，那一年的双 11，技术团队几乎是在"走钢丝"。零点刚过，购物车的提交请求瞬间涌来，系统多次濒临崩溃边缘。最惊险的一次，支付链路在凌晨 1 点突然出现大面积超时，几百万用户同时看到那个让人抓狂的白色旋转圈。最终，是几位资深工程师连夜手动扩容、紧急优化代码、回滚异常版本，才把系统从悬崖边上拉了回来。

事后复盘时，一位参与其中的工程师说了一句让很多人至今难忘的话："那一刻我才真正明白，所谓的'高并发'不是书本上的一个名词，而是真真切切的一把悬在头顶的刀——刀落下来，公司可能就没了。"

这不是危言耸听。在互联网的世界里，"系统崩溃"四个字，从来都不是技术圈的自嗨，而是真金白银的代价、用户体验的崩塌、甚至一家公司命运的转折点。

让我们把时间轴再往前拨一些，去看看那些年，我们一起"跪"过的系统。

---

1.1 那些年，我们一起"跪"过的系统

1.1.1 12306：春运回家的"最后一公里"

2012 年春运，铁路客户服务中心网站 12306 上线不久。那一年的除夕前几天，无数游子守着电脑抢票，结果迎来的却是一次又一次的"系统繁忙，请稍后再试"。

很多人还记得那个画面：网页转了五分钟，最后跳出一个空白页面；或者好不容易刷到了票，点击预订之后弹出一行冷冰冰的字："您提交订单的时间过长，请重新选择车次"。再登录一看，票已经被别人抢走了。

当时的 12306 到底承受了多大的压力？据后来披露的数据，2012 年春运期间，12306 单日的访问量峰值超过了 14 亿次。这个数字是什么概念呢？做一个简单的对比——同年，整个淘宝双 11 当天的 PV（页面浏览量）大约是 9 亿。换句话说，12306 在某一天，扛住了比双 11 还高的流量。

但 12306 的悲剧在于，它的业务逻辑远比淘宝复杂。每张火车票都不是孤立的，它牵涉到出发站、到达站、车次、座位类型、座位号、身份证实名制、退票改签规则等等。当一列有 1000 个座位的火车开售时，几百万人同时去抢这 1000 个座位——这不是"下单"问题，这是"分配稀缺资源"问题，其计算复杂度远高于普通电商。

更糟糕的是，那一年 12306 的后台系统是按"日常售票"规模设计的，应对春运高峰完全是"小马拉大车"。结果就是系统频繁宕机，用户体验极差，骂声一片。

12306 的故事后来成为中国互联网技术史上最经典的"高并发"反面教材。它告诉我们一件事：业务规模暴涨时，如果系统能力跟不上，再大的平台也会被流量淹没。

1.1.2 微信红包：2015 年春晚的"黑色五分钟"

2015 年春节，微信和央视春晚合作，推出"摇一摇抢红包"活动。除夕夜 20:30 左右，第一轮摇一摇红包正式开放，金额为 5 亿元现金。

结果，短短几分钟内，微信服务器几乎全面崩溃。用户摇一摇时，屏幕上出现的是无尽的"加载中"，红包页面打不开，好不容易挤进去了又显示"已抢完"。整个活动期间，大量用户反映根本抢不到红包，系统响应迟缓。

事后复盘，技术团队承认：在那个时间点，微信的并发处理能力远低于实际涌来的请求量。摇一摇活动的瞬间峰值，远超他们的预期。

这次事故的直接后果是：用户体验大幅下降，很多人错过了抢红包的机会；更重要的是，微信支付的口碑受到了影响——很多用户第一次感受到，原来微信也会"掉链子"。

更深层的影响是，它暴露了一个问题：当一个产品获得现象级的成功（春晚 7 亿观众都在用），它的技术架构必须能够承受"全民级"的流量冲击。否则，再好的产品创意，都会被技术瓶颈扼杀。

1.1.3 苹果官网：iPhone 发售日的"蹲点噩梦"

2012 年 iPhone 5 发售日，苹果中国官网开放预购。结果，网站在预定开始后的几分钟内就完全瘫痪，用户反复刷新都是白屏。

类似的情况几乎每年都在上演。每当苹果发布新机，华为、小米等品牌的新机首销，官网也常常会出现类似的状况。

这些案例的背后，都指向同一个核心问题：高并发能力。

1.1.4 小米秒杀：饥饿营销背后的技术代价

雷军在 2014 年的某次发布会上提到过一件事：小米做秒杀活动时，由于技术准备不足，几次活动都出现了"点不开"、"加购物车失败"、"支付超时"等问题。那时的雷军一度非常焦虑，因为每一次秒杀失败，都意味着用户对小米品牌的信任度下降。

后来小米专门组建了一支精英技术团队，从架构到代码层面进行了彻底的优化。这种"用技术换体验"的投入，最终让小米在后续的秒杀活动中能够从容应对。

1.1.5 共同的教训：技术不是"事后补救"

把这些案例放在一起看，你会发现一个共同点：所有的崩溃，都发生在流量突然爆发的时刻。而所有的崩溃，本质上都是"系统处理能力跟不上请求量"。

这背后又可以拆解出几个具体原因：

• **架构设计时低估了流量**：以为峰值就是日常的几倍，结果来了几十倍。
• **没有做好容量规划**：服务器数量、数据库连接、网络带宽，没有按峰值配置。
• **代码层面有性能瓶颈**：一段低效的查询、一个不加缓存的接口、一个死循环，都可能在高并发下放大成灾难。
• **缺乏降级和熔断机制**：当系统某一部分撑不住时，没有"放手一搏"的备用方案，导致雪崩效应。
• **监控和应急响应不到位**：出了问题不能第一时间发现，第一时间止血。

这些问题，归根结底，都指向一个核心能力——高并发系统设计能力。

---

1.2 高并发的本质：到底什么是"高并发"？

听到"高并发"这个词，很多非技术背景的读者可能会觉得高深莫测。什么 QPS、TPS、并发线程数、吞吐量……一堆专业术语扑面而来，让人望而生畏。

其实，高并发的本质，一点都不复杂。

1.2.1 一个生活化的比喻：食堂打饭

想象一下大学食堂的中午 12 点。下课铃一响，几千名学生同时涌向窗口。打饭阿姨只有一个，窗口只有 4 个。如果排队的学生超过 50 人，队伍就会越来越长，等候时间越来越长，最后有人会等不及直接离开，甚至投诉。

这就是"高并发"的真实场景：

• "打饭窗口" = 你的服务器
• "打饭阿姨" = 你的处理程序
• "排队的学生" = 待处理的请求
• "单位时间内涌来的学生数" = 并发量

如果食堂的管理者提前预判到中午 12 点会"爆满"，于是多开了几个窗口，多雇了几个阿姨——这就是水平扩容（增加机器）。

如果发现某个窗口的阿姨打饭特别慢，一勺一勺地舀，而不是一次性舀满——这就是代码性能问题，需要优化代码。

如果发现大家都在排队打米饭，而打米饭的窗口只有 1 个，这就是资源瓶颈（单一资源点），需要把打米饭的任务分散到多个窗口——这就是分布式设计。

如果发现有些学生其实只想打一个菜，有些想打两个菜，但所有窗口都得按"米饭+菜+汤"的固定套餐来出餐——这就是业务流程设计不合理，可以通过业务拆分来提升效率。

你看，高并发的应对策略，说白了就是"开源节流"四个字：

• **开源**：增加处理能力（更多窗口、更多阿姨、更智能的工具）
• **节流**：减少不必要的请求（限流、排队、降级）

1.2.2 另一个比喻：演唱会入场

再看一个场景。演唱会开场前 1 小时，5 万人同时涌向一个能容纳 1 万人的体育场。

如果只有一个入口——灾难。 如果开了 10 个入口——勉强能用。 如果开了 20 个入口，并且每个入口都配备了扫码枪、安检仪、引导员——体验就顺畅多了。

但即便如此，如果 5 万人在同一分钟到达，依然会出问题。所以演唱会通常采用"分时段入场"——门票上印着 18:30 入场、18:45 入场、19:00 入场，把人流摊平到一段时间内。

这其实就是削峰填谷——把瞬时高峰拉平到一个时间段内，让系统不至于瞬间被打爆。

这些生活化的例子告诉我们：高并发不是一个抽象的技术概念，而是现实世界每时每刻都在发生的资源争夺问题。我们每天打的车、点外卖、网购、看视频，背后都是一个个小型的高并发场景。

1.2.3 技术语言的精确描述

当然，要做技术决策，我们需要更精确的术语。在技术领域，"高并发"通常用下面这些指标来描述：

• **并发用户数（Concurrent Users）**：同一时刻有多少用户在使用系统。例如，淘宝双 11 同时在线人数可达数亿。
• **QPS（Queries Per Second）**：每秒查询数。系统每秒要响应多少次请求。淘宝搜索的 QPS 在高峰期可以突破百万级。
• **TPS（Transactions Per Second）**：每秒事务数。一个事务可能包含多个请求，所以 TPS 通常比 QPS 小。
• **吞吐量（Throughput）**：单位时间内系统能处理的总工作量，通常用"请求数/秒"或"字节数/秒"来衡量。
• **响应时间（Response Time）**：从用户发出请求到收到响应的耗时。理想情况下应该在 100 毫秒以内，差的情况下可能要好几秒。
• **P99 响应时间**：99% 的请求都在这个时间内完成。这是衡量系统稳定性的关键指标。

理解这些指标后，"高并发"的定义就清晰了：

> 高并发 = 在相对较短的时间内，系统需要处理远超日常水平的请求量，并且要保证服务的可用性和响应速度。

请注意这里的两个关键点：

1. "相对较短的时间"：高并发强调的是"瞬时"和"突发"，而不是平均。日常 QPS 1000 的系统，碰到双 11 这种活动，QPS 可能在某几分钟内冲到 10 万。 2. "保证服务的可用性和响应速度"：高并发的目标不是"扛下来"就行，而是要在扛住的同时，让用户体验不受影响。系统没崩但慢如蜗牛，也是一种失败。

1.2.4 哪些场景属于"高并发"？

高并发并不是互联网公司的专利。事实上，任何"短时间内处理大量请求"的场景，都属于高并发的范畴：

• **电商大促**：双 11、618、黑五、春节年货节
• **抢票场景**：春运火车票、演唱会门票、热门赛事门票
• **社交爆发**：明星官宣结婚或离婚、重大社会事件、热门话题
• **红包雨**：春晚红包、直播间福袋
• **在线教育**：开学第一课、考研冲刺班开课
• **公共服务**：高考成绩查询、税务申报、社保认证
• **新闻热点**：突发新闻、热门文章刷屏
• **直播带货**：头部主播开播瞬间

甚至一些看似传统的行业，也逃不开高并发的"洗礼"：

• **银行系统**：发工资日、理财产品到期日、跨行转账高峰期
• **医院挂号**：专家号放号瞬间
• **景区门票**：节假日景区门票预约

可以说，在数字化时代，"高并发"是每个系统都必须面对的"成人礼"。

---

1.3 高并发为何重要：用户体验、商业价值、技术挑战

理解了什么是高并发，接下来要回答一个更关键的问题：为什么我们要花这么大力气去研究它？

答案可以从三个维度展开：用户体验、商业价值、技术挑战。

1.3.1 用户体验差：留不住的用户，流失的是真金白银

在互联网行业，有一个被无数案例验证过的真理：用户的耐心，比想象中还要稀缺。

Google 做过一项研究：页面加载时间每增加 0.5 秒，流量就会下降 20%。亚马逊也发现：页面加载每慢 100 毫秒，销售额就会下降 1%。

这是什么意思呢？一个看似不起眼的 1 秒延迟，可能让你损失数千万的营收。

举个例子，假设你的电商网站日均访问用户 100 万，平均客单价 200 元。如果页面加载时间延长 1 秒，导致 20% 的用户流失，那就是每天损失 20 万用户、4000 万订单金额。一年下来，损失超过 140 亿。

更可怕的是用户的"记忆效应"。用户不会理性地去分析"哦这次是技术问题下次会好"。他们只会记住：这个网站卡，这个网站慢，这个网站不行，下次去别家。

在竞争激烈的市场里，用户的迁移成本越来越低。今天你让他卡了 5 秒，明天他可能就下载了你竞争对手的 App。

所以，高并发能力的背后，其实是用户体验的承诺。

1.3.2 商业损失大：每一次宕机都是一场"放血"

直接经济损失，是高并发失败的"显性代价"。

我们来看几个真实的数据：

• 2017 年亚马逊 AWS 的一次 S3 服务故障，持续约 4 小时，导致大量互联网公司服务中断。S3 本身在那个季度贡献了亚马逊数十亿美元的收入，事故直接影响超过了 1.5 亿美元营收。
• 2018 年 Facebook 全球宕机 24 小时，市值蒸发约 360 亿美元。
• 2021 年 7 月，Akamai 的 CDN 服务故障，导致美国大量航空公司、银行、政府网站无法访问，直接影响了美国部分关键基础设施。
• 每年双 11、618 大促期间，电商平台为应对高并发要投入数千万甚至上亿的服务器、带宽、人力成本。

这些数字的背后，是每一次系统崩溃背后都是企业真金白银的损失。

但比直接损失更可怕的是间接损失——品牌信誉受损、用户信任度下降、合作伙伴信心动摇、媒体负面报道……这些"软损失"往往需要数月甚至数年才能修复。

举个典型的例子：某个互联网金融平台曾在一次秒杀活动中，因为系统崩溃导致用户无法正常购买理财产品。事故之后，虽然平台进行了赔偿，但仍有大量用户将资金转移到了竞品平台——这就是典型的"信任崩塌"。

对于互联网公司来说，"服务可用性"已经不是技术问题，而是商业底线。

1.3.3 技术挑战深：高并发是一面"照妖镜"

高并发的第三个维度，是它对技术能力的全面考验。

为什么这么说？因为高并发场景下，系统的每一个"短板"都会被无限放大。

平时日均 QPS 1000，系统有点小 bug 也无伤大雅；但当 QPS 冲到 10 万时，这个 bug 可能直接导致系统崩溃。

平时一台服务器就能扛住的流量，到了高并发时，需要几十台、几百台服务器协同工作——这就涉及到了分布式系统、负载均衡、服务治理等复杂问题。

平时单机数据库还能应付查询请求，到了高并发时，数据库成为瓶颈——这就需要分库分表、读写分离、缓存策略、搜索引擎等技术的综合运用。

平时用户的操作是顺序的、可预测的，到了高并发时，用户行为变得极端——重复点击、恶意刷单、流量攻击，都可能出现。

可以说，高并发是对系统架构、代码质量、运维能力、应急响应能力的全方位大考。

也正因为如此，高并发能力被公认为互联网技术能力的"试金石"。很多公司的招聘 JD 里都会写"有高并发经验者优先"——这不是装腔作势，而是因为能扛住高并发的工程师，确实凤毛麟角。

这也是为什么我们要专门写一本书来讲这件事。

---

1.4 本书能给你带来什么：一份"高并发系统设计"学习路线图

既然高并发这么重要，那我们应该怎么学？

在动手写这本书之前，我做了大量的调研。我看了市面上几乎所有的高并发相关书籍、文章、课程，发现一个普遍现象：

大部分技术书籍，要么太浅——只讲概念不讲原理；要么太深——堆砌术语让人望而生畏。

要么是面向资深架构师的"圣经"，普通工程师读得云里雾里；要么是面向初学者的"入门书"，看完之后依然不知道怎么做项目。

我希望能写一本"中间地带"的书——

• 对普通开发者友好，不要求你有 10 年经验
• 对资深工程师也有价值，能给你提供系统化的思维框架
• 有故事，有案例，有血有肉，不是一堆干巴巴的概念
• 有方法，有步骤，能让你看完之后真的动手去做

1.4.1 这本书的整体结构

为了让你在阅读之前就有一个清晰的"地图"，我把这本书的结构按照"由浅入深、由局部到全局"的逻辑分成了三个部分：

第一部分：基础篇——从一次"打饭"说起

第 1 章（你正在读的）：故事的起点，我们为什么要学高并发。 第 2 章：理解衡量系统性能的"尺子"——QPS、TPS、响应时间、吞吐量。 第 3 章：服务器进化论——从一台机器扛所有，到集群化部署。 第 4 章：操作系统层面的并发——进程、线程、协程，背后的秘密。

第二部分：核心技术篇——打造高可用系统的"十八般武艺"

第 5 章：缓存——让数据飞起来的最快方式。 第 6 章：消息队列——解耦系统的"魔法棒"。 第 7 章：分布式存储——从单机 MySQL 到分布式数据库。 第 8 章：负载均衡——把流量均摊到每台服务器。 第 9 章：服务拆分——微服务架构的演进与挑战。 第 10 章：限流与降级——在流量洪峰下保住核心业务。 第 11 章：熔断与隔离——防止故障蔓延的"防火墙"。 第 12 章：监控与告警——给系统装上"心电图"。

第三部分：实战篇——从理论到真实项目的"最后一公里"

第 13 章：秒杀系统设计——高并发最经典的实战场景。 第 14 章：稳定性保障——大促前的"魔鬼训练"。 第 15 章：未来展望——云原生时代的高并发新挑战。

1.4.2 谁应该读这本书？

这本书适合以下几类读者：

• **在校学生**：希望系统学习高并发知识，为找工作打下基础。
• **工作 1-3 年的初级工程师**：希望跳出"CRUD 程序员"的标签，向高级工程师迈进。
• **工作 3-7 年的中高级工程师**：希望系统梳理高并发知识体系，应对更复杂的项目。
• **技术管理者**：希望理解高并发系统的设计原理，做出更合理的技术决策。
• **对技术感兴趣的跨界人士**：希望了解互联网技术背后的运行逻辑。

无论你属于哪一类，我都希望这本书能给你带来三个层次的收获：

1. 知识层面：理解高并发系统的核心原理和主流技术。 2. 思维层面：建立"系统化思考"的能力，从单点优化到全局架构。 3. 实践层面：掌握真实项目中的设计方法和落地路径。

1.4.3 读这本书的正确姿势

最后，关于阅读这本书，有几点小建议：

第一，不要跳读。这本书的章节之间是有逻辑递进关系的，前一章是后一章的铺垫。跳读可能会让你在某些章节遇到"看不懂"的情况。

第二，多思考，多动手。每一章的最后都会有思考题和小实验，建议你真的去动手做一做。技术这东西，"看懂"和"会