Powered by AppSignal & Oban Pro
Would you like to see your link here? Contact us

IM

docs/im.livemd

IM

功能列表

需求平台的需求抽象

  • 实时在线消息的投递

    • 投递质量

      • QOS 0 最多投递一次的场景,适合状态数据等具有时效性的场景

      • QOS 1 最少投递一次的场景,适合可靠消息投递的场景

    • 投递时序,关系性的消息有序性,例如单个会话的消息保证其相对有序性

  • 离线消息、完整消息数据同步

    • 能够在需要的时候完成数据的同步,能够明确感知什么位置缺失数据

    • 同步可能存在不同的场景

      • 从最旧的消息位置进行同步

      • 从最新的消息位置进行同步

  • 消息的操作

    • 单聊的消息已读以及未读

    • 群聊消息的已读未读

    • 群聊消息是否关联有thread数据

    • 消息是否有pin操作

    • 消息是否有reaction操作

  • 事件的通知

    • 群组加入退出等动作的同步需要靠离线消息的驱动

    • 会话的操作

    • 漫游消息的操作

业务需求

关系

1对1关系

  • 白名单
  • 黑名单

多人关系

  • 持久关系(群组)
  • 非持久关系(聊天室、直播间)
  • 两种特性是否要互斥?需要慢慢的回归到根据不同的操作不同的动作

消息投递

扩散方式
  • 1对1消息投递
  • 多人关系的消息投递
  • 多人关系的定向消息投递
投递质量
  • QoS0 仅仅对于在线的进行投递,At Most Once
  • QoS1 保障消息投递终端, At Least Once

元数据维护

  • 个人元数据

    • 同步自己的元数据
    • 同步他人的元数据
      • 好友的元数据
      • 群成员的元数据
  • 群(多人关系)的元数据

      - 消息元数据
          - 已读、送达状态
          - reaction、pin等消息属性元数据

场景诉求

客户端离线消息的问题

IM首屏消息显示

  • 能够获取到”最新”的会话交流列表,对标当前的会话列表系统
  • 能够获取到”需要”的消息,对比当前的漫游系统
  • 时机可以是登录后的首屏,也可以是后续按需进行同步的时机

消息操作

消息级别的操作

  • 消息的操作可以通过实时消息系统进行投递?

  • 消息的最终状态如何进行终端同步?

    • 本地没有的消息?

      服务端进行信息的补齐

    • 本地已经存在的消息?

      何时,什么时机进行同步。。。

元数据操作

元数据更新

账号级别的元数据

同步自己的元数据
  • 用户属性(登录账号)
  • 会话列表

此类可以通过登录的时候进行数据更新同步来做到。

  • 全量数据同步

    通过更新时间(version)校验,识别是否有数据变更,如果有变更则进行从服务端拉取全量最新的数据

  • 增量数据同步

    通过更新时间(version),识别是否有数据变更,如果有变更则同步变更之后的数据。(明显结构要复杂,需要针对具体的业务确定是否有进行增量同步的必要,比如数据规模,全量同步的时间,增量数据实现的复杂性等)

同步他人的数据
  • 用户属性(非登录账号)

此类不宜和当前登录账号进行绑定,例如,和你有个交流的账号有10000人,采用什么方式进行同步,什么时机进行同步。

三方实例的数据

  • 群属性,群公告

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

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

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

扩散系数比较的场景

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

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

实时消息

实时消息投递

  • 可靠性

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

  • 实时性

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

  • 有序性

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

  • 可控性

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