求教关于IM群聊消息中只存储一份的逻辑有些疑问

原帖 《IM群聊消息究竟是存1份(即扩散读)还是存多份(即扩散写)？》
终极方案是每条消息只存一份，群内用户每个人都只存一个last_ack_msgid 来维护? 对这个last_ack_msgid 不太理解，群消息msgid 是按小到大排序的，比如5条群消息，msgid 为 1 2 3 4 5，用户正常收到了1和5 回复了ack，last_ack_msgid最后修改为5？ 此时 2 3 4 由于其他原因丢了，用户无法收到，离线消息获取也是从5 开始，此时 2 3 4去哪了， 怎么保证消息不丢？

你说的这篇文章里，其实是你没有讨论你说的这个问题的，不然很复杂，也很难讲清文章里的内容，具体你可以再深入读一读以下几篇：
《IM消息送达保证机制实现(一)：保证在线实时消息的可靠投递》
《IM消息送达保证机制实现(二)：保证离线消息的可靠投递》
《如何保证IM实时消息的“时序性”与“一致性”？》
《一个低成本确保IM消息时序的方法探讨》
《IM单聊和群聊中的在线状态同步应该用“推”还是“拉”？》
《IM群聊消息如此复杂，如何保证不丢不重？》

引用：JackJiang 发表于 2019-01-21 10:18
你说的这篇文章里，其实是你没有讨论你说的这个问题的，不然很复杂，也很难讲清文章里的内容，具体你可以再 ...

非常感谢你的回答，想再问下：
1 为了解决数据冗余，群里用户只存最后一条last_ack_msgid，其他中间过程中last_ack_msgid之前的消息丢失情况，有什么方式保证吗？
2 离线消息，单聊和群聊的离线全部放一个数据库表吗？还是分开放？  离线拉取单聊时候可以分页拉取，前端再根据userid分到不同好友里面即可，群离线消息的拉取，是一起拉，还是分每个群去请求各自的离线消息，因为last_ack_msgid存储的机制，查询离线时候，需要每个群都去查 > last_ack_msgid的是否存在，如果一起拉会存在需要每个群去sql  >last_ack_msgid 查询是否存在群消息，这样多次sql 会慢， 每个群各自拉自己的，只要sql一次。

引用：86760813 发表于 2019-01-22 09:44
非常感谢你的回答，想再问下：
1 为了解决数据冗余，群里用户只存最后一条last_ack_msgid，其他中间过程 ...

你是打算自已做im吗？

引用：JackJiang 发表于 2019-01-22 10:02
你是打算自已做im吗？

是的，前期可能人数不多，想参考一些成熟的思路去设计，就是一些细节思路不是很清晰，想请教一下

引用：86760813 发表于 2019-01-22 10:05
是的，前期可能人数不多，想参考一些成熟的思路去设计，就是一些细节思路不是很清晰，想请教一下

上面讨论的这种就是扩散读方法。

如果拿扩散读方法，跟扩散写方法来比较的话：

• 扩散读方法可能会有99种缺点，但唯一的优点就是存储可以很省；
• 扩散写方法可能会有99种优化点，但唯一的缺点是存储占的多一些。
  

以上比较你完全可以根据你们的场景和需求来选择。没有必要死磕某一个方法。就技术实现来说，扩散写 要简单多了。如果说，为了追求那少有的优点而要趟过N种缺点，我觉得有点不值。这是我的个人观点了，仅供参考。

引用：JackJiang 发表于 2019-01-22 10:24
上面讨论的这种就是扩散读方法。

如果拿扩散读方法，跟扩散写方法来比较的话：

非常感谢你，群消息存储我决定用last_ack_msgid的方式去做，所以下面要设计，离线拉取群消息的方式，是一次分页拉所有群的，还是一个个群去啦的，就上面查询 sql一次，和多次查询的问题了。就这个问题了   thank you

引用：86760813 发表于 2019-01-22 11:20
非常感谢你，群消息存储我决定用last_ack_msgid的方式去做，所以下面要设计，离线拉取群消息的方式，是一 ...

分页拉取更经济