如何设计高可用、可扩展且事件仅处理一次的事件监听应用？

核心思路是解耦事件接收和事件处理逻辑，从架构层面避免多实例重复接收相同事件，或通过校验机制拦截重复处理逻辑。 #

方案1：单实例接收器+分布式消息队列 #

这是生产环境最常用的成熟方案，兼顾可靠性和扩展性：

• 单独部署WebSocket事件接收器集群，采用主备高可用模式，同一时间只有1个活跃接收器负责和上游建立WebSocket连接接收事件，主节点故障时自动切换到备节点，避免事件丢失
• 接收器仅做事件合法性校验，不执行业务逻辑，校验通过后直接将事件写入分布式消息队列（Kafka、RabbitMQ、RocketMQ均可），确保事件落地
• 原Node.js业务逻辑改造为无状态的消息消费者，从消息队列拉取事件进行处理，利用消息队列的消费确认ACK机制保证单条事件仅被一个消费者实例获取并处理
• 优势：业务处理端支持无限按需扩缩容，消息队列自带削峰能力，不会出现性能瓶颈；事件落地到消息队列后不会因为处理节点故障丢失

方案2：分布式锁+幂等校验兜底 #

适合不想新增消息队列组件、改造成本要求低的场景：

• 所有Node.js实例同时监听WebSocket事件，收到事件后首先基于事件的唯一标识（事件自带ID，或按事件内容+时间戳生成唯一哈希值）尝试获取分布式锁（可基于Redis、ETCD实现）
• 仅成功拿到锁的实例可以执行后续业务处理逻辑，未拿到锁的实例直接丢弃当前事件
• 额外增加幂等校验层：处理完事件后将事件唯一ID写入缓存并设置合理过期时间，后续所有实例收到相同ID的事件时先查缓存，已存在则直接跳过处理，作为锁冲突场景下的兜底逻辑
• 注意点：分布式锁需要设置合理的超时时间，避免处理节点崩溃导致锁永久占用；事件唯一ID生成规则需保证不会出现重复冲突

方案3：上游WebSocket分区推送 #

如果上游WebSocket服务支持自定义推送规则，可以采用此方案，无需额外引入中间件：

• 要求上游服务按事件唯一ID的哈希值对事件进行分区，每个Node.js实例仅负责固定哈希区间的事件处理，上游仅将对应区间的事件推送给目标实例，天然避免重复接收
• 扩缩容时采用一致性哈希算法分配区间，减少实例数量变化时的事件重分配范围
• 优势：架构最简洁，没有额外中间件成本
• 限制：依赖上游WebSocket服务的定制开发支持

通用建议：所有方案都建议给业务处理逻辑加上幂等校验兜底，极端场景下就算出现事件重复投递，也不会产生脏数据或异常业务结果

内容的提问来源于stack exchange，提问作者Carven