你來說說 websocket 有什么用

雙向通信，服務(wù)器端可以主動 push，給客戶端發(fā)送通知

那websocket多個節(jié)點有什么問題？

頭條面試官的提問讓我的回憶飄到了一個下午，想起了我兩個同事之間的對話

引子

咱有部分用戶收不到通知了

通知是由ws服務(wù)控制的，它最近是有啥改動么

也沒改啥，以前單個節(jié)點也沒有問題

想起來了，接上面通知，把服務(wù)都從單節(jié)點改成了多節(jié)點

對，說是為了什么 HA，兩位數(shù)用戶的服務(wù)需要折騰嗎

沒事，這樣出去了也有搭建高可用服務(wù)與 websocket 負載均衡的經(jīng)驗了

說的倒也是！不過這樣確實會有 ws 分布式的問題

簡單，加個 reids 就好了

多節(jié)點問題

在開始思考分布式會有什么問題時，先來回答一個問題: 服務(wù)端如何與客戶端交流？

在 ws 服務(wù)端，當與客戶端連接成功后，會生成一個對象 connection，ws 會維護一個與客戶端所有連接的 connections。如果想要主動推送消息到客戶端，只需要調(diào)用API connection.sendText(message)。

那如何給所有人廣播消息呢？

服務(wù)器只需要與它自身的所有連接 server.connections 挨個發(fā)消息就是廣播，所以它只是一個偽廣播：我要給群里所有人發(fā)消息，但我不能在群里發(fā)，只能挨個私發(fā)。

單節(jié)點

當單節(jié)點時所有用戶都能正常受到通知，流程如下

這時所有用戶都能收到消息通知

多節(jié)點

當多節(jié)點時，就會有部分用戶無法正常受到通知，從以下流程圖中可以很清楚地看到問題所在

負載到節(jié)點2的所有用戶都沒有收到消息通知

如何解決

多節(jié)點服務(wù)器就會有分布式問題，解決分布式問題就找一個大家都能找到的地，比如說 Redis，比如說 Kafka 等消息件

改進后流程圖如下

1. 需要向所有用戶推送消息，請求 websocket 服務(wù)

2. 負載均衡到某個節(jié)點

3. 該節(jié)點向 redis/kafka 推送消息: 向所有用戶推送消息通知

4. 所有節(jié)點在 redis/kafka 上訂閱消息

5. 訂閱成功后所有節(jié)點向客戶端 push 消息

redis PUBSUB

其中有一個細節(jié)是 pub/sub 那里，redis 的 pubsub 較 Kafka 等消息中間件更為輕便，最主要的是與ws集成的社區(qū)方案比較成熟，這點很重要，如 Node 中的以下兩個

• graphql subscriptions - redis

• socket.io-redis

pubsub 在 redis 中的命令如下

• pub: publish channel message

• sub: subscribe

如果我們要訂閱 eat 這個 channel 的話，圖示如下

小結(jié)

借用解決方案的圖作為小結(jié)