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倍，你最先檢查哪個指標？