IM专题：分层架构IM系统（6）— Router能力分析

在分层架构 IM 系统中，路由层 Router 的核心职责是作为中央存储记录在线用户的连接状态，见下图。

Router 其本质是一个巨大的 Map<uid, EntryIp>，其 key 是表示客户端用户的 uid，其 value 是客户端连接的 Entry 节点；要判断一个用户是否在线，该用户客户端连接到了哪一个 Entry 节点，Router 是门儿清的。

明确了 Router 的核心职责后，那么Router 需要提供哪些能力呢？

先分析一下，在分层架构 IM 系统中 Entry、Router 和 Logic 三者之间的调用关系，见下图。

Entry 通过 RPC 调用 Logic，实现业务逻辑的处理；
Logic 通过 RPC 调用 Entry，实现消息向用户侧的推送；
Logic 通过 RPC 调用 Router，维护在线用户信息；
Router 回调 Logic，实现心跳失活用户的及时通知。

所以，Router 需要提供两方面能力：业务接口和通知回调。

一、业务接口

Router 的核心数据结构是一个 Map，其 key 是唯一标识用户的 uid，而其 value 为了方便功能上扩展，可以落地为一个结构体对象，代码如下：

Map<uid, userInfo>
userInfo {
  int userStat；//用户状态 0—离线 1—在线 2—......
  long heartbeat；//最近一次心跳时间
  int deviceType；//设备类型 0—安卓 1—IOS 2—......
  string deviceToken；//用户移动设备token，用于手机推送
  string entryAddr;  //Entry节点地址， ip:port
}

Router 基于该核心数据结构，向 Logic 提供四个业务接口；这四个业务接口，纯内存操作，而且逻辑简单。

用户登录Logic 校验完成用户登录请求后，构建 userInfo 对象，写入到 Router 中。
用户登出用户登出时，Logic 直接从 Router 中根据用户 uid 删除记录，或将 userStat 字段置为 0。
设置用户信息在多种业务场景下，Logic 会调用该接口：客户端发送心跳请求时，修改 heartbeat 字段值；客户端在线状态下，使用了新的设备进行登录，修改 deviceType 和 deviceToken 字段值，如果连接的是新的 Entry 节点，修改 entryAddr 字段值。
查询用户信息Logic 需要向用户主动推送消息时，在 Router 中查询用户是否在线，如果在线，则获取用户客户端连接的 Entry 节点地址。

二、通知回调

Router 中保存了所有的在线用户；而 Router 不仅仅只是一个内存数据库，它能根据客户端心跳数据判断出失活用户，然后通过回调方式及时通知 Logic 进行处理；Logic 处理的方式是通知相关 Entry 节点及时关闭与客户端之间的连接，释放资源。

我们在前面的文章 IM专题：分层架构IM系统（4）— Entry心跳算法中分析过，Entry 也会根据客户端心跳数据识别出失活用户，这和 Router 的识别失活用户工作并不冗余，而是相辅相成。

Router 的核心数据结构是一个很大的 Map。通常我们会通过定时扫描的方式，扫描出很长时间未发送心跳包的客户端；在扫描的时候，为了安全，会给这个很大的 Map 加上一把大锁，这会非常影响 Router 的服务性能；如何进行优化呢？见下图