2026年2月25日Evgeny · 高级系统工程师
高负载系统架构：如何处理每秒百万请求
一台服务器——一台死亡服务器。如果你的后端只运行在单台机器上，你不是在构建产品——你是在构建一颗定时炸弹。高负载系统不是关于强大的硬件，而是关于正确的架构。
高负载的三大支柱
图 1. 负载均衡器将流量分配到服务器池
1. 水平扩展（Scale Out）
规则：不要让一台服务器更强大——添加更多服务器。这是垂直扩展（$50,000的机器）和水平扩展（10台×$500的机器）之间的本质区别。
- 优点：无限增长上限。一个节点崩溃——其余继续工作。
- 挑战：应用程序必须是无状态的。不能在进程内存中存储会话。
2. 负载均衡器
负载均衡器是调度器。它接受所有传入请求并将其分发到活跃节点。分发算法：轮询（Round Robin）、最少连接（Least Connections）。Nginx、HAProxy、AWS ALB——适合任何预算的选择。
3. 缓存——第一道防线
大多数服务中80%的请求是重复的。Redis或Memcached缓存响应并减少数据库负载。Cache-aside规则：先检查缓存，未命中时——去数据库并将结果存入缓存。
# 典型高负载架构
客户端 → CDN → 负载均衡器
├── 应用服务器 #1 → Redis缓存 → PostgreSQL（主）
├── 应用服务器 #2 → Redis缓存 → PostgreSQL（从）
└── 应用服务器 #3 → 消息队列（RabbitMQ/Kafka）
异步作为哲学
并非所有任务都需要同步执行。发送邮件、生成报告、图像缩放——这些都放入队列（Kafka、RabbitMQ、SQS）并由后台工作进程处理。用户无需等待——他们立即得到响应。
NineLab 建议：从简单的单体开始，但要设计成易于提取服务的方式。"过早的微服务化"比高负载杀死了更多的初创公司。
结论：高负载系统不是魔法。它是负载均衡器 + 无状态应用 + Redis + 队列 + 精心设计的数据库。每一层都减轻了下一层的压力。这正是Telegram、Avito和Ozon的工作方式。
主题常见问题
流量形态与数据往往与生产不一致。需要场景、与线上一致的指标，以及可回滚的逐步加压。
常见瓶颈在数据库与执行计划、连接池、同步外部调用与队列——可作为快速排查清单。
不一定：失效、冷启动与热点键可能适得其反。缓存要按读模型与 SLO 设计。
垂直扩展与查询优化触顶，且数据增长在分片键上可预期时。