服务端如何实时同步状态变化？

不需要解决，本身就是得支持多个长连接

非得长连接？轮询不行么？

这个网关的会话保持就解决了吧

长连接接入需要一个 session 服务维护每个会话对应的连接
扫码登录轮询就行了

@spritecn 不行吧，因为扫码的是手机端，并不能保证请求同一个服务吧？

@fingerxie 网关的会话保持一般无非就是 iphash 或是插 session 的思路,有啥不行

轮询不会比长连接消耗大

前端轮训，简单高效，登录并发也不会太高

连微信官网的扫码登录都是轮询…… https://mp.weixin.qq.com/ 折腾长连接干啥呀

redis publish ？消息队列广播？

直接轮询，方案越简单，可靠性越高

生成个 id 啊

轮询还是长链接要看你业务的契合度。
至少前几年，我专门研究了下，淘宝的扫码登录就是轮询，微信的就是长链接。
非常契合这两家的业务基础。淘宝就是查询多，微信作为聊天软件就是擅长维持长链接。

一两秒一个轮询对用户来说也不是不可以，用户体验没差别

微信支付宝都是轮询

其实这种还是使用 long polling 轮询实现更简单快捷，搞个异步 IO 的框架，挂起实现不要太简单

不说你业务的实现方式，只说你关心的点，我猜是在分布式环境中，客户端之间如何通信？就是消息路由。要么广播；要么有个中心负责转发给客户端所在的服务器，再下发给客户端。中心可以是消息队列。

简单轮询的方式，就是查数据库，数据库就是中心，主动去取。

@hellomsg 是这样，我也考虑采用消息队列来做。利用广播消息的机制实现。不过我在想有没有什么更好的方案

之前做的扫码登录都是用的轮询

轮询啊，http 哪怕是长链接（事实上默认都是长链接）你也是无法反向推送消息的。

前端轮询是最简单的，后端任意节点状态更新到 redis ，接口直接查询 redis 数据返回，最多加个 db 查询兜底。
如果一定要长连接，也有简化方案，前端到接口用 websocket/sse ，接口实际还是轮询 redis 并返回，这样即使重新连接到不同节点也无所谓，一定程度算是无状态的。
更加麻烦的方案：
- 多个 websocket 节点，mq 广播结果(引入额外依赖和故障点 mq)
- 中心化维护用户与节点的连接信息，这样可以直接通知到对应节点(引入中心化信息更新问题)
- websocket 节点直接互相连接，对于不是自己的消息用 rpc 或者 websocket 或者 http 转发到其他节点(复杂度最高)
这 5 个方案前 4 个都有用过，最后发现 1 方案反而是最好的，实现简单，无状态易扩展，故障点少。2 3 也比较可靠，增加些复杂度。4 踩过坑之后不准备用了。