百万级WebSocket实时推送架构：Redis Cluster会话状态管理实践

先说结论：这个项目做完之后，我最大的感受就是——WebSocket本身不复杂，复杂的是把“连接”和“状态”这两件事放进分布式架构里，还要在百万级连接的压力下不翻车。省钱返利小助手这类业务，看着是一个聊天/客服工具，本质上是一套强实时、高读写的交互系统。用户要实时看到返利到账、优惠券提醒、比价结果推送，这些场景天然需要服务端主动推送，轮询根本扛不住那个频次和延迟。而要把WebSocket连接和用户会话状态在多个节点之间协调好，Redis Cluster是目前工程上最稳、性价比最高的选择。这篇文章我按实践顺序来拆：先聊需求背后的技术账，再讲会话状态的整体设计，然后给Java侧的实现细节和Redis Cluster的容量预算，最后把上线前后踩过的坑全部摊开。适合正在做IM、客服、实时通知、在线协作这类项目的开发者参考。

1. 需求背后的技术账：为什么省钱返利场景非用这套架构不可

1.1 所谓"实时交互"，在这个项目里到底指什么

省钱返利小助手不是一个单纯的比价工具，它的核心交互链路是：用户复制商品链接过来，后台解析、查券、显示返利；用户下单后，系统跟踪订单状态、结算返利；返利到账那一刻推送给用户。这里面真正对延迟敏感的不是“查券”本身（用户能等3秒），而是“返利到账通知”和“限时优惠券变动通知”。这类消息的特点是：短、频、快，而且不可能靠客户端轮询解决。轮询的代价是按秒级拉一次接口，100万用户在线时，就算错峰，每秒也有几十万次HTTP请求打到后端，光连接开销就把资源吃掉了。

WebSocket在这里解决的是“服务端主动找用户说话”的问题。一次握手之后，服务端可以在任意时刻把消息塞给客户端，双向通信，头部开销比HTTP握手小几个数量级。同一台8核16G的机器，撑住几万条HTTP长轮询都费劲，但同样配置撑住十几万条WebSocket连接是可能的。所以这个项目从一开始就定了基调：实时消息通道用WebSocket，会话状态和跨节点协调交给Redis Cluster。

1.2 WebSocket与Redis Cluster各自解决什么问题

我拆解一下这两个组件各自的职责边界，很多团队一开始会把它们混着用，导致后面被坑。

WebSocket端解决的是“连接管理”：谁的连接打到哪台机器、连接活着还是死了、心跳由谁负责、断线之后怎么续上。这本质上是连接层的问题。连接是会移动的，比如用户断网重连，负载均衡可能把新连接分配到了另一台后端节点，这个时候旧的连接状态就不能再留在本机内存里了。

Redis Cluster解决的是“状态同步”：用户ID和sessionId怎么映射、连接落在哪台节点、用户当前订阅了哪些优惠券topic、消息要转给哪个节点去推。这本质上是状态层的问题。Redis选Cluster模式，而不是单机或主从，原因是连接与状态的映射关系在百万用户量级下必须做水平扩展，单机内存和单点风险都撑不住。

提示：这个架构里，Redis存的不是聊天记录本身，而是“会话状态”。聊天记录、返利订单详情这类数据应该进消息队列和数据库，别混在会话状态的存储里，否则Redis内存和过期策略会被拖垮。

2. 会话状态管理的整体设计：从连接到状态保持

2.1 连接生命周期与心跳机制

我在这个项目里把一条WebSocket连接的生命周期拆成五个阶段：握手鉴权、注册状态、心跳保活、消息收发、断开清理。每个阶段都对应Redis里的若干次读写。

握手阶段，客户端通过HTTP Upgrade发起请求，WebSocket底层框架（我用的Spring WebSocket，底层是Tomcat的WebSocket实现）会先走一遍拦截器，在这里做token鉴权。鉴权通过之后，onOpen回调里拿到用户身份，这时候第一步不是给客户端回“连接成功”，而是去Redis写入会话映射。

心跳是最容易被忽略的坑。TCP层有keepalive，但默认间隔太长，而且经过负载均衡和宿主机网络栈之后不可靠。应用层心跳必须自己做。我的方案是：客户端每30秒发一个ping帧，服务端收到后回pong帧；服务端同时用空闲检测，如果60秒没收到任何客户端消息，主动断开这条连接并清理Redis状态。这里有一个关键细节：心跳消息本身不要触发业务逻辑，但必须刷新Redis里的活跃时间戳，否则会出现“连接活着但状态被过期清理”的灵异事件。

断开清理阶段，onClose和onError都要走同一套清理逻辑，不要各写一遍。我踩过一次因为只处理了onClose、没处理onError，导致Redis里残留了几万条僵尸会话记录的坑。

2.2 会话状态在Redis Cluster里的存储模型

状态存储设计我前后改了三版，最终定型为三层映射，全部放在Redis Cluster里：

第一层是用户ID到会话信息的映射。Key设计为session:{userId}，Hash结构，字段包括sessionId、nodeId、loginTime、lastActiveTime。为什么用Hash而不是直接存JSON字符串？因为我想在不读取整个对象的情况下，单独更新lastActiveTime，Hash可以做到单字段更新，省流量省CPU。

第二层是会话ID到节点ID的映射。Key设计为route:{sessionId}，Value是后端节点的唯一标识（比如node-1）。这一层的意义在于消息分发时能快速找到连接落在哪台机器。如果不存这一层，每次推送消息都要全节点广播，100万连接在线时广播风暴直接能打垮网络。

第三层是在线用户集合。Key设计为online:users，用Set存储所有在线userId，用于后台统计在线人数、定向运营筛选。这层数据允许一定的延迟，所以不用每次心跳都更新，连接建立时写入、断开时移除就行。

TTL策略方面，session:{userId}设置为10分钟过期，每次心跳刷新。route:{sessionId}不设TTL，由断开事件显式删除。为什么不给route也设TTL？因为只要连接在，session一定在，但route如果提前过期，消息分发就找不到节点了；而且显式删除的路径很明确，没有漏删的理由。在线集合同样不设TTL，靠断开事件维护。

2.3 路由策略：连接与状态怎么对上

这里有个很多人会困惑的问题：WebSocket连接长在后端节点A上，订单服务在节点B上要推送消息，它怎么知道去哪找这条连接？

答案就是查Redis。完整的消息推送链路是这样的：

1. 业务服务收到“返利到账”事件，拿到userId。
2. 查询session:{userId}，拿到sessionId和nodeId。
3. 如果nodeId是本机，直接从本地连接管理器（一个ConcurrentHashMap，key是sessionId，value是WebSocketSession）拿出连接推送。
4. 如果nodeId是其他节点，把消息丢给目标节点的推送接口（我用的是内部HTTP回调，也可以用Redis Pub/Sub做广播，但广播要小心流量放大）。
5. 目标节点收到消息后，根据sessionId查本地连接管理器，推送成功返回ACK。

这五步里面，第2步是Redis读取，第4步是节点间通信，其他都是本地操作。整个链路最耗时的其实是第4步，但内部网络的延迟通常在1ms以内，可以忽略。

注意：本地连接管理器必须是内存态，不能每次推送都从Redis拿WebSocketSession对象，因为WebSocketSession是JVM对象，没法序列化到Redis里再还原成可用的连接。Redis里只存路由信息，真正的连接永远在后端节点的内存里。

3. 核心实操：Java侧的具体实现细节

3.1 WebSocket端点与鉴权接入

我用的方案是Spring WebSocket + Spring Boot，端点类用@ServerEndpoint注解那一套，但要注意容器的选择。Tomcat自带的WebSocket实现在连接数上来之后，线程模型是“每个连接一个线程”，5000个并发连接就开始明显吃力。我的做法是后端接入Netty，直接用Spring WebSocket确实省事，但Netty的线程模型撑10万连接根本不慌。这里不展开Netty的线程模型原理，只强调一点：100万级连接的规模，IO线程和业务线程必须分离，而Netty天然就是这套模型。

端点的鉴权放在握手拦截器里。客户端在Sec-WebSocket-Protocol头或者query参数里携带token，拦截器校验通过后才允许握手。校验token时顺带把userId解析出来，存入WebSocketSession的attributes里，后续onOpen直接用，不用再查一次数据库。

public class AuthHandshakeInterceptor implements HandshakeInterceptor { private final SessionService sessionService; @Override public boolean beforeHandshake(ServerHttpRequest request, ServerHttpResponse response, WebSocketHandler wsHandler, Map<String, Object> attributes) { String token = parseToken(request); UserSession user = sessionService.validateToken(token); if (user == null) { response.setStatusCode(HttpStatus.UNAUTHORIZED); return false; } attributes.put("userId", user.getUserId()); attributes.put("sessionId", generateSessionId()); return true; } }

这里有两个细节容易踩坑。第一，握手阶段的鉴权失败，不能让客户端看到详细的失败原因，否则就是给攻击者送情报，统一返回401 UNAUTHORIZED即可。第二，attributes里的参数在onOpen里可以直接通过session.getAttributes()取到，这是握手阶段往后传递数据最干净的方式。

3.2 状态写入Redis的关键代码与序列化选择

会话状态写入Redis，我有几条硬性规则：

序列化统一用JSON，不用Java原生序列化。Java原生序列化出来的二进制，读出来就是一堆\xAC\xED\x00\x05开头的垃圾，排查问题的时候在Redis里没法直观看到内容。JSON的好处是能直接redis-cli查看，线上问题定位快好几倍。

连接建立后必须先写Redis再回客户端。顺序不能反。如果先回客户端“连接成功”，然后才写Redis，这中间有几十毫秒的空窗期，用户发来第一条消息时服务端按userId查不到会话，就会误判为未注册。

@OnOpen public void onOpen(Session session) { String userId = (String) session.getUserProperties().get("userId"); String sessionId = (String) session.getUserProperties().get("sessionId"); String nodeId = NodeRegistry.getCurrentNodeId(); // 第一层：用户 -> 会话 String sessionKey = "session:" + userId; Map<String, String> sessionMeta = new HashMap<>(); sessionMeta.put("sessionId", sessionId); sessionMeta.put("nodeId", nodeId); sessionMeta.put("loginTime", String.valueOf(System.currentTimeMillis())); sessionMeta.put("lastActiveTime", String.valueOf(System.currentTimeMillis())); redisTemplate.opsForHash().putAll(sessionKey, sessionMeta); redisTemplate.expire(sessionKey, 10, TimeUnit.MINUTES); // 第二层：会话 -> 节点 redisTemplate.opsForValue().set("route:" + sessionId, nodeId); // 第三层：在线用户集合 redisTemplate.opsForSet().add("online:users", userId); // 最后才往本地连接管理器注册 LocalConnectionManager.add(sessionId, session); }

序列化我重点说一个陷阱：用GenericJackson2JsonRedisTemplate还是StringRedisTemplate？我推荐StringRedisTemplate加手动序列化，也就是写一段工具类把对象转成JSON字符串，原因有三：

第一，GenericJackson2JsonRedisTemplate会在序列化结果里额外写入@class字段，用来反序列化时还原真实类型，但Redis里存的这些元数据占了大量空间。100万用户的会话状态，每个多存20字节的class信息，就是20MB的额外内存，而且不直观。第二，手动序列化可以严格控制在同一个DTO类里增减字段，反序列化时用ObjectMapper的FAIL_ON_UNKNOWN_PROPERTIES=false，未来加字段不会把老数据卡死。第三，GenericJackson2JsonRedisTemplate偶发的类型转换异常在线上排查起来很痛苦，不如自己控制。

3.3 百万级连接下的Broker分发与消息推送设计

消息推送的分发策略是这个架构的命门。在100万连接量级下，“全覆盖广播”是一种极其昂贵的操作，一定要尽量避免。我按消息的受众范围分了三种推送模式：

定向推送，userId明确，比如返利到账，只推给某个用户。走前面说的查Redis路由链路。

组播推送，比如“全部收藏了某商品券的用户”。这些用户在Redis里维护一个group:item:{itemId}的Set，推送时遍历Set里的userId，各自走定向推送。注意这里不要用Redis的Pub/Sub做组播，因为Pub/Sub的消息是即发即弃，消费者不在线消息就丢了，而业务消息不能丢。正确做法是把消息丢进消息队列，然后消费端逐条走定向推送。我在这个项目里过了一遍消息队列，真正有延迟要求、又需要可靠投递的推送都用它。

场景广播，比如“全平台限时秒杀即将开始”，这类消息看起来要广播，但真正的受众是当前在线的、对秒杀感兴趣的活跃用户。让后端每个节点本地维护一个“在线订阅表”，广播消息只在节点间传一次，每个节点往自己本地的在线连接推送。

public void pushToUser(String userId, PushMessage message) { String sessionKey = "session:" + userId; Map<Object, Object> sessionMeta = redisTemplate.opsForHash().entries(sessionKey); if (sessionMeta == null || sessionMeta.isEmpty()) { // 离线，消息转入离线队列，等用户下次上线再补推 offlineMessageService.save(userId, message); return; } String nodeId = (String) sessionMeta.get("nodeId"); String sessionId = (String) sessionMeta.get("sessionId"); if (NodeRegistry.getCurrentNodeId().equals(nodeId)) { LocalConnectionManager.send(sessionId, message); } else { NodePushClient.send(nodeId, sessionId, message); } }

这里有一个性能隐患：每次pushToUser都读一次Redis Hash的entries，这个方法调用很频繁时，Redis的读放大就很明显。我在本地加了一个两级缓存：第一级是userId到nodeId的映射，缓存在本地内存里，30秒过期；第二级才是穿透到Redis查询。如果消息投递失败（比如目标节点返回连接不存在），再清掉本地缓存重新查一遍Redis，定位到最新节点。

4. Redis Cluster的容量与性能预算

4.1 容量估算：会话数据到底占多少内存

做容量预算的前提是把数据模型量化。我按100万在线用户来算：

会话基础数据session:{userId}，一个Hash存4个字段，Key本身约20字节，Hash的field和value加起来大约200字节，加上Redis Hash自身的编码开销，算300字节一个用户。

路由数据route:{sessionId}，Key约20字节，Value是节点ID约12字节，加上Redis DictEntry和SDS的开销，算80字节。在线集合online:users，100万个userId放进一个Set，每个元素加上集合开销大约40字节，这就是40MB。

账号体系、离线消息这些先不算，光会话状态就是100万乘以380字节，约362MB。这只是数据部分，还没算Redis的复制buffer、持久化RDB/AOF的额外消耗。所以在Cluster模式下，3主3从的架构，每个主节点分片大约1/3的数据，也就是120MB左右的数据量，留2倍内存给持久化和复制，每个节点的内存规划做到2GB以上。

这里有个容易犯的错误：按单机Redis的容量思维去配Cluster，结果每台只给512MB，上线三个月内存被打满。Redis做状态存储和做缓存不一样，缓存数据没了可以从数据库回源，但会话状态没了用户就直接断线重连，流量的尖峰和内存的持续增长需要预留足够的buffer。

4.2 热点问题与key设计规范

Redis Cluster有个特性：数据按hash slot分布，默认16384个槽位，每个key通过CRC16算法映射到槽位。多key操作（比如MGET、事务）要求所有key在同一个槽位，所以用{userId}这种hash tag可以把相关key固定到同一槽位。但这里有个权衡：如果在线用户集合、session、route都用同一个hash tag，那把大量数据打进同一个槽位，分片就失去了意义。

我的经验是：session:{userId}和route:{sessionId}不需要在同一槽位，因为它们不会在一个多key操作里同时访问。真正需要hash tag的是同一个用户的多个状态，比如session:{userId}和notify:queue:{userId}，这两个key经常一起操作。

还有一个热点问题要特别注意：在线用户集合online:users是一个超大的Set，即便只做SADD/SREM操作，在百万成员量级下，单个集合的读写也会成为Redis所在节点的CPU热点。我的处理方式是把在线集合按userId的哈希值分片，拆成online:users:0到online:users:15共16个Set，统计在线人数时把16个SCARD加起来。这样任何一个节点的负载都降下来了。

4.3 集群扩缩容对WebSocket的影响

Redis Cluster的在线迁移会对会话状态管理产生冲击，这个在架构设计阶段就要考虑到。扩容时新增一个分片，会从已有节点迁移部分槽位过去，迁移期间slot对应的key可能被阻塞几百毫秒到几秒。对WebSocket的影响是：心跳刷新或者状态查询可能超时，导致连接被误判为失效。

我采用的规避方案是：Redis客户端访问开启重试和超时熔断。心跳刷新Redis失败时，不立即断开连接，而是允许连续失败3次再断开。因为Redis迁移导致的失败是短时间的，客户端等一会就恢复，但连接一断就是大规模重连风暴，代价完全不是一个量级。

另外，要提前给Redis Cluster的客户端配置正确的拓扑刷新机制。现在用的客户端框架都支持Cluster拓扑自动刷新，但很多人默认配置没调，槽位迁移后客户端还在往旧节点发请求，导致一堆MOVED重定向错误。我在上线前专门测过一轮：扩缩容过程中，消息推送的失败率在5秒内恢复到0，才算合格。

5. 上线前后踩过的那些坑

5.1 连接风暴：把Redis打挂的一次事故

上线第一个月就出过一次事故。某个渠道做了返利翻倍活动，大量用户同时打开小程序，一瞬间新WebSocket连接数翻了十倍。每一条新连接都要写三次Redis（session、route、online集合），再加上握手前的token校验也要查Redis，Redis Cluster的主节点CPU瞬间打满，所有请求的延迟从1ms飙升到200ms，然后客户端因为超时重连，又带来新一波连接，雪崩就这样发生了。

事后复盘，加了三个保护措施：

连接建立入口加全局限流，每秒放行新连接数不超过5000条，多余连接在负载均衡层直接返回“稍后再试”。用户端有重试逻辑，短暂的拒绝并不会影响体验。

握手时的token校验不走Redis，改成JWT本地验签。原因是连接建立时的Redis写入已经不少了，校验这种读操作能省则省。JWT验签不依赖Redis，本地几微秒完成。

Redis写入改为异步批量。连接建立时的三次写操作，合并成一个pipeline提交，减少RTT。这个改动让Redis的QPS降了差不多60%，效果立竿见影。

5.2 心跳间隔不合理导致的误判

最开始心跳策略是客户端每30秒发一次，服务端空闲检测90秒断开。看起来挺合理，结果测试环境出现了一批连接被无故断开的情况。一查发现是客户端App在后台被系统挂起，心跳定时器不执行，服务端90秒没收消息就断了；用户把App切回前台，WebSocket还没重连成功，消息就丢了。

后来改成：客户端每30秒发一次心跳，服务端空闲检测放宽到180秒。同时客户端在App从后台切回前台时，主动检测WebSocket状态，如果断了立即重连，并在重连成功后拉取一次离线消息。这个改动之后，连接被误断的案例基本绝迹。

5.3 序列化版本兼容的隐形炸弹

有一次发布版本，往session:{userId}的Hash里加了一个clientVersion字段。以为很安全，结果发布后不久，大批用户的会话状态变成了空，所有在线用户被迫重连了一遍。排查发现，线上有一批老的客户端节点还在用旧代码，它们读到新的session数据结构时，反序列化用了严格模式，遇到未知字段直接抛异常，异常处理又写成了“删除整个key”，结果session被一遍遍清空。

教训有三条：

第一，反序列化必须开启FAIL_ON_UNKNOWN_PROPERTIES=false，永远不允许因为多了一个字段而反序列化失败。

第二，清理逻辑必须做到字段级，不要因为一次序列化异常就直接删除整个key。异常的时候应该保留原始数据并告警，让值班的人决定要不要清。

第三，所有状态结构的变更，先改服务端代码，灰度发布，验证稳定后再让老节点滚动升级，不要一次性全量上线。

6. 常见问题排查速查表

为了减少大家上线后的排查成本，我把这个项目里遇到过的典型问题整理成一张表，每一条都是实际踩过的：

排查时有个通用的思考顺序：先确认是不是Redis集群的问题（看慢日志、命中率、内存），再确认是不是连接管理的问题（看本机连接数、断开率），最后才怀疑业务代码。大部分“灵异事件”最后都能归到这三类里面。

7. 这套架构的边界与后续演进思路

这套WebSocket + Redis Cluster的方案，覆盖的是百万级在线、每天推送量千万级以下、会话状态不超过几百GB的场景。如果业务继续往上涨，有两个方向需要考虑演进。

一个是把状态层从Redis Cluster迁到支持水平扩展的分布式内存网格，让会话数据更靠近计算节点，减少一次Redis访问带来的开销。但引入这类组件的运维成本明显上升，不是所有项目都值得。

另一个是把消息推送从“推给节点再让节点找连接”演进成“连接自己订阅主题”的模式。也就是每个WebSocket连接在建立时声明自己关心哪几类消息，后端不做userId级别的路由查询，而是根据主题把消息送到所有订阅了该主题的连接所在节点。这个模式更省Redis访问，但要求业务方提前规划好主题分类，不适合临时起意的定向推送。

以我目前的判断，省钱返利小助手现有的业务体量，这套架构再跑两三年是够用的。它的核心价值不仅是扛住了百万用户的实时交互，更重要的是把“连接”和“状态”两层关注点分开了：今后如果节点不够，加机器就行；如果状态不够，扩Redis分片就行。两边独立扩，互不牵连，这比一开始就上一套重型的消息中间件方案要务实得多。最后再提一个容易被忽视的细节：所有Redis的key命令用对了，大量耗时其实出在客户端的连接池配置和序列化选择上，这些基础组件在压测阶段花一小时调好，线上能少熬三个通宵。