即时通讯-4-写扩散下的同步协议方案
1. 背景信息
上篇提到了, IM协议层是主要解决会话和消息的同步, 在实现上, 以推模式为主, 拉模式为辅.
本文Agenda:
- (How)如何同步
- (How)如何设计同步位点
- (How)如何设计 Gap过大(SyncGapOverflow) 机制
- (How)如何设计Ack机制
- (How)同步协议如何支持上层
- 总结
提示: 本系列文章不会单纯的给出结论, 希望能够分享的是"如何分析, 如何得出的结论"的思路.
2. 同步协议如何设计
什么是同步协议
同步是通过将server的位置同步到client的位置, 最终实现了消息的同步.
大前提条件
- 知道client 在哪里
- 知道server 在哪里
小前提条件
3. client可以同步到server的位置
4. server在此流程中, 将消息内容带给端上
结论
实现消息内容的同步
示例
用户A发送了10,000条消息给B, 并且B仅有A一个会话. server的同步队列, 仅能记录单人的1000个同步事件, 在不同的场景下(场景为何如此划分, 请参考上篇文章)的处理.
scene: 首次登录
scene: 用户在线同步/短暂离线后再次在线同步
scene: 用户长期不在线再次在线后同步
示例场景总结
总共有四个步骤
- client告诉server, client的同步位点
- server计算client的同步位点与server的gap
- server推送之间的gap与最新的同步点
- 如果server推送之间的gap过大, server会告知client需要自己处理, client标记gap, 拉取最新的会话信息
此四个步骤便是同步协议的核心流程.
如果加上建联的过程. 便是完整的同步协议方案.
如何同步
完整的同步协议方案, 整体可以认为分为四个阶段.
- 通讯层建连
- 离线消息同步
- 在线等待指令
- 在线消息同步
即离线消息同步, 是保证了client与server的同步位点是一样的. 这也是微信的WeiSync的设计思路的前提假设: client与server是状态同步的.
而细化处理的逻辑如下
如图所示, 可以得出以下的结论
- 通讯层建联后, 协议层的首个通讯是确定的, 是协议层建连同步.
- 整个同步协议的核心要素有两个: 同步位点 以及 是否有gap.
- Ack机制
- 同步协议中的目的是同步位点同步, 以及消息同步. 那么消息同步是否一定要归属到同步协议中?
因而
- 同步位点以及 gap过大(SyncGapOverflow)的设计 ,成为了解决同步协议端到端方案的核心问题.
- Ack机制如何设计?
- 消息同步是否一定要归属到同步协议中, 是否可以拆出来?
如何设计同步位点
什么是同步位点
同步位点, 是server和client用于判定server的同步队列, 当前已经同步到的位置信息.以及用于server和client之间判断还有那些信息未同步的判断依据.
如何设计
版本号?
版本号的方式, client是OK的. 但是对于server而言, 如果server需要清空对应的队列时, 便需要记录已经清空的最新的版本号. 这样在新消息来临时, 才能比较准确的记录.
时间戳?
时间戳的方式, client是OK的. 如果是比较活跃的群聊, 单位时间内的消息暴涨, 采用毫秒的时间戳, 也是可能会有重复的记录. 建议采用纳秒.
其他方式?
如生成单独的uuid, 也是可以的. 不过对于server而言, 由于是字符串匹配, 检测client已经同步到的位置, 耗时会比较久.
因而采用纳秒级别的时间戳是一种比较好的解决方式.
结论
采取纳秒的方式作为同步位点, 另外, 为了做方便做后续的协议升级, 除了同步位点外, 还需要增加一个同步协议版本号的元素.
即同步协议版本号 + 纳秒的同步位点. 作为同步协议的同步位点解决方案
谁来持有同步位点?
client和server均需要持有同步位点.
server记录client的设备维度的同步位点 + 天然持有的同步队列的同步位点信息.
client记录当前设备上账号的同步位点信息.
如何设计 Gap过大(SyncGapOverflow) 机制
什么是Gap过大(SyncGapOverflow)
ps: 英文名字是我定义出来的.
英文名便比较好理解. Sync Gap Overflow. 同步gap时, 内容过多, server拒绝主动同步. 即告知client, 需要client主动拉取. 从推模式切成了拉模式.
如何做SyncGapOverflow
gap一般的处理, 也是一个端到端的问题.
出现SyncGapOverflow, 是client的同步位点, 已经不在同步队列中.
而不在同步队列中, client的位点太老可以导致, 也可能是server对同步队列做了定期清理机制导致.
因而一般的SyncGapOverflow的触发原因有两类
- client侧的设备首次登录或者超过了长期未登录
- server侧的清理机制导致
如何设计Ack机制
什么是ACK机制
ACK机制, 即ACK消息. “回复已经收到数据”. 而在同步协议的场景下, 是指 client 确认收到了sever的同步数据, 给到server的一个确认消息.
目的:
1. server确认同步消息消费了, 即保证消息的可靠性投递和消费
2. server根据此确认消息, 标记client的当前同步位点
如何设计Ack机制
以用户短暂离线再次在线为例.如图所示.
当用户离线后时, server记录的最新同步位点的index位于10,000, 而client的同步位点的index位于9,900.
用户再次登录时,
- 通讯层建联
- client将index为9,900的同步位点上传给到server.
- server处理9,900的同步位点, 发现位于同步队列中, 并且未达到SyncGapOverflow的条件. 于是批次的下发同步的内容. 如. 50个sync消息作为一个业务包下发.
- client在收到了9,901 ~ 9950的同步位点数据后, 进行处理
- 对于处理的结果需要Ack server. 而Ack server有两种结果. SUC和FAIL.
- 对于SUC的case. server更新client 同步位点到index为9,950.
- 对于FAIL的case, server认为client处理失败. 进行重试机制的处理, 如 等 3s 在进行重试.
- 如果重试的次数, 超过了三次. server告知client sync同步失败, client进行兜底的处理. 如端侧reset, 重新初始化.
Ack的逻辑, 可以直接参考TCP的Ack机制.
消息同步是否属于同步协议?
一般来讲, 消息同步是附属于同步协议的, 但是严格来讲, 同步协议与消息同步是可以做分割的
同步协议仅推送最新的同步位点信息,同步后, client 回复ack. 而client每次在收到同步位点信息时, 跟本地做比对, 然后主动拉取中间的消息内容,
即同步协议仅推送server最新的变更通知, client收到通知后, 回复ack. 主动拉取. 最大程度的使用拉模式. 依然以用户短暂离线再次在线为例.如图所示.
处理流程
而这种Ack机制, 也确实保证了是收到了消息通知, 但是没有保证client的消息数据正常处理了. 选择此种方案需要慎重.
3. 同步协议如何支持上层
同步协议的上层是什么
同步协议的上层, 从IM的角度来看,是包含了会话和消息, 不过如果从IM整体的系统来看, 可能还有User的Profile等等. 如果IM的系统还有直播等内容, 那么同步协议正常来讲, 与直播也有是有关系的.
因而, 从一般的设计来看, 包含了
- 通用的IM的内容: 会话 + 消息
- IM系统的内容: User的Profile
- 其他业务的内容: 直播等
同步协议的上层有那些行为
会话和消息的行为
会话存在新增会话, 删除会话, 会话属性变更等等.
消息存在新增消息, 撤回消息, 删除消息, 消息的属性变更等等.
UserProfile的行为
新增了联系人, 联系人的Profile有变更,如昵称等等.
虽然userProfile有如此的变更, 但是对于业务而言, UserProfile的变更, 是否需要一定对接到同步协议中, 有待商定. 可以参考下微信的feature. 尤其是在群聊中, 当点击一个群中user的头像时, 群聊时头像是V1, 而点进去后, 看到头像变了, 是V2, 再返回群聊时, 头像变为了V2. 因而UserProfile的行为不一定与同步协议强绑定.
其他业务的行为
其他业务可能需要进行事件通知, 如直播中的评论的新增等等(可以通过拉模式, 也可以通过推模式).
如何支持上层
针对上层的这么多行为, 如何进行支持呢? 按照同类合并即可.
先按照业务划分, 业务再进行细化.
业务划分为IM, 直播等
IM的事件划分为会话事件以及消息事件.
会话事件可拆分 新增会话, 会话删除, 会话属性变更等具体事件.
消息事件可拆分 新消息, 消息撤回, 消息删除, 消息属性变更等具体事件.
因而整体的业务逻辑可以按照如下结构划分.
即按照 biz_type, sub_biz_type, event的三层业务结构支持上层业务
3. 结论
本文通过同步协议的各个场景细化, 比较完整的介绍了
1. 同步协议的方案.
2. 在设计同步协议中, 几个比较关键的元素的设计, 同步位点, Gap过大机制, Ack机制.
3. 同步协议通过biz_type, sub_biz_type, 以及event的三层业务结构支持上层业务