您现在的位置:主页 > 手机最快现场开奖直播-视频 > 正文内容

ore websocket 即时通讯组件---ImCore

发布日期:2019-08-14 16:44   来源:未知   阅读:
 

  ImCore 利用 webSocket 协议实现简易、高性能、集群即时通讯组件,支持点对点通讯、群聊通讯、上线下线事件消息等众多实用性功能。

  如果浏览器使用 webSocket ,iOS 使用其他协议,协议不一致的后果很严重(难维护)。

  诸如此类业务判断会很复杂,如果使用imServer做业务协议,它是不是会变成巨无霸难以维护?

  业务和推送分离的设计,即 imServer 只负责推送工作,webApi 负责业务。

  获取历史消息:客户端请求业务方(webApi)接口,返回json(历史消息)。

  背后采用 redis 轻量级的订阅发布功能,实现消息缓冲发送,方案必备之一,后期可更换为其他技术。比如 webApi 业务发需要通知1000个人,若不用消息缓冲,会对 webApi 应用程序整体将造成性能损耗。

  还有使用 redis 存储一些数据,如在线 clientId,频道信息。

  还有使用 redis 存储一些数据,如在线 clientId,频道信息。

  单个 imServer 实例支持多少个客户端连接,两千个没问题?如果在线万人,怎么办???

  每个 imServer 管理着对应的终端连接,当接收到 redis 订阅消息后,向对应的终端连接推送数据。

  IM 系统比较常用的有上线、下线,在 imServer 层才能准确捕捉事件,但业务代码不合适在这上面编写了。

  此时采用 redis 发布订阅技术,将上线、下线等事件向指定频道发布,业务方(webApi) 通过 ImHelper.EventBus 方法进行订阅捕捉。

  因为他是双工通讯的设计,用oke 发送命令给服务端处理业务,其他就和 ajax 差不多,用来代替 ajax 减少 http 请求数量比较看好。

  但是过多使用 hub,signalr 服务端会被业务入侵严重,业务变化频繁后不得不重新发布版本,每次部署所有终端都会断开连接,遇到5分钟发一次业务补丁的时候,类似离线和上线提示好友的功能就无法实现。

  ImCore 的设计是业务和推送分离,即 imServer 永不更新重启,业务全部在 webApi 上编写,终端连接的是 imServer 就不会频繁重启的问题。返回搜狐,查看更多