Max*_*ari 2 javascript websocket node.js pubnub
我正在开发一个非常有趣的网络应用程序项目,它可以变得相当大,我有机会玩这个被称为PubNub应用程序的主要实时引擎的方便的东西.
因此,它是一个带有Node.js后端的Web应用程序,涉及用户之间可能存在的大量聊天室,以及当更新数据库中的某些数据时后端发送给用户的实时通知.
通常,开发时Sockets.io,我将只为每个用户订阅他唯一的数据库ID的频道,以及代表不同聊天室的chanel.
通过这种方式,我可以在后端处理聊天室和身份验证,并在DB中存储一些个人通知后,我可以轻松地将它们推送到用户ID命名的频道,因此如果用户在线 - 他得到它,如果不是 - 很好,他会看到它在下次登录时,通知已在DB中.从理论上讲,这个怪物应该在redis pub/sub的帮助下水平缩放.
在这种情况下让我担心PubNub的是可扩展性.由于我显然不了解PubNub后端的黑暗角落发生了什么,我想确保应用程序的构建方式是它将准备好处理一些模糊的大量同时用户.
我的问题是,建立这样一个系统的最佳方法是什么PubNub？
感谢您耐心阅读这一文字墙!
首先,让我们解决这个问题......
在这种情况下让我担心PubNub的是可扩展性.由于我显然不了解PubNub后端的黑暗角落发生了什么,我想确保应用程序的构建方式是它将准备好处理一些模糊的大量同时用户.
还有这个...
那么在PubNub中没有任何意义,而不是我的服务器上的websockets,因为服务器无论如何都会在所有这些打开的在线用户频道的负载下进行,并且应该缩放以保持大量的
这是一种倒退,因为您将使用像PubNub这样的服务来确保您的应用程序可以扩展以处理数百万用户.PubNub拥有数千个可扩展到数百万用户和100亿条消息的客户.不知道PubNub如何做到这一点,你可以释放你的应用程序的业务逻辑.
但我想我得到你说的话.您的印象是服务器必须参与每个用户的每个聊天室交互,但这只是部分正确.大多数情况下,您的服务器将用于身份验证,某些订阅维护(可选),并可能根据需要将消息发送给一个,多个或所有最终用户(取决于您的要求).
这里有一些尝试回答你的问题,虽然它们有点遍布各处,所以我会尽力回答我认为你在问的问题.
这个问题似乎是为了保持对频道的大量订阅及其可扩展性.
一般来说,每个最终用户都会初始化PubNub并订阅他们需要收听的频道并发布到他们发送消息所需的频道.通常情况下,他们发布的频道(我认为是你的情况下的聊天室)是他们订阅的频道,但有不同类型的用例.您可以一次订阅数千个频道(每个客户端最多20K).如果您使用WebSockets执行此操作,您将如何将其扩展到数百万用户？您将实现和操作(扩展)类似于PubNub的东西(不容易且不便宜).
现在,如果用户订阅了一堆聊天室频道,但有一些或许多是陈旧的(用户暂时没有查看或发布),您可以在服务器(或客户端)上监视一些代码用户的活动,并从那些陈旧的渠道取消订阅.这可以使用渠道组.每个最终用户都有自己的频道组,其中包含他们正在收听的所有频道.以及客户端代码或服务器代码,以及从这些最终用户的通道组添加和删除通道.
现在这个问题更清晰,更集中,并且询问身份验证(登录)以及如何确保某人是他们所说的人以及如何处理授权(他们可以做什么和不能做什么)以及控制它的位置/谁.
答案是,您控制身份验证(登录)以证明此人是他们所说的.您的登录过程会检查有效的用户名/密码,在用户记录中,您将获得该用户的访问控制列表.通过它,您可以生成一个auth-key,您可以授予对一个或多个通道的读取和/或写入权限.此授权是服务器调用的PubNub操作.auth-key被传递回客户端,客户端代码使用pub/sub键和PubNub服务器根据通道和请求的操作检查访问权限的auth-key初始化PubNub实例(订阅此通道) ,发布到该频道,等).如果auth-key没有正确的访问权限,PubNub服务器将拒绝访问(403响应).
除此之外还有更多,但这是一个良好的开端.阅读PubNub Access Manager,了解您将在我们的文档页面上使用的SDK.例如,您可以从JavaScript SDK Access Manager文档和教程开始.
我相信我已经用问题1 - 频道组充分回答了这个问题.从JavaScript SDK Stream Controller(提供Channel Group功能)文档和教程开始.
我希望我已经设法让您在使用PubNub实现非常成功的实时数据流应用程序的过程中向前迈进了一步.如果您有任何其他问题,请回复.
感谢您的后续评论.你现在要问的很清楚.
我将需要将聊天室时间戳与个人用户最后读取时间戳进行比较,因此我似乎需要从后端收听这些频道并更新用户的最后读取,或信任到前端,并获取来自用户的时间戳
不,您不必收听服务器上的频道.是的,从客户端应用程序,您将保留上次收到的消息的时间戳.当用户重新联机时,您可以使用此时间戳来获取客户订阅的频道的历史记录.许多人已经成功地完成了这项工作,我们将在未来几个月内发布一些令人惊叹的功能,这将大大简化这一过程.
从后端向用户推送实时通知.如果我想随时向他们发送笔记,是否需要订阅我的所有用户频道？
您可以在任何频道上发布,而无需先实际订阅它.所以你的服务器可以根据需要发布到频道.
和以前一样,随时提出更多问题.
...因为没有从DB请求所有这些聊天室并通过pubnub加入所有聊天室,而是实现分页...用户如何知道可能出现在他的旧聊天室中的新消息？
同样,您可以使用频道组保持订阅20K频道.您可以订阅10个频道组,每个频道组有2K频道 - 但我建议您将用户限制为100或更少,因为这似乎是在您的应用中强加的限制.但是选择你想要的任何上限,当用户达到这个限制时,强迫他们先离开另一个聊天室,或者建议他们离开前10个最不活跃的,或者某个对你的应用有意义的算法.
获取错过的消息数确实需要完整的历史记录提取,但我们将提供改进的API,以便在不久的将来更简单.但是,如果用户在所有这些频道上注册了推送通知,则设备将能够接收这些推送消息,并且您的应用可以在本地保留该数量.我们将很快发布"如何更新背景中的徽章数"文章.您还可以使用它来跟踪每个频道(聊天室)错过的消息数量.
现在我只想限制用户可用的房间数量,让我们说一百个并请求并加入他们而不加入分页.
我们确实有客户这样做而不用担心分页.他们只是在设备订阅的100个频道上检索历史记录.使用背景徽章计数更新程序技术,您将有一个优势,即知道应用程序变为活动状态时要从哪些渠道获取.发布后,我会在这里发布该文章的链接.