100万用户涌入那晚：30个救命设计决策让系统没崩

凌晨2点17分，Amol Kharat的仪表盘数字跳到了7位数。他后来回忆，第一反应不是兴奋，是手开始抖——不是因为成就感，是因为他知道接下来会发生什么。

API响应时间从120毫秒爬到4秒，数据库连接池在17分钟内耗尽，错误日志以每分钟3000条的速度刷屏。这不是假设场景，是2024年3月某个周二的真实凌晨。「那一刻我才懂，」他在复盘文档里写，「写代码和造系统是两回事。」

第1-10课：当流量变成洪水，你的堤坝在哪

缓存不是锦上添花，是生死线。 Kharat的团队在崩溃前72小时紧急部署了Redis集群，把热点查询的响应从数据库的450毫秒压到12毫秒。但真正的教训是缓存穿透——当100万用户同时搜索同一个新上线功能，缓存层直接失效，请求像瀑布一样砸向数据库。

他们的解法叫「空值缓存」：即使查询结果为空，也在Redis里存一个5分钟的占位符。这个改动花了3小时写代码，却挡住了后续90%的无效请求。Kharat的原话：「缓存策略的复杂度，和系统规模成正比，但和团队准备度成反比。」

负载均衡器成了第二个战场。单台Nginx在8000并发时开始丢包，他们切到AWS ALB后发现更隐蔽的问题：会话粘滞（Session Affinity）导致某几台后端服务器负载飙到95%，而其他机器只有30%。

解法是把状态从服务器抽离，全部塞进Redis。这意味着重构了40%的业务代码，但Kharat算过账：「重构3天，还是崩溃后救火3周？这不需要犹豫。」最终架构支持了无状态水平扩展，单集群能扛住10万QPS。

数据库层面，读写分离是第一步，但主从延迟让他们吃了暗亏。用户刚发的帖子，刷新页面找不到——因为读请求走到了从库，而复制延迟有800毫秒。最终方案是「写后读一致性」：用户自己的操作强制走主库，其他人的请求走从库。这个细节藏在代码的DAO层，却决定了用户体验的底线。

第11-20课：分布式系统的9个谎言

网络分区不是会不会发生，是何时发生。 Kharat引用了一条分布式系统的铁律，然后补了后半句：「我们测试环境从来没分区过，生产环境第一周就遇到了。」

他们的服务部署在3个可用区，一次光纤维护导致跨区延迟从2毫秒跳到200毫秒。熔断器（Circuit Breaker）在这种情况下救了命：当错误率超过阈值，系统自动切断对故障依赖的调用，返回降级数据。用户看到的是「评论加载中」而不是整个页面崩溃。

幂等性设计是另一个血换来的教训。支付回调接口在重试时重复扣款，因为早期代码没做幂等校验。Kharat的方案是数据库唯一索引+业务令牌：同样的请求ID第二次进来，直接返回上次的结果。这个改动让财务对账差错率从0.3%降到0。

消息队列的引入是为了削峰，但带来了新问题：顺序保证。用户的关注操作和取消关注，如果乱序处理，最终状态就错了。他们用Kafka的分区键（Partition Key）确保同一用户的消息进同一分区，牺牲全局顺序换取单用户顺序。

日志聚合系统在那周也经历了考验。ELK堆栈在日志量暴涨时，Elasticsearch集群黄了——磁盘I/O瓶颈。Kharat的团队把热日志保留3天，冷日志转S3，查询时用Athena。成本降了60%，查询速度反而更快，因为ES只索引真正需要实时检索的字段。

第21-30课：从救火到防火

监控不是仪表盘漂亮，是能告诉你该看哪。 Kharat的团队最初有47个监控图表，崩溃时没人知道先看哪个。后来他们定了「黄金三指标」：错误率、延迟、流量。任何异常先盯这三个，其他的都是噪音。

混沌工程（Chaos Engineering）是第28课。他们在生产环境随机杀容器、注入延迟，验证系统的自愈能力。第一次演练就发现了数据库连接池的泄露：某个边缘服务在异常时没有释放连接，4小时后拖垮了整个集群。这个问题在常规测试里永远发现不了。

容量规划从拍脑袋变成数据驱动。Kharat建立了「用户增长→API调用量→资源消耗」的回归模型，能提前2周预测瓶颈。100万用户那天，模型预测和实际资源消耗的误差只有7%。

最后两课关于人和流程。On-call轮值制度确保凌晨2点有人能决策，而不只是叫醒整个团队。事后复盘（Postmortem）禁止追责，只问「系统怎么防止人犯错」。Kharat说：「最好的系统设计，是让错误很难发生，而不是指望人不犯错。」

文档里还记着一个细节：崩溃当晚，一位工程师在Slack发了张截图——他的咖啡杯在键盘上倒了，代码没保存。Kharat回复：「去买个新杯子，系统我来盯。」这个片段没出现在任何技术分享里，但他说那是他学到最重要的一课：「系统韧性最终是人的韧性。」

现在他的团队正在准备500万用户的架构方案。当被问到「如果重来一次，哪一课最早学」时，Kharat停顿了几秒：「可能是第31课——别等100万用户才学这30课。但说实话，有些坑，不摔进去真的不懂。」

你的系统现在能扛多少用户？如果明天醒来数字翻10倍，你最先检查哪个指标？