北京
staging环境跑得好好的，一上生产就崩。这不是什么新鲜事，但当你的系统要同时处理模型调用、用户连接和后台代理时，问题会成倍放大。
我们团队最近就栽了。一个实时AI功能，延迟飙升、事件重复、内存溢出，全赶在一起爆发。用户消息被处理两次，后台代理反复触发模型运行，WebSocket服务器在重连风暴中撞墙。最头疼的是，这些故障互相勾连——一个组件里的重试循环，会在别处制造流量尖峰。
一开始我们走了条"熟悉的路"：用关系型数据库当事件日志来保序，给WebSocket服务器加粘性会话图省事，用Redis的PUBLISH/SUBSCRIBE手搓个发布订阅层。看起来没毛病，直到规模上来。
数据库背书的序列化成了瓶颈，锁延迟拖慢全局。粘性会话让自动伸缩失效，滚动部署变成噩梦。Redis PUB/SUB没有持久化，节点一重启，正在协调的消息就丢了，回放行为诡异。我们还假设"最多一次"语义够用，结果后台代理重试时，模型成本翻倍，用户体验崩坏。
痛定思痛，我们需要三样东西同时到位：带背压的用户连接实时广播、持久有序的跨代理事件协调、以及足够低的运维负担——让团队专注模型编排，而不是 messaging 层。
最终方案是换掉自研组件，引入专门的消息编排层，把临时协调从主数据库迁出，用支持持久化、回放和消费者组的服务替代Redis PUB/SUB，并将WebSocket连接处理与业务逻辑解耦。具体落地分三步：事件扁平化为带序号和因果ID的幂等命令，按租户ID+逻辑主题分区隔离热点，消费者显式确认失败时由编排层指数退避重试并走死信队列。模型运行前还加了预确认步骤——先预留计算槽位，再确认消息。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
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.
