是否可以以這種方式使用 Node-Redis 還是我會堅持使用 websockets？

Question

我一直在考慮一個涉及以下內容的設計：

1. 客戶端向端點發出 POST 請求
2. 然后該路由（從返回我字符串化的請求對象的構造函數）發布到 redis 通道。 例如

( {request: String, transid: String, data: Object } )

3. 另一台服務器偵聽該通道，解析 JSON -> 從 obj 切換請求密鑰
4. 是否具有驗證憑據等功能；
5. 調用一個類，該類返回一個轉換為 str 的預制響應對象，並通過同一個（或另一個通道）發送回正在異步偵聽等待的路由處理程序（通過該通道發送原始請求）（在這種情況下，固定。）例如
   ( { "transid": "1234-Abcd-5678-abcde", "state": Boolean, data: <data> } )

時間線

路由處理程序向 redis 偵聽器發出 Pub 請求：

1. ( {request: "auth", transid: "1234-Abcd-5678-abcde", data: { email: "test@test.com", "password": "pass" } )

2. 另一台服務器上的訂閱偵聽器進行內部憑據驗證

發布回 redis 頻道

3. ( {transid: "1234-Abcd-5678-abcde", state: false, data: { error: "Incorrect" } } )

4. 路由處理程序使用特定於庫的方法回復客戶端，即 request.send(200)

我的問題是我不完全理解如何實現上述時間線中第 4 步的結果； 即在路由處理程序中甚至有可能幾乎等待消息嗎？ 我已經非常接近了，但是當我設計可以擴展的東西時，我懷疑這是否是一種實用的處理方式。 （用戶將詳細信息發送到 /endpoint，/endpoint 路由處理程序將 json 消息發布到通道，外部服務器偵聽解析消息並將其發送到 switch 語句，即 [switch(data.request)]，該語句調用執行 DB 的函數操作，然后使用類構造函數生成一個對象，該對象通過 redis 通道發送回等待回復的路由處理程序，然后回復給客戶端。）

請問有人對此有什么看法嗎？

Answer 1

pub/sub 背后的概念是解耦和執行異步任務，但您正在強制系統采用同步風格，這使他的所有優點都消失了。

例如：如果您發布消息，則沒有訂閱者收到它……您會怎么做？ 重試？ - 客戶端超時，錯誤？ - 但用戶只想登錄並且數據庫正在運行

此外，當流量增加時，響應會變慢，因為由於 pub/sub 是廣播，您將只有一個訂閱者可以接收所有這些消息，並且您不想處理兩次登錄邏輯！ （我假設）

因此，要解決此問題，您應該實現對等邏輯，其中： - 所有訂閱者都收到消息 - 每個訂閱者都彼此認識 - 一個訂閱者說“我會做這項工作” - 一個“主要”訂閱者說沒問題 - 另一個訂閱者丟棄消息 - 主要訂閱者崩潰，您需要選舉以擁有新的主要訂閱者.. - 等等...

但這是消息代理或redis流api所做的，因此您無需自己實現。 我過去做過，但 Redis 5 還不存在。

由於這些原因，我認為您應該以同步方式進行同步工作。 發布/訂閱不適合您的使用示例。