Stream-Nexus开源推送系统升级支持集群部署，基于Redis实现多节点协同推送

开源实时推送项目Stream-Nexus近日完成重要功能迭代，正式支持集群部署模式。该项目最初定位为轻量级实时消息推送平台，支持Server-Sent Events（SSE）与WebSocket两种主流协议，早期版本仅限单机运行；此次升级响应社区反馈，实现了面向生产环境的高可用架构扩展。

Stream-Nexus名称源自“Stream”（流式数据）与“Nexus”（连接枢纽），其设计初衷是解耦业务系统与推送逻辑：业务端仅需将消息“灌入”系统，由服务端统一调度并推送给终端连接。这一架构在单机场景下简洁高效，但面对高并发或容灾需求时存在明显瓶颈。此次集群化改造，核心目标是在不牺牲轻量特性的前提下，提升系统的横向扩展能力与可靠性。

集群部署的关键挑战在于：SSE与WebSocket客户端连接无法直接序列化存储于Redis等中间件中——它们本质是长连接句柄，属于进程内资源。因此，项目采用“连接映射+消息路由”双层策略：各节点本地维护活跃连接实例，而连接与用户/模块的绑定关系则持久化至Redis；当消息需要推送时，先经Redis Pub/Sub广播，再由目标节点依据本地映射表精准触达对应客户端。

具体实现中，项目选用Redis作为集群总线，利用其原生Pub/Sub机制处理瞬时通知类消息。作者指出，该方案对消息丢失具备一定容忍度，适用于多数实时推送场景；若需强一致性保障，则可切换至Redis Streams（5.0+），以支持消息持久化与消费组回溯。

值得注意的是，SSE与WebSocket在集群环境下的行为差异显著，直接影响路由逻辑设计：

SSE为单向流协议，客户端建立连接后，后续心跳请求可能被负载均衡器分发至任意节点，导致原连接上下文丢失。因此，SSE推送必须依赖Redis总线进行跨节点寻址——发送端将消息发布至特定频道，所有节点订阅该频道，仅持有目标连接的节点执行实际推送。

相比之下，WebSocket因维持双向长连接，在首次握手完成后，后续通信（含心跳）通常固定路由至同一节点（尤其在启用sticky session时）。这意味着WebSocket的消息路由可部分绕过Redis总线，仅在连接迁移或节点故障时才需依赖全局映射表重定向。

上述机制在图2所示的三层结构中得以体现：上游EventSource或业务系统发出推送请求，经负载均衡层（支持轮询或一致性哈希）转发至任一工作节点；节点内部通过本地缓存与Redis映射表协同完成消息投递决策。该设计既避免了中心化网关的单点压力，又保障了连接状态的全局可见性。

另一项配套升级是管理后台（admin console）的会话共享支持。在单机模式下，用户登录态可直接存于HTTP Session；进入集群环境后，Session需跨节点同步。项目采用Spring Session + Redis方案，通过引入spring-boot-starter-session-data-redis依赖，将Session数据外置至Redis，确保用户在任意节点登录后，其认证状态均可被其他节点识别，从而实现无感切换。

图3清晰展示了SSE/WS消息在集群中的流转路径：以节点A为入口发起publishPush操作，该动作不关心当前连接归属，仅向Redis bus推送消息；各节点（如节点B）监听相同频道，收到广播后查询本地WsClientRegistry.byModule()映射表，确认自身是否持有目标连接；若命中，则调用writeAndFlush完成最终推送。整个过程无中心协调节点，符合去中心化设计哲学。

技术细节上，项目提醒使用者注意Redis协议兼容性问题：默认启用RESP3协议（Redis 6.0+特性），若部署环境使用Redis 5.x或更早版本，需显式降级为RESP2协议，否则可能导致连接异常。这一提示反映出开源项目在向下兼容性上的务实考量。

从行业视角看，实时推送系统正经历从“单体工具”向“云原生组件”的演进。传统方案如Socket.IO虽功能完备，但依赖Node.js生态且较重；而Java系方案（如Spring WebFlux + Reactor Netty）虽性能优异，却需较高开发门槛。Stream-Nexus以极简代码库（据GitHub仓库估算不足千行核心逻辑）实现SSE/WebSocket双模支持，并快速补全集群能力，体现了微服务时代对“够用就好”型基础设施的迫切需求。

类似架构已在多个中大型系统中验证可行性：例如某金融行情平台采用Redis Pub/Sub+本地连接池模式支撑百万级并发SSE连接；某在线教育平台则结合WebSocket粘性会话与Redis映射表，实现低延迟课堂互动。Stream-Nexus的开源实践，为中小团队提供了可快速落地的参考范本。

值得指出的是，集群化并非万能解药。在极端高吞吐场景下，Redis Pub/Sub本身存在扇出（fan-out）瓶颈——当订阅者数量激增时，消息复制开销会上升。对此，项目作者未作过度承诺，而是明确说明适用边界：适用于中等规模实时通知、用户在线状态同步、轻量级事件广播等场景；若需亿级连接或强事务保障，仍建议引入Kafka/Pulsar等专业消息队列。

目前，Stream-Nexus已开放全部源码至GitHub（github.com/simonking-w…），更新版本包含完整的Docker Compose部署示例与配置说明。社区反馈显示，已有数家企业将其集成至内部IM、告警中心与数据看板系统中，验证了其在真实生产环境中的稳定性。

本次升级虽源于用户需求驱动，却折射出开源项目演进的典型路径：从解决单一痛点出发，逐步构建完整能力闭环。对于需要快速搭建私有化实时通道的开发者而言，Stream-Nexus提供了一条低门槛、高可控的实施路径——它不追求大而全，而专注于把“推送”这件事做稳、做轻、做可靠。