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人，采用什么方式进行同步，什么时机进行同步。

三方实例的数据

• 群属性，群公告

  此类数据属于有一定关系的数据，但是又非是用户级别可以聚合的，

  例如，不可能群主更新群组公告，给所有的群组成员的状态变更。

  目前可能得解决方案是按需进行比较，同上面的同步他人账号数据的逻辑。

扩散系数比较的场景

• 群组成员列表
• 群组成员的属性

仿照微信按需更新，列表方式的获取仅仅获取本地的数据，仅仅在获取详情的时候，有时间维度的进行更新。

实时消息

• 可靠性

  消息能够不丢失的投递给目标方。

• 实时性

  消息能够在规定的时间内送达到目标方。

• 有序性

  消息能够按照预期的顺序投递到目标方。

• 可控性

  能够通过可控的方式获取消息，客户端可以选择性的接收特定的消息。