极客时间：高并发系统实战课

https://time.geekbang.org/column/intro/100309001

这门课把高并发从零散的性能技巧，提升成一整套系统能力地图：从数据结构、缓存、一致性、事务、拆分、检索，到流量治理、平台化和可观测性，帮助你看清一个系统是如何一步步被规模逼着演进的。

核心观点

这门课的重点不是教你几招顶住流量的优化技巧， 而是建立一张高并发系统的问题地图：当请求量、数据量、服务数量和机房数量同时上升时，系统瓶颈会从数据库，逐步转移到缓存、一致性、事务、隔离、检索、调度和可观测性上。

• 高并发系统的演进，本质上是瓶颈位置不断迁移：先是单表、索引和数据库写入扛不住，再是缓存一致性、鉴权流量、跨机房同步、分布式锁、跨服务事务、检索和统计链路扛不住。
• 真正难的不是把系统拆开，而是拆开以后仍然让整体对外表现为正确、稳定、可观测、可扩展。
• 高并发改造不是单点技巧堆砌，而是一条能力建设链路：数据结构梳理 -> 缓存承压 -> 一致性治理 -> 服务拆分 -> 流量隔离 -> 存储与检索分层 -> 工程化平台化。
• 课程隐含的判断很明确：性能优化只是入口，一致性、隔离性、可观测性和成本控制才是高并发系统长期演进的主战场。
• 很多问题不能靠更大的机器解决。一旦进入多副本、多机房、多服务阶段，核心矛盾就会转向 分布式系统、一致性、微服务 和 可观测性。

问题地图

1. 数据与存储

这一模块对应课程最开始的结构梳理和中段的稀疏索引。

它解决的问题不是SQL 怎么写得更快，而是：

• 业务数据是否按访问模式组织
• 数据库表结构是否已经把热点集中到少数行、少数索引、少数写路径上
• 关系数据库是否还适合继续承担高写入压力

课程一开始就强调先梳理表结构，这个判断很重要。很多老系统性能差，不是因为代码没优化，而是因为：

• 单表职责太多
• 字段、索引和访问路径不匹配
• 热点数据与冷数据混放
• 查询模式和数据模型已经错位

这说明高并发改造的第一步通常不是上中间件，而是先回答：

• 读多还是写多
• 点查还是范围查
• 是否需要强事务
• 是否可以按业务维度拆表、拆库、拆存储引擎

课程后面讲高并发写不推荐关系数据库，核心不是否定关系型数据库，而是指出：

• 关系库擅长事务、约束、关联
• 但在超高写入、超大日志、稀疏索引、实时分析这类场景下，写放大、索引维护和扩展成本会迅速上升

因此这一模块的关键认知是：

高并发系统首先要让数据模型服务访问模式，而不是让访问模式迁就一套历史表结构。

2. 缓存与一致性

这一模块覆盖缓存一致``本地缓存``可编程订阅式缓存``统一缓存数据平台``业务缓存等内容。

高并发系统里，缓存几乎一定会出现，因为数据库很难直接承受所有读流量。但缓存一上来，问题立刻从性能变成正确性：

• 数据库更新了，缓存什么时候更新
• 删除缓存还是覆盖缓存
• 临时缓存和长期缓存怎么区分
• 本地缓存如何避免多副本之间各自陈旧
• 缓存平台如何避免沦为一堆零散 Key 的垃圾场

课程里有个很强的主线：缓存不是一个组件，而是一层数据系统。

这意味着缓存问题至少分 3 层：

1. 单点技巧 比如缓存穿透、击穿、雪崩、延迟双删、失效时间。
2. 业务一致性 哪些数据允许旧，允许旧多久，失败后如何补偿。
3. 平台设计 是否要把缓存抽成统一平台、是否需要订阅、脚本、元数据管理和数据同步能力。

本地缓存一节尤其值得记住：本地缓存吞吐高、延迟低，但它天然把一致性问题放大了。进程越多、实例越多、发布越频繁，本地缓存就越像一个多副本分布式系统。

这一模块和 一致性、设计数据密集型应用、Redis 相关笔记都有强关联。

3. 身份鉴权与网关

Token``用户网关和缓存降低研发成本这两讲看起来像业务细节，其实是在讲高并发入口的两个核心问题：

• 鉴权流量是否会把中心化认证系统打穿
• 是否能把通用访问逻辑前移到边界层

Token 的价值不只是免登录，而是把原本可能频繁回源的会话校验，转成低成本、弱依赖、可扩展的身份凭证校验。

这背后的判断是：

• 用户量上涨时，鉴权系统本身也会成为热点服务
• 如果每次请求都依赖中心会话存储，认证层就会先于业务层成为瓶颈

而网关编程一节，则是在讲把通用逻辑从业务服务中拿出来：

• 鉴权
• 路由
• 灰度
• 限流
• 缓存
• 协议转换

这不仅是性能优化，也是在做复杂度收敛。越多横切能力下沉到网关或平台层，业务服务就越容易保持简单。

4. 分布式一致性与事务

这是整门课最硬核、也最通用的一组内容，包括：

• 同城双活
• Raft 共识
• 强一致锁
• 分布式事务（2PC、TCC）

这里课程反复强调同一个事实：

当系统从单机数据库进入多机房、多副本、多服务阶段后，性能不再是唯一问题，正确性会成为第一问题。

同城双活讲的是跨机房同步与容灾，Raft 讲的是复制状态机如何收敛出一个确定结果，强一致锁讲的是高并发库存争抢下如何控制共享资源，2PC/TCC 则是在讨论跨服务业务流程如何尽量维持原子性。

可以把这组问题统一看成：

• 如何让多个节点对同一份状态达成一致
• 如何在失败、重试、超时、乱序下仍保持业务可解释

关键结论不是要无脑追求强一致，而是：

• 强一致通常更慢、更贵、更脆弱
• 最终一致通常更灵活，但要求业务补偿、幂等、重试和状态机设计

所以高并发系统的核心能力，不是把所有流程都做成分布式事务，而是能判断：

• 哪些流程必须强一致
• 哪些流程只需顺序一致
• 哪些流程允许异步补偿

这部分可直接和 raft、一致性、微服务、分布式系统 一起看。

5. 系统拆分与隔离

领域拆分``系统隔离两讲是整门课架构味最重的部分。

课程没有把拆分讲成微服务口号，而是在讲两个更本质的问题：

• 什么边界应该拆
• 拆完以后如何防止互相拖垮

领域拆分关注的是业务边界：

• 什么能力应该内聚在同一个服务里
• 什么数据应该被同一个领域模型管理
• 什么调用关系说明边界划错了

系统隔离关注的是故障边界：

• 热点业务是否能与普通业务隔离
• 读链路与写链路是否隔离
• 核心依赖与非核心依赖是否隔离
• 流量突增时，是否能做到局部降级而不是整体雪崩

这部分的核心判断是：

高并发系统不是永不出故障，而是故障出现时能够被限制在局部，而不把整条链路一起拖死。

所以拆分的目标不是优雅，而是：

• 降低耦合
• 限制爆炸半径
• 让扩容、降级、容灾都能按边界生效

6. 检索、统计与分析

这一组包括：

• 链路追踪系统
• Elasticsearch 分片
• 实时统计算法
• ClickHouse

它们共同回答的是：

• 当数据量和访问量上去后，关系库已经无法同时兼顾事务、检索、聚合、分析，系统该如何分层

Elasticsearch 解决的是大规模检索与倒排索引问题，ClickHouse 解决的是分析型查询问题，实时统计则是在讲高吞吐事件流里的近实时聚合。

这说明高并发系统到了中后期，存储体系通常会分层：

• OLTP：承接事务和业务写入
• Search：承接检索
• OLAP：承接分析
• Trace/Log：承接排障和观测

这里最值得记住的一点是：

不同系统不是在竞争，而是在按访问模式分工。

一套数据库想同时做好事务、全文检索、海量聚合和低成本分析，通常不现实。

7. 流量治理与调度

流量拆分``流量调度``DNS、全站加速及机房负载均衡这一组，讨论的是高并发系统在入口层和全局层如何分配流量。

它关注的不是某台机器扛不扛得住，而是：

• 流量如何按地域、机房、用户、业务、灰度规则拆开
• 故障机房是否能快速摘除
• 是否可以就近接入
• 核心链路是否能优先保证

这意味着高并发后期的瓶颈已经不只在应用层，而是开始进入：

• DNS
• 全站加速
• 全局负载均衡
• 跨机房流量编排

这一模块和同城双活``系统隔离是连着的。前者解决流量怎么走，后者解决流量打进来以后系统怎么不崩。

8. 可观测性、成本与压测

课程后段把链路追踪``日志中心成本``性能压测放在一起，非常合理，因为这三者共同定义了系统的工程闭环：

• 你能不能看见系统发生了什么
• 你知不知道这些能力的代价
• 你有没有在流量到来前验证过它

链路追踪的价值不只是排障，而是：

• 找到尾延迟放大的位置
• 看清调用拓扑
• 做容量评估和优化决策

日志中心成本一节则提醒一个常被忽略的问题：可观测性不是免费的。日志留多久、采集多细、索引怎么建、冷热数据如何分层，都会转化成真实的存储和计算成本。

压测一节的判断也很现实：

• 压测不只是打满 QPS
• 压测的价值在于尽可能接近真实链路、真实依赖、真实数据分布和真实故障模式

所以这一模块真正讲的是：

没有观测，就没有优化；没有成本意识，就没有可持续的基础设施；没有压测验证，就没有真正的容量把握。

课程主线

如果按原课程推进顺序看，这门课的主线大致是：

单点热点 -> 缓存承压 -> 多机房一致性 -> 服务拆分 -> 分布式事务 -> 检索与分析分层 -> 缓存平台化 -> 流量治理 -> 观测与成本收尾

第一阶段：先处理眼前最容易爆的点

课程从数据库表结构、缓存一致、Token 开始，是很典型的实战顺序。

因为多数系统在真正迈向分布式架构前，最先遇到的不是 Raft，也不是 TCC，而是：

• 表设计拖慢请求
• 数据库读压力过高
• 鉴权服务被打爆

这一阶段的关键词是：止血。

第二阶段：开始面对多机房和多副本问题

当单点问题初步缓解后，系统会进入更难的一层：

• 多机房之间怎么同步
• 多副本如何保持一致
• 高并发共享资源如何避免争抢错乱

这时课程引入同城双活、Raft、强一致锁，说明系统已经从单点优化进入分布式正确性阶段。

这一阶段的关键词是：一致性。

第三阶段：系统拆分，复杂度外溢

有了一定规模之后，单体或大服务很难继续承载团队协作和业务增长，于是课程开始讲领域拆分、系统隔离、分布式事务。

这一步的意义是：

• 服务拆开了，团队边界更清晰
• 但事务、调用链、故障传播、依赖管理都变难了

所以课程顺序本身已经在说明：

服务拆分从来不是终点，而是把复杂度从进程内搬到网络和治理层。

这一阶段的关键词是：边界。

第四阶段：存储体系开始分层

接着课程进入链路追踪、Elasticsearch、实时统计、ClickHouse、自研追踪。

这意味着系统已经不再依赖单一数据库，而是开始围绕不同访问模式做设施分工：

• 事务写入一套
• 检索一套
• 实时统计一套
• 分析查询一套
• 观测数据一套

这一阶段的关键词是：分层。

第五阶段：从组件使用走向平台建设

本地缓存、可编程缓存、统一缓存数据平台、元数据服务、用户网关，标志着系统开始做平台化沉淀。

这时关注点已经不只是某个服务扛不扛流量，而是：

• 是否能把通用能力平台化
• 是否能让新业务复用这些能力
• 是否能减少研发重复造轮子

这一阶段的关键词是：平台化。

第六阶段：流量治理与工程闭环

最后课程落到流量拆分、流量调度、日志成本、压测。

这说明系统建设的最终形态不是某个组件很强，而是你已经具备：

• 对外接流量的能力
• 对内分流量的能力
• 观测问题的能力
• 预估成本的能力
• 演练容量和故障的能力

这一阶段的关键词是：运营级工程能力。

关键启发

1. 高并发系统的优化顺序通常不是随机的，而是沿着瓶颈迁移路径推进。先是数据库和缓存，再是一致性和事务，再是检索分析、流量治理和观测体系。
2. 课程反复说明：性能问题和正确性问题往往交织在一起。缓存解决了吞吐，却引入一致性；拆分提升了扩展性，却引入事务和治理成本。
3. 真正的高并发能力不是某个组件能抗多大 QPS，而是系统在高流量、部分失败、跨机房、异步链路下仍然可解释、可恢复、可扩容。
4. 平台化是高并发系统后期的重要方向。缓存平台、元数据服务、网关、日志中心，本质上都在把重复问题抽成基础设施。
5. 可观测性和成本意识必须尽早进入设计，而不是等系统出事后再补。很多系统不是死在不够快，而是死在看不见或者成本失控。

进一步延伸

• 设计数据密集型应用