第三次迁移的凌晨，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上更狠的压测，别等上线才发现延迟硬伤；二是客户端批处理必须提前跑基准测试，性能底牌不能盲打。

事件溯源救了我们，但真正的教训是——架构决策前，把"看起来可行"和"压测验证过"划清界限。