引用：Frank 发表于 2023-03-14 08:23
拉消息肯定有个应用服务来聚合下。

这就叫专业

引用：JackJiang 发表于 2022-08-18 21:59
这篇文章是目前为止，有关钉钉的最有价值技术干货，有兴趣的，一定读一读！

引用：JackJiang 发表于 2022-08-23 10:34
嗯嗯，关键是要动手实践，光看看的话，很快就忘记了

确实要动手;反推他们的实现,然后画成完整的图逻辑,自圆其说也是可以的.

一说: 当消息进入Receiver之后，会先查询此cid:1001所在的单元，发现是Unit A，路由框架将请求转到A单元，消息在A单元持久化并通过A单元的同步协议，将数据推送到客户端
二说: Processor 消费到 IM 发送事件首先做按接收者的地域分布（DTIM 支持跨域部署， Geography，Geo）做消息事件分流
上面说的是会话路由,下面说的是消息同步分流? @JackJiang 请教站长

引用：yqfclid 发表于 2022-08-31 16:58
DTIM 采用了会话维度划分：因为人和会话都是元数据，数据规模有限，消息数据近乎无限，消息归属于会话，会 ...

这里应该是,把消息推送到 用户所在单元同步服务;同步服务推送时,根据是否在线来确定.

引用：Frank 发表于 2023-03-14 08:21
这种设计明显是后期补的漏洞，完全推的思路，后期发现问题了，再补充。我们早期也是推，结果经常把客户端 ...

这里的rebase流程确实没有说清楚，只说客户端pts和服务端pts相差太大，就返回客户端rebase，然后客户端来拉最新的消息同时更新pts，由于pts是用户维度的，那么客户端来拉最新消息是怎么拉的？从文中描述看起来是像会话的最新消息，也就是说rebase的时候，需要用户把所有会话的最新消息都拉回去？如果是这样存在一个问题，用户的所有会话难道是同步入库的？如果是异步入库那么用户的会话列表就会有延迟，进而导致rebase流程也会有问题。

不清楚钉钉的rebase细节是啥