吾辈所解之实题

Hytale引擎以简易之发布订阅系统——即EventManager——触发诸般事件。然当Veltrix扩容至两千五百同场竞技者，周五寻宝之戏于一千二百同场参与者负荷下，竟至停摆。其症非隐晦：

• EventManager阻塞队列于Redis流中达八十九之百分率
• 每有宝物生成，延迟骤升至2.4秒
• 客户端宝物激活时玩家超时，致NRE-7280：宝箱激活超时——区域53无应答
• Redis内存用量未及15分钟，自2.1GB暴涨至11.2GB，致缓存层触发OOM杀手

根本非逻辑之过，乃配置之弊也。吾辈一用全球事件通道，通辖诸域；一用Redis流，统管诸宝，而绝无反压之设。是以EventManager，竟若决堤之水，非若灌溉之有度也。

初试之道（及其败因）

吾初试，乃愚拙之法：增 Redis 分片，增消费者，速硬件。吾投三 Redis 7.2 分片于事，每片有八消费者组，跨四域。此得四十分钟之稳，然队列犹在重负下壅塞。何哉？

• 其发布订阅之信道，犹为全局。海港城之珍宝，尚列于枯瘴沼泽之一信之后。
• 玩家流移：众客迁跃于疆域，未得清分群属，致生灵重现，虚箱频现.
• 无断路之设。当 Redis 膜池骤升，OOM 杀手非独绝其进程，复诛尽缓存之层，尽堕众客之会。
• 吾等以 OpenResty 为速率限制器，然其每启一进程，辄增迟滞四百毫秒，玩家渐报行止涩滞。

硬言之？吾辈优化吞吐量，而非信号之完整。视事件流若原始数据之管道，而非具明晰边界之界限情境。

建筑之决断

吾等转而采严苛之区域事件巴士模式：

• 六域各得独存之 Redis 流，非分片也。
• 吾更易频道之名，以合生境之号：Harbormere为EventStream_53，Blightfen为EventStream_71。
• 藏宝生成之规，区域有别：非得明许，不可跨区生成（吾等既已调试跨区鬼箱，遂全然禁之）
• 吾等创制一轻便之事件总线网关，以Go语书之，运行于专司之k3s节点，每节点具2 vCPU与4GB内存。此物非为消费者，乃为发散路由也。
• 各域之消费者群，其最大在飞消息数为卅二，于 Redis NACK 上行指数退避。
• 吾设Redis之maxmemory-policy为allkeys-lru，定8GB为硬性上限，复增Lua脚本，俟内存逾6GB，则强令GC。
• 吾等将宝物激活之理，自客户端移至地域微服务，名曰TreasureCore，其运行于Fly.io，以Postgres 16及pgbouncer为基。其外露REST端点：POST /treasure/{biomeId}/activate，兼用ETag锁，以防重生之弊。

权衡之计昭然：操作之费增，区域之耗高，区际传送或有迟滞。然吾辈择正道不取便捷。区域之制，使Harbormere宝物之生，虽玩家中事而传送，亦不阻Blightfen宝箱之现。

数之所言，后何在哉

三月穩運：

• Redis之内存稳定于3.2GB，遍及诸流（较旧之全局模型减71%）
• 宝物生成延迟由2.4秒降至180毫秒（p99）
• 不复见NRE-7280之误于重负—激活之失自12%降<千分之一
• 遊戲體驗得改善：無再胸閃爍於屏，無再傳送致不同步
• 价：Redis月费四十七元（自百八十九元减之），加六TreasureCore实例月费百一十二元。吾辈以十四毫秒之跨区延迟易得稳定。

数理昭示吾辈所疑：视事件引擎为全域系统乃反常之道。区域化非为过早优化——实乃补救之策。

吾当异法行之

吾永不再设一统全局之事件系统。非为《Hytale》，非为诸游戏。纵有强地域化，然玩家于高峰时批量越区传送，犹使事件网关为路由更新所压。吾之解法，乃引入传送引致地域转换之冷却期，然则损用户体验矣。

他日，吾当析事件流为二：一为静流，载固定宝箱之讯；一为动流，载怪物、天候、定时生成之讯。若得闲暇以习，吾将择NATS JetStream代Redis Stream，盖其自带流级缓冲之能。

吾永不复信客户端激活。Hytale客户端仍唯JavaScript与WebGL耳，物理不同步乃必然。当将此逻辑推于服务器，归其所属。

吾于是周五救Veltrix于倾颓。非增置硬件以解之，乃循吾所建系统之疆界。此训永铭：事非仅若特征，实为契约。毁约则系统亦随之崩。