默认
发表评论 11
想开发IM:买成品怕坑?租第3方怕贵?找开源自已撸?尽量别走弯路了... 找站长给点建议
求教IM中离线聊天消息的拉取,应该通过 http 还是 socket?
阅读(46854) | 评论(11 收藏 淘帖
关于离线消息的拉取阅读了着两篇文章《IM开发干货分享:如何优雅的实现大量离线消息的可靠投递》《IM消息送达保证机制实现(二):保证离线消息的可靠投递》。现在我们决定拉取的时候选择全量拉取,全量拉取对比分页拉取服务端和客户端省了不少麻烦,
可是看有些大佬选用 http 方式来拉取离线消息,
要是用 socket 拉取免不了的 ack 确认,还可能不准确,那就要去重。 如果选用 http 的方式一次性全量拉取后后台直接删掉,会不会稳妥一点。
或者说那种方式更好一些呢?

即时通讯网 - 即时通讯开发者社区! 来源: - 即时通讯开发者社区!

上一篇:求教各位,怎么保证IM群消息在线的的用户都收到下一篇:关于IM群消息,服务端是否应该给发送者回复ack应答?
推荐方案
评论 11
用http是最好的方法,不用纠结。http简单、易用,而且有大把的通用的方案,未来性能吃紧的时候,Http完全可以独立拆分出来,用上nginx这些东西。

你体会一下,离线消息的拉取,跟实时通信通道已经没有任何关联了,完全可以作为最简单的http服务。
引用:JackJiang 发表于 2020-09-25 15:13
用http是最好的方法,不用纠结。http简单、易用,而且有大把的通用的方案,未来性能吃紧的时候,Http完全可 ...

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

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

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

那群的离线消息是不是就得存多份了?
引用:JackJiang 发表于 2020-09-25 19:29
建议你先别搞这种增量拉取了,直接最简单的有离线就拉,拉完就从服务端删除。

那每个离线群成员是不是就得把群消息一条条的都存下来
引用:Sfa 发表于 2020-09-27 09:38
那群的离线消息是不是就得存多份了?

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

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

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

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

前期先往 简单了做,而不是往复杂做。过来人的建议,切记!
打赏楼主 ×
使用微信打赏! 使用支付宝打赏!

返回顶部