来自具有PubNub，可伸缩性和超过9000个聊天室的后端的实时用户通知

Posted 2023-02-24

我正在开发一个非常有趣的Web应用程序项目，该项目可能会变得很大，并且我有机会尝试使用名为PubNub的便捷工具作为应用程序的主要实时引擎。

因此，它是一个具有Node.js后端的Web应用程序，涉及到用户之间潜在的大量聊天室以及当数据库中的某些数据更新时后端发送给用户的实时通知。

通常，使用Sockets.io进行开发，我将只为每个用户订阅其唯一DB ID的频道，并订阅代表不同聊天室的频道。

通过这种方式，我可以处理后端的聊天室和身份验证，并且在将一些个人通知存储在数据库中之后，我可以轻松地将其推送到以用户ID命名的频道，因此，如果用户在线-他可以（如果可以）-很好，他会在下次登录时看到它，通知已在数据库中。从理论上讲，这种怪物应该在redis pub / sub的帮助下在水平方向上很好地缩放。

在这种情况下，我担心PubNub的是可伸缩性。由于我显然对PubNub后端的黑角中所发生的事情一无所知，因此我想确保该应用程序的构建方式使其可以处理一些晦涩难懂的大量同时用户。

我的问题是，用PubNub建立这样的系统的最佳方法是什么？

1. 我是正确的假设，如果需要向特定用户推送通知，则订阅该用户的发布，推送注释和退订会更好。好像我将所有在线用户通道保持打开状态一样-服务器上的PubNub而不是websockets没有意义，因为服务器无论如何都将承受所有打开的在线用户通道的负载，因此应进行扩展以保持庞大的在线用户通道数量。
2. 用户授权如何？在不涉及后端的情况下，我如何确定发布某些消息的用户将无法伪造自己的个性，并且与在应用程序内部进行身份验证的身份完全相同？
3. 并且通常（并通过PubNub）什么是处理每个用户大量聊天的最佳实践？可以这么说，在应用程序生命周期中，每个用户可能会积累一些相当数量的垃圾聊天室，其中有些用户在其中，尽管很长一段时间都没有人碰过它，而且用户太懒了，无法手动离开它？

感谢您耐心阅读本文墙！

答案

2020年5月15日更新我们有some new docs可以用更清楚的术语解释下面的许多内容。

以及可以应用于以下许多问题/答案的新功能：

• Message Actions
• Message Counts
• Batch History (multi-channel message fetch)
• [Objects (Users, Channels and Memberships Metadata)-在此等待对象v2（即将推出）

NOTE：在下面的答案中，我已经添加了一些上面的链接。

---

首先，让我们解决这个问题...

在这种情况下，我担心PubNub的是可伸缩性。当我 显然不了解PubNub后端的黑暗状况 角落，我想确保该应用程序的构建方式 准备处理一些晦涩难懂的 同时使用的用户。

和这个...

然后，在PubNub中没有任何意义，而不是服务器上的websocket， 因为无论如何，服务器将承受所有打开的在线用户的负载 渠道，应该进行扩展以保持大量渠道]

这有点倒退，因为您将使用PubNub之类的服务来确保您的应用程序可扩展以处理数百万个用户。 PubNub拥有成千上万的客户，可扩展到数百万用户和1000亿条消息。不知道PubNub如何做到这一点使您可以释放应用程序的业务逻辑。

但是我想我明白你的意思。您的印象是您的服务器必须参与每个用户的每次聊天室交互，但这只是部分正确。通常，您的服务器将用于身份验证，一些订阅维护（可选），并可能根据需要（取决于您的要求）用于向一个，多个或所有最终用户发送消息。

尽管这里到处都有一些尝试，但仍会尝试回答您的问题，所以我会尽我所能回答您认为的问题。

问题1

这个问题似乎是针对维护频道的大量订阅及其可扩展性。

通常来说，每个最终用户都会初始化PubNub并订阅他们需要收听的频道，并发布到他们需要在其上发送消息的频道。通常，它们发布的渠道（假设是您的聊天室）使用的是相同的渠道，但是存在不同的用例。您一次可以订阅数千个频道（每个客户端最多2万个频道）。如果使用WebSockets进行此操作，您将如何扩展到数百万用户？您将实现和操作（按比例缩放）类似于PubNub的东西（既不容易也不便宜）。

现在，如果用户订阅了一系列聊天室频道，但其中一些或多个是陈旧的（该用户一段时间未查看或发布），则您的服务器（或客户端）上可能会有一些代码，监视用户的活动，并从那些过时的频道退订他们。使用channels groups可以做到这一点。每个最终用户将拥有自己的频道组，其中包含他们正在收听的所有频道。以及客户端代码或服务器代码，并在这些最终用户的频道组之间添加和删除频道。

问题2

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

现在，这个问题更加清晰和明确，它在询问身份验证（登录），以及如何确保某人就是他们所说的身份，以及如何处理授权（他们可以做什么和不能做什么）以及在哪里/由谁控制。

答案是，您控制身份验证（登录）以证明此人就是他们所说的。您的登录过程将检查有效的用户名/密码，并且在用户记录中，您将获得该用户的访问控制列表。这样，您将生成一个授权密钥，该授权密钥将授予对一个或多个通道的读取和/或写入访问权限。此授予是服务器调用的PubNub操作。 auth-key传递回客户端，并且客户端代码使用pub / sub密钥和PubNub服务器用来根据通道和所请求的操作检查访问权限的auth-key初始化PubNub实例（订阅此通道） ，发布到该频道等）。如果auth-key没有正确的访问权限，则PubNub服务器将拒绝访问（403响应）。

所有这些还有更多，但这是一个好的开始。在我们的“文档”页面上，使用将要使用的SDK的PubNub Access Manager进行阅读。例如，您可以从JavaScript SDK Access Manager docs and tutorials开始。

问题3

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

我相信我对问题1-渠道组的回答足够充分。从JavaScript SDK Stream Controller (which provides Channel Group feature) docs and tutorials开始。

我希望我已经成功地将您带到使用PubNub的高度成功的实时数据流应用程序的过程中。请回答您还有其他问题。

---

回答您的新评论：

感谢您的后续评论。很清楚您现在要问什么。

我需要将聊天室的时间戳记与个人用户进行比较 最后读取的时间戳，所以看来我需要听 后端的那些渠道并更新用户的最后阅读，或信任 进入前端，并直接从用户那里获得时间戳记

不，您不必收听服务器上的频道。是的，从客户端应用程序，您将保留最后收到的消息的时间戳。当用户重新联机时，您可以使用此时间戳来获取客户端订阅的频道的历史记录。许多人已经成功地做到了这一点，我们将在未来几个月内发布一些惊人的功能，这些功能将大大简化这一过程。

从后端向用户推送实时通知。我需要成为 如果我想向他们推送注释，请订阅我所有的用户频道 随时

您可以在任何频道上发布，而无需先实际订阅。因此，您的服务器可以根据需要发布到频道。

和以前一样，根据需要不断提出更多问题。

---

再次进行重大后续问题。这是我的建议

...这使得不向DB请求所有这些聊天室， 通过pubnub所有人加入，而是实现分页...如何 用户可以知道他的旧聊天中可能出现的新消息 房间？

同样，您可以使用频道组继续订阅2万个频道。您可以订阅10个频道组，每个频道组2K个频道-但我建议仅将用户限制为100个或更少，因为这似乎足以限制您的应用程序。但是请选择您想要的任何上限，当用户达到该上限时，强制他们首先离开另一个聊天室，或者建议他们离开最不活跃的前十名之一，或者使用对您的应用有意义的算法。

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

获取遗漏消息的数量确实需要完整的历史记录获取，但是我们将提供改进的API，以便在不久的将来使此操作更简单。但是，如果在所有这些渠道上为用户注册了推送通知，则该设备将能够接收这些推送消息，并且您的应用程序可以将该计数保留在本地。我们将很快发表一篇“如何在后台更新徽章计数”的文章。您还可以使用它来跟踪每个频道（聊天室）中错过的消息数。

目前，我只想限制用户可使用的房间数量 比方说一百，并且请求并且不分页地加入他们。

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

我们确实有这样做的客户而不必担心分页。他们只是检索设备已订阅的100个频道上的历史记录。使用后台徽章计数更新器技术，您将有一个优势，当应用程序启动时，知道从哪个渠道获取信息。发布该文章后，我将在此处发布该文章的链接。