有个问题点，想请教下：

在4.3中，提到钉钉的消息存储使用的是消息读扩散+写扩散的方式，群内普通消息写到conversation_message这张表，P和NP消息写到message_inbox表。而且还展示了拉消息的逻辑，第七章7.2.2也作证了这一点。

但是在第六章中，讲数据的多终端同步和离线同步，有点类似于漫游的功能，拉的消息会持久化一份到Event Store表，然后PTS记录每个端拉取的消息seq，这里怎么看怎么像消息的写扩散。同样也展示了对应拉消息的逻辑


那么问题来了： 只看普通消息，前面说用读扩散，后面同步的时候又是按人维度以写扩散的方式单独存储一份，这个岂不是有矛盾？难道同步服务和在线消息推送是解耦的？多端在线直接推，并抄一份到同步服务，同步服务做持久化，同一用户离线的终端上线后再到同步服务个人消息存储的队列来拉取，这样在消息推送可以保证实时，拉消息逻辑又可以变得简单，解释起来貌似要合理一点，但是文章中没有体现出来。

麻烦大佬们帮忙看看这个，怎么看待这个问题

有个问题点，想请教下。

在4.3中，提到钉钉的消息存储使用的是消息读扩散+写扩散的方式，群内普通消息写到conversation_message这张表，P和NP消息写到message_inbox表。而且还展示了拉消息的逻辑。7.2.2也作证了这一点

但是在第六章中，讲数据的多终端同步和离线同步，有点类似于漫游的功能，拉的消息会持久化一份到Event Store表，然后PTS记录每个端拉取的消息seq，这里怎么看怎么像消息的写扩散。同样也展示了对应拉消息的逻辑

那么问题来了： 只看普通消息，前面说用读扩散，后面同步的时候又是按人维度以写扩散的方式单独存储一份，这个岂不是有矛盾？难道同步服务和在线消息推送是解耦的？多端在线直接推，并抄一份到同步服务，同步服务做持久化，同一用户离线的终端上线后再到同步服务个人消息存储的队列来拉取，这样在消息推送可以保证实时，拉消息逻辑又可以变得简单，解释起来貌似要合理一点，但是文章中没有体现出来。

看看各位大佬对这个点怎么看

引用：JackJiang 发表于 2022-08-22 22:19
其实说到扩散写和扩散写，主要讨论的是群聊，群聊肯定会有一份全量消息存储。而针对每个端的记录，应该不 ...

感谢站主热心解答，群消息存一份肯定是必须的，人维度存储索引确实要轻量很多，读起来效率也高，这样理解也合理很多。当时看的时候觉得他这样说有点奇怪，每个人再写一份挺浪费钱。。。但是想想，这样这样客户端做逻辑会方便很多，客户端也会流畅很多，毕竟阿里，有钱（手动狗头）。

学习一下大厂的架构，回头自己实现的时候有个参考的模型，哈哈哈。

再次感谢站主。