应用选型咨询：SSE与WebSockets在转账交易通知场景的对比选择

仅需服务端单向推送的业务场景下，优先选择SSE作为推送方案，百万级并发场景下的稳定性和运维成本都优于WebSocket

方案选型对比 #

SSE适配性 #

• 天生基于HTTP协议，服务端实现成本极低，所有主流浏览器、移动端原生支持，不需要引入额外的客户端SDK
• 自带自动重连、消息ID追踪能力，网络波动后的消息连续性不需要额外开发
• 基于HTTP/2部署时可复用TCP连接，单台4核8G的服务端可稳定承载10万+活跃SSE连接，资源开销比同量级的WebSocket集群低30%以上
• 现有负载均衡、网关组件原生支持，不需要额外配置长连接升级、帧解析规则，运维成本极低

WebSocket适配性 #

• 核心优势是支持双向通信，你的业务场景暂不需要该能力，属于能力冗余
• 握手、帧解析逻辑比SSE复杂，单台服务端承载的活跃连接上限比SSE低20%~40%
• 集群部署需要额外配置负载均衡的长连接保活、跨节点会话同步规则，运维成本更高

单用户定向推送实现逻辑 #

该逻辑对SSE和WebSocket通用：

1. 客户端发起连接时，在请求参数/头中携带已签名的身份凭证（比如JWT），服务端校验凭证合法性后解析出对应用户ID
2. 服务端维护「用户ID-活跃连接实例」的映射关系：单机部署可存在本地内存Map中，集群部署可借助Redis存储「用户ID-连接所在节点IP」的映射
3. 转账交易成功后，交易服务生成收款方通知，携带收款方用户ID发送到推送服务
4. 推送服务根据用户ID查询对应连接，将消息写入对应连接的输出流即可完成定向推送
5. 额外注意：需要定期发送心跳包检测连接存活状态，用户断开连接后及时清理映射关系避免内存泄漏

百万级并发稳定性优化建议 #

• 推送服务和交易服务解耦：用消息队列中转交易通知，交易成功后先将通知写入MQ，推送服务异步消费消息完成推送，避免交易链路受推送服务故障影响
• 集群路由优化：推送集群不要全量广播消息，而是根据Redis存储的用户-节点映射，将消息路由到用户连接所在的对应节点，降低集群内部通信开销
• 离线消息兜底：如果用户当前无活跃连接，将通知存入离线消息表，用户下次上线后主动拉取未读通知，保证消息不丢失
• 连接复用：优先用HTTP/2部署SSE服务，单个TCP连接可承载多个用户的SSE会话，大幅降低服务端TCP连接、端口占用开销

内容的提问来源于stack exchange，提问作者A.Codera