來自后端的實時用戶通知，具有 PubNub、可擴展性和 9000 多個聊天室

Question

我正在開發一個非常有趣的 Web 應用程序項目，該項目可以變得相當大，我有機會使用這個名為PubNub方便的東西作為應用程序的主要實時引擎。

因此，它是一個帶有Node.js后端的 Web 應用程序，涉及用戶之間潛在的大量聊天室以及當數據庫中的某些數據更新時后端向用戶發送的實時通知。

通常，使用Sockets.io開發時，我只會為每個用戶訂閱其唯一數據庫 ID 的頻道，以及代表不同聊天室的頻道。

這樣我就可以在后端處理聊天室和身份驗證，在數據庫中存儲一些個人通知后，我可以輕松地將它們推送到由用戶 ID 命名的頻道，所以如果用戶在線 - 他得到它，如果沒有 - 很好，他會看到它下次登錄時，通知已在數據庫中。 從理論上講，在 redis pub/sub 的幫助下，這個怪物應該可以很好地橫向擴展。

在這種情況下，讓我擔心 PubNub 的是可擴展性。 由於我顯然不了解 PubNub 后端的暗角中發生了什么，我想確保該應用程序的構建方式可以准備好處理一些晦澀的同時用戶數量龐大的情況。

我的問題是，使用PubNub構建這樣一個系統的最佳方法是什么？

1. 我是否正確假設需要向特定用戶推送通知，訂閱該用戶的pubnub，推送注釋和取消訂閱會更好。 好像我將保持所有在線用戶通道打開一樣 - 那么在我的服務器上使用 PubNub 而不是 websockets 沒有任何意義，因為服務器無論如何都會承受所有這些打開的在線用戶通道的負載，並且應該進行擴展以保持巨大他們的數量。
2. 用戶授權呢？ 在不涉及我的后端的情況下，我如何確保發布一些消息的用戶無法偽造他的個性，並且與他在應用程序內部進行身份驗證的情況完全相同？
3. 通常（以及通過 PubNub）處理每個用戶的大量聊天的最佳實踐是什么？ 就像在應用程序中每個用戶可能會積累一些相當數量的垃圾聊天室，其中有一些用戶，盡管很久沒有人接觸過，用戶也懶得手動離開它？

感謝您耐心閱讀這面文字牆！

Answer 1

2020 年 5 月 15 日更新我們有一些新文檔，它們將以更清晰的術語解釋以下大部分內容。

以及可應用於以下許多問題/答案的新功能：

• 消息操作
• 消息計數
• 批處理歷史記錄（多通道消息獲取）
• 對象（用戶、頻道和成員資格元數據） - 等待對象 v2（即將推出）

注意：我在下面的答案中撒了一些上面的鏈接。

---

首先，讓我們解決這個...

在這種情況下，讓我擔心 PubNub 的是可擴展性。 由於我顯然不了解 PubNub 后端的暗角中發生了什么，我想確保該應用程序的構建方式可以准備好處理一些晦澀的同時用戶數量龐大的情況。

和這個...

那么在我的服務器上用 PubNub 代替 websockets 沒有意義，因為服務器無論如何都會承受所有那些打開的在線用戶通道的負載，並且應該擴展以保持它們的大量

這有點倒退，因為您將使用 PubNub 之類的服務來確保您的應用程序可擴展以處理數百萬用戶。 PubNub 擁有數千名客戶，可擴展到數百萬用戶和 100 億條消息。 不知道 PubNub 如何做到這一點，您可以自由地實現應用程序的 biz 邏輯。

但我想我明白你在說什么。 您的印象是您的服務器必須參與每個用戶的每個聊天室交互，但這只是部分正確。 大多數情況下，您的服務器將用於身份驗證、一些訂閱維護（可選），並且可能根據需要（取決於您的要求）向一個、多個或所有最終用戶發送消息。

這里有一些嘗試來回答你的問題，盡管它們有點到處都是，所以我會盡力回答我認為你在問什么。

問題 1

這個問題似乎是為了維護對頻道的大量訂閱及其可擴展性。

一般來說，每個最終用戶都會初始化 PubNub 並訂閱他們需要收聽的頻道，並發布到他們需要發送消息的頻道。 通常，他們發布的頻道（我假設是您的聊天室）與他們訂閱的頻道相同，但有不同類型的用例。 您可以一次訂閱數千個頻道（每個客戶端最多 20K）。 如果您使用 WebSockets 做到這一點，您將如何將其擴展到數百萬用戶？ 您將實現和操作（擴展）類似於 PubNub 的東西（既不容易又不便宜）。

現在，如果用戶訂閱了一堆聊天室頻道，但其中一些或許多頻道已經過時（用戶有一段時間沒有查看或發布過），則您的服務器（或客戶端）上可以有一些代碼來監視用戶的活動，並從這些陳舊的頻道中取消訂閱。 這可以使用通道組來實現。 每個最終用戶都有自己的頻道組，其中包含他們正在收聽的所有頻道。 以及客戶端代碼或服務器代碼，並在這些最終用戶的頻道組中添加和刪除頻道。

問題2

更新文檔： https : //www.pubnub.com/docs/platform/security/access-control

現在這個問題更加清晰和集中，並且詢問身份驗證（登錄）以及如何確保某人是他們所說的人以及如何處理授權（他們可以做什么和不能做什么）以及在哪里/誰控制這一點。

答案是，您控制身份驗證（登錄）以證明此人就是他們所說的那樣。 您的登錄過程會檢查有效的用戶名/密碼，並且在用戶記錄中，您將擁有該用戶的訪問控制列表。 有了它，您就可以生成一個授權密鑰，授予對一個或多個通道的讀和/或寫訪問權限。 此授權是您的服務器調用的 PubNub 操作。 auth-key 被傳遞回客戶端，客戶端代碼使用 pub/sub 密鑰和這個 auth-key 初始化 PubNub 實例，PubNub 服務器使用這個 auth-key 根據通道和請求的操作來檢查訪問（訂閱這個通道，發布到該頻道等）。 如果 auth-key 沒有正確的訪問權限，PubNub 服務器將拒絕訪問（403 響應）。

所有這些還有更多，但這是一個好的開始。 閱讀 PubNub Access Manager，了解您將在我們的文檔頁面上使用的 SDK。 例如，您可以從JavaScript SDK Access Manager docs and tutorials 開始。

問題 3

更新文檔： https : //www.pubnub.com/docs/platform/channels/receive#subscribe-to-channels

我相信我用問題 1 - 渠道組充分回答了這個問題。 從JavaScript SDK Stream Controller（提供頻道組功能）文檔和教程開始。

我希望我已經成功地讓您在使用 PubNub 的過程中更進一步，實現了一個非常成功的實時數據流應用程序。 請回復您可能仍有的任何其他問題。

---

對您的新評論的回答：

感謝您的跟進評論。 你現在問的問題很清楚。

為此，我需要將聊天室時間戳與個人用戶上次閱讀時間戳進行比較，因此似乎我需要從后端收聽這些頻道並更新用戶的上次閱讀，或者信任前端，然后獲得直接來自用戶的時間戳

不，您不必收聽服務器上的頻道。 是的，從客戶端應用程序，您將保留上次收到消息的時間戳。 當用戶重新上線時，您可以使用此時間戳來獲取客戶端訂閱的頻道的歷史記錄。 許多人已經成功地做到了這一點，我們將在未來幾個月內發布一些驚人的功能，這將大大簡化這一過程。

從后端向用戶推送實時通知。 如果我想隨時向他們推送筆記，是否需要訂閱我的所有用戶頻道

您可以在任何頻道上發布，而無需先實際訂閱。 因此，您的服務器可以根據需要發布到頻道。

和以前一樣，根據您的需要繼續提出更多問題。

---

很好的后續問題。 這是我的建議

......因為不是從數據庫請求所有這些聊天室並通過pubnub加入所有這些聊天室，而是實現分頁......用戶如何知道可能出現在他的舊聊天室中的新消息？

同樣，您可以使用頻道組訂閱 2 萬個頻道。 您可以訂閱 10 個頻道組，每個頻道組有 2K 頻道 - 但我建議只將用戶限制為 100 或更少，因為這似乎足以在您的應用中施加限制。 但是選擇你想要的任何上限，當用戶達到這個上限時，強迫他們先離開另一個聊天室，或者建議他們離開前 10 個最不活躍的聊天室，或者一些對你的應用有意義的算法。

更新文檔： https : //www.pubnub.com/docs/platform/channels/receive#subscribe-to-channels

獲取丟失消息的數量確實需要獲取完整的歷史記錄，但我們將在不久的將來提供改進的 API 以使其更簡單。 但是如果用戶在所有這些渠道上注冊了推送通知，設備將能夠接收這些推送消息，並且您的應用程序可以在本地保留該計數。 我們將很快發布一篇“如何在后台更新徽章計數”的文章。 您還可以使用它來跟蹤每個頻道（聊天室）錯過的消息數量。

現在我只想限制可供用戶使用的房間數量，比如說一百個，然后在沒有分頁的情況下請求和加入他們。

更新文檔： https : //www.pubnub.com/docs/platform/channels/retrieve

我們確實有客戶這樣做而不必擔心分頁。 他們只是檢索設備訂閱的 100 個頻道的歷史記錄。 使用后台徽章計數更新器技術，您將有優勢知道當應用程序處於活動狀態時要從哪些渠道獲取。 該文章發表后，我將在此處發布該文章的鏈接。