IM
功能列表
需求平台的需求抽象
-
实时在线消息的投递
-
投递质量
-
QOS 0 最多投递一次的场景,适合状态数据等具有时效性的场景
-
QOS 1 最少投递一次的场景,适合可靠消息投递的场景
-
-
投递时序,关系性的消息有序性,例如单个会话的消息保证其相对有序性
-
-
离线消息、完整消息数据同步
-
能够在需要的时候完成数据的同步,能够明确感知什么位置缺失数据
-
同步可能存在不同的场景
-
从最旧的消息位置进行同步
-
从最新的消息位置进行同步
-
-
-
消息的操作
-
单聊的消息已读以及未读
-
群聊消息的已读未读
-
群聊消息是否关联有thread数据
-
消息是否有pin操作
-
消息是否有reaction操作
-
-
事件的通知
-
群组加入退出等动作的同步需要靠离线消息的驱动
-
会话的操作
-
漫游消息的操作
-
业务需求
关系
1对1关系
- 白名单
- 黑名单
多人关系
- 持久关系(群组)
- 非持久关系(聊天室、直播间)
- 两种特性是否要互斥?需要慢慢的回归到根据不同的操作不同的动作
消息投递
扩散方式
- 1对1消息投递
- 多人关系的消息投递
- 多人关系的定向消息投递
投递质量
- QoS0 仅仅对于在线的进行投递,At Most Once
- QoS1 保障消息投递终端, At Least Once
元数据维护
-
个人元数据
- 同步自己的元数据
-
同步他人的元数据
- 好友的元数据
- 群成员的元数据
-
群(多人关系)的元数据
- 消息元数据 - 已读、送达状态 - reaction、pin等消息属性元数据
场景诉求
客户端离线消息的问题
- 能够获取到”最新”的会话交流列表,对标当前的会话列表系统
- 能够获取到”需要”的消息,对比当前的漫游系统
- 时机可以是登录后的首屏,也可以是后续按需进行同步的时机
消息操作
-
消息的操作可以通过实时消息系统进行投递?
-
消息的最终状态如何进行终端同步?
-
本地没有的消息?
服务端进行信息的补齐
-
本地已经存在的消息?
何时,什么时机进行同步
。。。
-
元数据操作
账号级别的元数据
同步自己的元数据
- 用户属性(登录账号)
- 会话列表
此类可以通过登录的时候进行数据更新同步来做到。
-
全量数据同步
通过更新时间(version)校验,识别是否有数据变更,如果有变更则进行从服务端拉取全量最新的数据
-
增量数据同步
通过更新时间(version),识别是否有数据变更,如果有变更则同步变更之后的数据。(明显结构要复杂,需要针对具体的业务确定是否有进行增量同步的必要,比如数据规模,全量同步的时间,增量数据实现的复杂性等)
同步他人的数据
- 用户属性(非登录账号)
此类不宜和当前登录账号进行绑定,例如,和你有个交流的账号有10000人,采用什么方式进行同步,什么时机进行同步。
三方实例的数据
-
群属性,群公告
此类数据属于有一定关系的数据,但是又非是用户级别可以聚合的,
例如,不可能群主更新群组公告,给所有的群组成员的状态变更。
目前可能得解决方案是按需进行比较,同上面的同步他人账号数据的逻辑。
扩散系数比较的场景
- 群组成员列表
- 群组成员的属性
仿照微信按需更新,列表方式的获取仅仅获取本地的数据,仅仅在获取详情的时候,有时间维度的进行更新。
实时消息
-
可靠性
消息能够不丢失的投递给目标方。
-
实时性
消息能够在规定的时间内送达到目标方。
-
有序性
消息能够按照预期的顺序投递到目标方。
-
可控性
能够通过可控的方式获取消息,客户端可以选择性的接收特定的消息。