多实例部署下WebSocket连接共享方案及序列化报错如何解决

首先明确一个基础误区：WebSocket连接本质是当前进程持有的TCP网络句柄，和创建它的实例进程强绑定，根本无法序列化后跨实例传递，你遇到的TypeError: Converting circular structure to JSON报错只是最表层的问题，就算你解决了序列化问题，把连接对象存在数据库里，其他实例拿到也没法用，这条路从底层逻辑上就走不通。

目前行业内成熟的实现方案主要有两种，适配不同的业务场景：

方案1：中心化映射+跨实例消息广播（通用性最强，适用绝大多数场景） #

• 核心逻辑：不尝试共享连接本身，只在共享存储里存轻量的关联映射，每个实例独立维护自己本地的连接池
• 落地步骤：
  1. 客户端和实例完成WebSocket握手后，当前实例生成该连接的唯一业务标识（比如用户ID、会话ID，根据你自己的业务定），将「连接标识 <> 当前实例ID」的映射关系写入Redis/PG，可设置过期时间略长于WebSocket的超时断开时间
  2. 每个实例自己在内存里维护HashMap，存储当前实例上所有存活的连接对象，只在当前实例内读写
  3. 当任意实例收到指定连接的推送需求时，先查共享存储里的映射，拿到目标连接所在的实例ID
  4. 如果目标是当前实例，直接从本地HashMap取出连接执行推送
  5. 如果目标是其他实例，通过消息队列（Redis Pub/Sub、RabbitMQ均可）向所有实例广播推送事件，事件内容包含目标连接标识和待推送的 payload
  6. 所有实例都订阅同一个广播主题，收到事件后检查目标连接是否在自己的本地连接池内，存在就执行推送
• 边界处理：连接正常断开时主动删除共享存储里的映射；如果实例异常宕机没来得及清理，可通过定时任务扫共享存储的映射，和服务注册中心的存活实例比对，清理无效实例对应的脏映射即可。

方案2：负载均衡层配置会话粘滞（改造成本最低，适合特定场景） #

• 核心逻辑：在接入的负载均衡服务上开启会话保持（会话粘滞），保证同一个客户端的WebSocket握手请求和后续所有关联请求，都转发到同一个实例上
• 优势：完全不用调整现有业务逻辑，你原本写的本地HashMap存连接的代码可以直接用
• 局限性：仅适合推送请求由客户端触发的场景，如果推送是服务端内部主动发起的，无法保证请求落到对应实例上；实例宕机时该实例上的所有连接会批量断开，需要客户端实现自动重连逻辑兼容。

关于你提到的数据库实现方式：共享存储只需要存「连接标识-实例ID」的纯文本映射，完全不需要涉及连接对象本身，不存在序列化问题，不管是Redis还是PG都可以直接存。

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