求教IM中离线聊天消息的拉取，应该通过 http 还是 socket？

关于离线消息的拉取阅读了着两篇文章《IM开发干货分享：如何优雅的实现大量离线消息的可靠投递》《IM消息送达保证机制实现(二)：保证离线消息的可靠投递》。现在我们决定拉取的时候选择全量拉取，全量拉取对比分页拉取服务端和客户端省了不少麻烦，
可是看有些大佬选用 http 方式来拉取离线消息，
要是用 socket 拉取免不了的 ack 确认，还可能不准确，那就要去重。 如果选用 http 的方式一次性全量拉取后后台直接删掉，会不会稳妥一点。
或者说那种方式更好一些呢？

引用：Sfa 发表于 2020-09-27 11:22
谢大佬，我再思考思考吧

前期先往 简单了做，而不是往复杂做。过来人的建议，切记！

引用：JackJiang 发表于 2020-09-27 11:16
我觉得涉及到具体的实现细节，暂时可以不用过多纠结，先简单把它做出来就好。
我的建议是，前期你们就用 ...

谢大佬，我再思考思考吧

引用：Sfa 发表于 2020-09-27 11:04
我们现在确认的是这种通过每个群用户发来的 ack 然后存储 last_ack_msg_id 的方式。因为群组不会多
离线 ...

我觉得涉及到具体的实现细节，暂时可以不用过多纠结，先简单把它做出来就好。
我的建议是，前期你们就用扩散写的方式来实现，这样技术上最简单，也能快速做出原型，后面有必要的话，再来优化成扩散读。

引用：JackJiang 发表于 2020-09-27 10:38
这篇文章你得好好读一读《IM群聊消息究竟是存1份(即扩散读)还是存多份(即扩散写)？》

我们现在确认的是这种通过每个群用户发来的 ack 然后存储 last_ack_msg_id 的方式。因为群组不会多
离线是：上线后服务端发送一个每个不同会话（群组或1 v 1）的离线消息总数、离线消息最新一条（供客户端列表显示），当点开到某个会话室的时候才开始拉取离线消息这个会话的离线

引用：Sfa 发表于 2020-09-27 09:38
那群的离线消息是不是就得存多份了？

这篇文章你得好好读一读《IM群聊消息究竟是存1份(即扩散读)还是存多份(即扩散写)？》

引用：JackJiang 发表于 2020-09-25 19:29
建议你先别搞这种增量拉取了，直接最简单的有离线就拉，拉完就从服务端删除。

那每个离线群成员是不是就得把群消息一条条的都存下来

引用：JackJiang 发表于 2020-09-25 19:29
建议你先别搞这种增量拉取了，直接最简单的有离线就拉，拉完就从服务端删除。

那群的离线消息是不是就得存多份了？

引用：Sfa 发表于 2020-09-25 15:32
有个问题是 群组的离线消息按照你之前文章里说的，不用单独存储群用户消息离线表，只是在用户接收到消息 ...

建议你先别搞这种增量拉取了，直接最简单的有离线就拉，拉完就从服务端删除。

引用：JackJiang 发表于 2020-09-25 15:13
用http是最好的方法，不用纠结。http简单、易用，而且有大把的通用的方案，未来性能吃紧的时候，Http完全可 ...

有个问题是 群组的离线消息按照你之前文章里说的，不用单独存储群用户消息离线表，只是在用户接收到消息后通过发到服务器的 ack 来记录最后收到的一条消息， 然后根据这个消息的 id 判断是否为离线消息，那么如果，在客户端还没有拉取群组离线时，接收到了这个群组的一条新消息，这时候该怎么办呢？

引用：JackJiang 发表于 2020-09-25 15:13
用http是最好的方法，不用纠结。http简单、易用，而且有大把的通用的方案，未来性能吃紧的时候，Http完全可 ...

谢大佬答疑

用http是最好的方法，不用纠结。http简单、易用，而且有大把的通用的方案，未来性能吃紧的时候，Http完全可以独立拆分出来，用上nginx这些东西。

你体会一下，离线消息的拉取，跟实时通信通道已经没有任何关联了，完全可以作为最简单的http服务。