2025年12月25日Evgeny · 高级系统工程师
高负载架构：如何构建不崩溃的系统
你的系统对于 100 个用户来说运行良好。但是如果明天 TechCrunch 报道了你，来了 100,000 人会发生什么？大多数初创公司并不是死于糟糕的想法，而是死于无法扩展。High-Load 架构是一门构建随业务增长的系统的艺术。
垂直 vs 水平：永恒的战斗
增长有两条路。你可以买一个“更大的服务器” (Scale Up) 或买“许多小服务器” (Scale Out)。
图 1. 典型的水平扩展方案
关键生存模式
- Load Balancing (负载均衡): 入口的 Nginx 或 HAProxy 分发请求。如果一个应用服务器宕机，均衡器只会停止向其发送流量。用户什么也没注意到。
- Database Replication (数据库复制): Master 服务器写入数据，Slave 服务器读取。这减轻了数据库的负担，因为 80% 的 Web 操作是读取。
- Sharding (分片): 当数据变成 PB 级时，一个数据库无法应付。我们将数据库“切”成碎片 (shards)：用户 A-M 在服务器 1 上，N-Z 在服务器 2 上。
缓存：不要徒劳地加载数据库
最快的请求是没有发生的请求。将热数据存储在 RAM (Redis/Memcached) 中。
规则： 如果数据请求频繁但很少更改（用户资料，产品目录）—— 它的位置就在缓存中。
异步和队列
用户点击了“生成报告”。这是一个繁重的操作。不要让他们看着旋转的加载器等待。将任务发送到队列 (RabbitMQ/Kafka)，让 worker 在后台完成，并告诉用户：“我们会发送通知”。
结论： High-Load 不是关于昂贵的服务器。它是关于智能架构，其中一个组件的故障不会导致整个系统崩溃 (No Single Point of Failure)。
主题常见问题
流量形态与数据往往与生产不一致。需要场景、与线上一致的指标，以及可回滚的逐步加压。
常见瓶颈在数据库与执行计划、连接池、同步外部调用与队列——可作为快速排查清单。
不一定：失效、冷启动与热点键可能适得其反。缓存要按读模型与 SLO 设计。
垂直扩展与查询优化触顶，且数据增长在分片键上可预期时。