我正在做一个非常有趣的web应用程序项目，它可能会变得相当大，我有机会玩这个叫做PubNub的方便的东西作为应用程序的主要实时引擎。
所以这是一个web应用程序与Node.js后端，涉及潜在的大量用户之间的聊天室和实时通知发送给用户时，后台数据库中的一些数据更新。
通常，使用Sockets.io开发时，我只会为每个用户订阅其唯一DB id的频道，以及代表不同聊天室的频道。
这样我就可以处理聊天室和身份验证后端，在数据库中存储一些个人通知后，我可以很容易地将它们推送到由用户id命名的通道，所以如果用户在线-他得到它，如果不是-很好，他会在下次登录时看到它，通知已经在数据库中。从理论上讲，这个怪物应该在redis pub/sub的帮助下可以很好地横向缩放。
在这种情况下，我担心的是PubNub的可扩展性。因为我显然不知道PubNub后台的黑暗角落里发生了什么，我想确保应用程序的构建方式能够处理一些模糊的、巨大的、同时存在的用户。
我的问题是，用PubNub构建这样一个系统的最佳方法是什么?
- 我是否正确假设它会更好，需要推送通知给特定用户，订阅该用户的pubnub，推送通知和退订。如果我将保持所有在线用户通道打开-那么在PubNub中没有任何意义，而不是在我的服务器上的websockets，因为服务器无论如何都会承受所有这些打开的在线用户通道的负载，并且应该扩展以保持大量的在线用户通道。
- 用户授权呢?不涉及我的后端，我怎么能确保用户发布一些消息将无法伪造他的个性，并将有完全相同的，因为他已经验证内部应用程序?
- 一般来说(通过PubNub)解决每个用户大量聊天的最佳实践是什么?比如，在应用程序的生命周期中，每个用户可能会积累一些相当数量的垃圾聊天室，其中有一些用户，尽管很长一段时间没有人碰过，用户只是懒得手动离开它?
感谢您耐心阅读这篇文章!
更新于2021年12月5日如果您正在实现聊天应用程序，请参考PubNub chat用例文档了解详细信息。它具有基于PubNub平台构建的新功能和UI组件。
更新于2020年5月15日我们有一些新的文档，将以更清晰的术语解释下面的大部分内容。
以及可以应用于以下许多问题/答案的新功能:
<<ul>注意:我把上面的一些链接洒在下面的答案里。
首先，让我们来解决这个问题…
在这种情况下，让我担心的是PubNub的可伸缩性。就像我很明显，他们对PubNub后台的黑暗中发生了什么一无所知角落，我想确保应用程序是建立在一个方式，它将准备好处理一些模糊的大量的同时用户。
这…
那么在PubNub而不是我的服务器上的WebSockets是没有意义的，因为服务器无论如何都要承受所有那些打开的在线用户的负载通道和应该缩放以保持它们的庞大数量
这有点落后，因为你会使用像PubNub这样的服务来确保你的应用程序可以扩展到处理数百万用户。PubNub拥有数千个客户，扩展到数百万用户和数千亿条消息。不知道PubNub是如何做到这一点的，您就可以自由地实现应用程序的业务逻辑。
但是我想我明白你在说什么。您的印象是服务器必须参与每个用户的每个聊天室交互，但这只是部分正确。大多数情况下，您的服务器将用于身份验证、一些订阅维护(可选)，并且可能用于根据需要向一个、多个或所有最终用户发送消息(取决于您的需求)。这里有一些尝试来回答你的问题，尽管它们有点到处都是，所以我会尽我所能回答我认为你在问什么。
问题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响应)。
还有更多，但这是一个好的开始。在我们的文档页面上阅读您将使用的SDK的PubNub Access Manager。例如，你可以从JavaScript SDK Access Manager文档和教程开始。
问题3
更新文档: https://www.pubnub.com/docs/platform/channels/receive subscribe-to-channels
我相信我已经用问题1 -通道组充分地回答了这个问题。从JavaScript SDK流控制器(它提供通道组功能)文档和教程开始。
我希望我已经成功地让你在使用PubNub的非常成功的实时数据流应用程序的旅程中向前迈进了几步。如果还有其他问题，请及时回复。
*回答你的新评论:*感谢您的后续意见。你现在的要求很清楚了。
我将需要比较聊天室时间戳与个人用户最后读取的时间戳，因此，我似乎需要从后端侦听这些通道并更新用户的最后读取，或者信任到前端，并直接从用户获取时间戳
不，您不必收听服务器上的频道。是的，在客户端应用程序中，您将保留最后收到的消息的时间戳。当用户重新联机时，使用此时间戳获取客户端订阅的通道的历史记录。许多人已经成功地做到了这一点，我们将在未来几个月发布一些令人惊叹的功能，将大大简化这一点。
从后端向用户推送实时通知。如果我想随时向他们推送笔记，我是否需要订阅所有的用户频道?
您可以在任何频道上发布，而无需首先实际订阅它。因此，您的服务器可以在需要时发布到通道。
和以前一样，继续提出你需要的更多问题。
*又一个很好的后续问题。这是我的建议
…这是有意义的，不请求所有这些聊天室从数据库和加入通过pubnub所有他们，而是实现分页…用户如何能够意识到新消息可能出现在他的旧聊天室?
同样，您可以使用频道组保持订阅20K频道。你可以订阅10个频道组，每个频道组有2K个频道，但我建议将用户限制在100个或更少，因为这似乎是你应用中施加的足够限制。但是选择你想要的上限，当用户达到这个限制时，强迫他们先离开另一个聊天室，或者建议他们离开前10个最不活跃的聊天室之一，或者一些对你的应用有意义的算法。
更新文档: https://www.pubnub.com/docs/platform/channels/receive subscribe-to-channels
获取丢失消息的#需要获取完整的历史记录，但我们将在不久的将来提供改进的api以使其更简单。但如果用户在所有这些渠道上注册了推送通知，设备将能够接收这些推送消息，你的应用可以在本地保存这个计数。我们将在后台有一个"如何更新徽章计数"文章即将发表。您还可以使用它来跟踪每个频道(聊天室)的错过消息数量。
现在我只想限制用户可用的房间数量，假设是100个，并且请求并加入它们而不进行分页。
更新文档: https://www.pubnub.com/docs/platform/channels/retrieve
我们确实有客户这样做而不用担心分页。他们只检索设备订阅的100个频道的历史记录。使用后台徽章计数更新策略，您将有优势知道从哪个渠道获取时，应用程序变得活跃。文章一发表，我就把链接贴在这里。