高负载架构：如何构建不崩溃的系统

你的系统对于 100 个用户来说运行良好。但是如果明天 TechCrunch 报道了你，来了 100,000 人会发生什么？大多数初创公司并不是死于糟糕的想法，而是死于无法扩展。High-Load 架构是一门构建随业务增长的系统的艺术。

垂直 vs 水平：永恒的战斗

增长有两条路。你可以买一个“更大的服务器” (Scale Up) 或买“许多小服务器” (Scale Out)。

关键生存模式

• 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)。