北京
第三次遷移的凌晨，Alex的電話把我從工位上拽了起來。"服務器卡死了，Chris，全是事件處理的鍋。"他的聲音帶著那種新手工程師特有的恐慌。用戶投訴像雪片一樣飛來——響應慢、事件丟失，Veltrix的默認配置在我們暴漲的流量面前徹底崩盤。
我盯著Prometheus面板，手心發涼：CPU利用率98%，事件服務錯誤率2.5%。再拖下去，用戶就要集體跑路了。
第一招：事件批處理，踩了大坑
我們選了最穩妥的方案：EventBatching。客戶端先把事件攢成一批再發，理論上能減少服務器處理次數，給CPU減負。聽起來沒毛病，實際用起來全是暗礁。
批處理把實時性干沒了。我們沒法立刻定位哪些事件在搞崩服務器，排查根因變成盲人摸象。更糟的是，客戶端攢批引入了平均10秒的延遲——對游戲服務器來說，這等于宣判死刑。
轉向：用事件溯源解耦CPU
逼到墻角，我們換了思路：Event Sourcing（事件溯源）。核心想法很簡單——把復雜的事件處理從服務器CPU上卸下來，扔進存儲層。
具體用了AWS DynamoDB的Streams功能，配合Fan-out Queue模式。事件先進隊列分批，再異步處理。服務器只管收，繁重的計算交給DynamoDB扛。實時性保住了，擴展性也有了。
數字說話
改造后的數據：CPU利用率直降25%，事件服務錯誤率從2.5%砸到0.2%，延遲從10秒壓到200毫秒。用戶終于能流暢玩游戲了，我們也喘上了氣。
如果重來
兩件事該前置做：一是給EventBatching上更狠的壓測，別等上線才發現延遲硬傷；二是客戶端批處理必須提前跑基準測試，性能底牌不能盲打。
事件溯源救了我們，但真正的教訓是——架構決策前，把"看起來可行"和"壓測驗證過"劃清界限。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
