来自后端的实时用户通知,包括PubNub,可扩展性和超过9000个聊天室

时间:2015-11-07 19:56:16

标签: javascript node.js websocket pubnub

我正在开发一个相当大的非常有趣的网络应用程序项目,我有机会使用这个名为PubNub的方便事物作为应用程序的主要实时引擎。< / p>

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

通常,使用Sockets.io进行开发,我只会将每个用户订阅到其唯一数据库ID的频道,也可以订阅代表不同聊天室的chanel。

这样我可以在后端处理聊天室和身份验证,在DB中存储一些个人通知后我可以轻松地将它们推送到用户ID命名的频道,所以如果用户在线 - 他得到它,如果没有 - 很好,他将在下次登录时看到它,通知已在DB中。理论上,这个monstrocity应该在redis pub / sub的帮助下水平缩放。

在这种情况下让我担心PubNub的是可扩展性。由于我显然不了解PubNub后端黑暗角落的情况,我想确保应用程序的构建方式能够处理一些模糊不清的大量并发用户。< / p>

我的问题是,使用PubNub构建此类系统的最佳方法是什么?

  1. 我是否正确,假设需要向特定用户推送通知,订阅此用户的pubnub,推送注释和取消订阅会更好。好像我会保持所有在线用户频道开放 - 那么PubNub没有任何意义,而不是我的服务器上的websockets,因为服务器无论如何都会在所有这些打开的在线用户频道的负载下进行,并且应该缩放以保持巨大的数量。
  2. 用户授权怎么办?如果不涉及我的后端,我怎么能确定用户发布一些消息将无法伪造他的个性,并且会像他在应用程序内部进行身份验证一样繁琐?
  3. 通常(并通过PubNub)解决每个用户大量聊天的最佳做法是什么?正如在应用程序生命周期中所说的那样,每个用户可能会累积一些体积庞大的垃圾聊天室,其中有一些用户,尽管很长时间没有被任何人触摸过,用户只是懒得手动离开它? / LI>

    感谢您耐心阅读这一文字墙!

1 个答案:

答案 0 :(得分:5)

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

  

在这种情况下让我担心PubNub的是可扩展性。就像我一样   显然对PubNub后端黑暗中发生的事情一无所知   角落,我想确保应用程序以它的方式构建   准备好处理一些不起眼的巨大数量   同时用户。

这......

  

那么PubNub中没有任何意义,而不是我的服务器上的websockets,   因为服务器无论如何都会在所有那些打开的在线用户的负载下   渠道,应该缩放,只是为了维持它们的大量数量

这是一种倒退,因为您将使用像PubNub这样的服务来确保您的应用程序可以扩展以处理数百万用户。 PubNub拥有数千个可扩展到数百万用户和100亿条消息的客户。不知道PubNub如何做到这一点可以让你自由地实现你的应用程序的商业逻辑。

但我想我得到你说的话。您的印象是服务器必须参与每个用户的每个聊天室交互,但这只是部分正确。大多数情况下,您的服务器将用于身份验证,某些订阅维护(可选),并可能根据需要将消息发送给一个,多个或所有最终用户(取决于您的要求)。

这里有一些尝试回答你的问题,虽然它们有点遍布各处,所以我会尽力回答我认为你在问的问题。

问题1

这个问题似乎是为了保持对频道的大量订阅及其可扩展性。

一般来说,每个最终用户都会初始化PubNub并订阅他们需要收听的频道并发布到他们发送消息所需的频道。通常情况下,他们发布的频道(我认为是你的情况下的聊天室)是他们订阅的频道,但有不同类型的用例。您可以一次订阅数千个频道(每个客户端最多20K)。如果您使用WebSockets执行此操作,您将如何将其扩展到数百万用户?你将实现和操作(扩展)类似于PubNub的东西(不容易且不便宜)。

现在,如果用户订阅了一堆聊天室频道,但有些或许多是陈旧的(用户暂时没有查看或发布),您可以在服务器上安装一些代码(或者客户端)监视用户的活动并从那些陈旧的渠道中取消订阅。这可以使用channels groups。每个最终用户都有自己的频道组,其中包含他们正在收听的所有频道。以及客户端代码或服务器代码以及向这些最终用户添加和删除频道的信息。频道组。

问题2

现在这个问题更清晰,更集中,并且询问身份验证(登录)以及如何确保某人是他们所说的人以及如何处理授权(他们可以做什么和不能做什么)和在哪里/谁控制这个。

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

除此之外还有更多,但这是一个好的开始。阅读PubNub Access Manager,了解您将在我们的文档页面上使用的SDK。例如,您可以从JavaScript SDK Access Manager docs and tutorials开始。

问题3

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

我希望我已经设法让您在使用PubNub实现非常成功的实时数据流应用程序的过程中向前迈进了一步。如果您有任何其他问题,请回复。

<小时/> 您的新评论的答案:

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

  

我需要将聊天室时间戳与个人用户进行比较   最后读取时间戳,这似乎我需要听   来自后端的那些频道,并更新用户的最后读取或信任   在前端,并直接从用户获取时间戳

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

  

从后端向用户推送实时通知。我需要吗?   如果我想向他们推送笔记,则订阅我的所有用户频道   随时

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

和以前一样,根据需要继续提出更多问题。

<小时/> 再次提出了很好的跟进问题。这是我的建议

  

...因为没有从DB请求所有这些聊天室   通过pubnub加入所有这些,而是​​实现分页...如何   用户可以知道可能出现在他的旧聊天中的新消息   间?

同样,您可以使用频道组保持订阅20K频道。您可以订阅10个频道组,每个频道组有2K频道 - 但我建议您将用户限制为100或更少,因为这似乎是在您的应用中施加的足够限制。但是选择你想要的任何上限,当用户达到这个限制时,强迫他们先离开另一个聊天室,或者建议他们离开前10个最不活跃的,或者某个对你的应用有意义的算法。

获取错过的消息确实需要完整的历史记录提取,但我们将提供改进的API,以便在不久的将来更简单。但是,如果用户在所有这些频道上注册了推送通知,则设备将能够接收这些推送消息,并且您的应用可以在本地保留该数量。我们将有一个&#34;如何更新背景中的徽章数量&#34;文章即将发表。您还可以使用它来跟踪每个频道(聊天室)错过的消息数量。

  

目前我只想限制用户可用的房间数量   让我们说一百个请求并加入他们而不加入分页。

我们确实有客户这样做而不用担心分页。他们只是在设备订阅的100个频道上检索历史记录。使用背景徽章计数更新程序技术,您将有一个优势,即知道应用程序变为活动状态时要从哪些渠道获取。我将在这里发布该文章的链接。