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数据库设计。
