1. 概述

本文介绍IM系统常见问题，以及术语介绍。

2. 常见问题

2.1. 网络闪断或SM掉线的客户端处理流程

Client优先遍历本地可用SM列表，尝试连接SM服务。

如果全部连接失败，则通过Portal访问Account服务，获取可用SM列表，然后再重连SM。

im-relogin.png

2.2. SM横向扩展

• SM启动后，注册到Account服务，包含SM地址、地理位置（Region）等
• Account服务，在用户登录成功后，基于SM路由策略，返回给用户可用SM列表
• 用户获取到可用SM列表后，按顺序登录到SM服务，也可以根据Traceroute结果确定最近的SM服务，建立全双工通道

SM路由策略，可基于办公地点就近、团队默认SM等因素判定

2.3. 数据库的作用

• 关系型数据库，只起元数据持久化和检索的作用，不应过多依赖数据库的特性，例如事务、触发器、存储过程或函数等
• 内存数据库，记录运行时数据，例如在线用户列表、每个用户最近10条消息（且最近10分钟）、SM地址列表等
• 时序数据库，例如InfluxDB，用于存储IM Message
• （暂不考虑）全文检索数据库，例如BleveSearch，可用于存储IM Message，实现其存储与检索

2.4. IM Online User ID

采用{UserId}@{Region-ID}/{Device}的方式，可唯一标识每一个在线IM用户，以及其连接的SM服务，便于更快速地推送消息。

其中，三个字段取值如下：

• UserId，是IM用户的唯一ID，采用32位UUID
• Region-ID，部署服务时人工命名，可以是城市全拼，例如cn-hangzhou、cn-zhengzhou、jp-tokyo
• Device，枚举类型，由客户端确定，取值范围：desktop-macos、desktop-win、desktop-linux、mobile-android、mobile-ios等

SM-ID，由SM启动时生成，ID格式{RegionID}-{UUID}，注册到Account服务，记录其地理位置

2.5. IM消息入库

原计划由每个Region的Recorder，在收到send包时即分批入库。

经过讨论，为了减少数据库操作，降低数据库压力，暂定在收到receive-ack时入库，具体有以下几种情况：

• SM收到Client的receive-ack，则单独发包给Recorder，通知入库，且该消息状态为已送达
• SM没有收到Client的receive-ack，或者client刚好下线，则单独发包给Recorder，通知入库，且该消息状态为未送达（User会在下次登录后，通过获取历史消息得到）
• Broker在路由单聊或群聊消息时，如果全局路由表不存在对应的receiver或groupid，则通知本区域的Recorder入库，且该消息状态为未送达
• Recorder需要监听死信队列，超过10分钟以上的receive消息，则入库，且标记为未送达

3. IM术语介绍

im-terms.png

4. 总结

以上是IM架构设计，在此基础上，将进一步完成IM通信协议设计和IM数据库设计。