来自后端的实时用户通知，具有 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 个频道的历史记录。 使用后台徽章计数更新器技术，您将有优势知道当应用程序处于活动状态时要从哪些渠道获取。 该文章发表后，我将在此处发布该文章的链接。