websocket + redis pub/sub 做实时更新应该如何设计

資深大佬 : chenglushe 4

目前我的结构是：

每个用户访问页面后会立即建立 websocket 长连接。
每个用户的 websocket 在连接建立时(on_open ）会建立一个 redis connection，这个 redis connection 用来 subscribe 一个固定的 channel
当某个模型更改需要通知前端时，会用一个全局的 redis connection 来 publish 相关的内容到 channel 。
在第二步中订阅 channel 的回调会用 websocket 将更新的模型数据发给前端，前端实现实时更新。
用户离开页面后在触发 websocket 的 on_close 回调，回调中关闭用户 redis 链接。

这种方案每个用户访问页面都会建立一个 redis 连接，而 redis 默认的最大链接数是 10000，也就是说在默认配置下页面最多承载 10000 左右个用户。想请教下各位大佬这种设计是否合理。

大佬有話說 (15)

資深大佬 : RickyHao

不是，redis 连接不应该在后端用连接池维护吗？

主資深大佬 : chenglushe

@RickyHao redis 的 subscribe 是阻塞的，我目前是每个用户都起一个 redis 连接来 subscribe channel

資深大佬 : hly9469

webdis

資深大佬 : kaifang

之前做过类似的实验，不过用的是 mqtt + websocket 做的实时更新，用的是 emqx,号称百万级别连接，估计问题不大。

資深大佬 : RickyHao

那你复用一个 sub 啊，通过内容里加标识来区分用户，然后后端做路由给各个 ws 连接

資深大佬 : swulling

单机一万个用户还不够？

主資深大佬 : chenglushe

@kaifang 也是这种结构吗？一个用户对应一个 broker/subscriber

主資深大佬 : chenglushe

@swulling 只是想知道这种设计是否合理，有没有更好的方案

主資深大佬 : chenglushe

@RickyHao 感谢，我尝试一下

資深大佬 : huntcool001

Redis pub/sub 几乎不具有实际使用意义. 因为消费者一旦掉线啥的,没消费到那个消息,那个消息就丢失了.

用 Redis5.0 里面的 Stream 吧.

还有一个方法是写个 Lua 脚本来当消费者,把订阅收到的信息存到某个 list 里. 实际消费者去 list 里消费. 因为 Lua 脚本存活在 Redis 服务器上,也就不存在掉线的问题了.

資深大佬 : h123123h

用 mq 把消息推送给 websocket chanel

資深大佬 : chihiro2014

Spring Reactor 了解下？

主資深大佬 : chenglushe

@huntcool001 感谢，粗略了解了下也支持多播，并且有 ack 确认机制保证不丢消息，应该可以被用来做 pusher

資深大佬 : sujin190

似乎这种短时页面上用的使用轮询机制感觉更简单的感觉，后台没过一段时间无数据超时就返回，有数据就返回数据，前端不延时，后台用个分布式锁啥的等待机制，需要返回的数据放到 redis 种，感觉结构更简单啊，直接 jquery ajax 就行，啥长连接啥心跳啥重试啥啥都不用管，容错啥的页更容易吧

主資深大佬 : chenglushe

@sujin190 我们是 web app，不是简单的页面，所以还是 websocket 更好些吧。