默认
打赏 发表评论 51
想开发IM:买成品怕坑?租第3方怕贵?找开源自已撸?尽量别走弯路了... 找站长给点建议
引用:lmyJavaDE1 发表于 2018-08-07 17:02
"进一步优化,解决重复拉取离线消息的问题:拉取了离线消息却没有ACK,服务器不会删除之前的离线消息,故下 ...

主流的移动端IM,都会把拉取过的消息离线保存到sqlite,以备在无网的情况下也可以使用(就像微信宣称不存储用户聊天记一样,都是存储到本地了)。所以是完全有条件去重的
引用:JackJiang 发表于 2018-08-07 18:53
主流的移动端IM,都会把拉取过的消息离线保存到sqlite,以备在无网的情况下也可以使用(就像微信宣称不存 ...

那如果要是此时的客户端是web网页呢?这种情况应该怎么处理?
引用:lmyJavaDE1 发表于 2018-08-08 09:21
那如果要是此时的客户端是web网页呢?这种情况应该怎么处理?

web端都是每次从服务端拉取聊天记录,不存在重复的问题。手机端重复是因为本地跟服务端都有存储才导致的,web端不用考虑这个问题。
有个问题,分页按需拉取,假设有1000条离线消息,其中前100条是同一个会话中的,每次分页拉取也是100条,那么岂不是第一次拉下来的时候的消息全部是一个会话的,其他会话就不更新吗?
签名: 最后两天了 坚持住 你行的!
引用:lee3164 发表于 2019-09-30 11:46
有个问题,分页按需拉取,假设有1000条离线消息,其中前100条是同一个会话中的,每次分页拉取也是100条,那 ...

已经在你的贴子《求教关于IM离线聊天消息同步策略的的一些疑惑》,回复你了
26 楼: bakatora Lv.1 4 年前 来自手机 | 显示全部楼层
您好,我想问一下,在推送系统的场景下,消息存储用什么数据库比较好,我感觉直接用sql并不是很好的一个选择,消息存储更类似于一个队列。
引用:bakatora 发表于 2020-01-08 18:27
您好,我想问一下,在推送系统的场景下,消息存储用什么数据库比较好,我感觉直接用sql并不是很好的一个选 ...

推送系统没那么高的要求,数据量不大就用mysql好了,如果是海量那就用nosql吧
通常情况下,主流的的移动端IM(比如微信、手Q等)通常都是以“优化方案2”为主,因为移动网络的不可靠性加上电量、流量等资源的昂贵性,能尽量一次性干完的事,就尽可能一次搞定,从而提供整个APP的用户体验(对于移动端应用而言,省电、省流量同样是用户体验的一部分)。
-------------------------------
1.如果消息量很大,一次性拉完很不现实吧
2.这个做法相比多次拉取,具体是如何节省电量和流量的呢。
SMC理论:系统层面无法做到消息不丢不重,业务层面可以做到,对用户无感知。
想问一下SMC理论是什么
可以用redis list结构存储离线消息么
引用:宋宋嗖嗖嗖 发表于 2020-02-14 22:34
可以用redis list结构存储离线消息么

没什么不可以,关键是能不能满足你的功能设计。
你好,请问netty怎么实现重发消息
引用:宋宋嗖嗖嗖 发表于 2020-02-20 00:01
你好,请问netty怎么实现重发消息

自已实现。

评分

1

查看评分

你好,我有个疑问,就是最后说分页拉取的时候,后一次是前一次的ack,会不会出现拉20条消息,有一条丢了,这个时候处于一种半完成的状态,是要单独把丢失的那条拿到然后再下一页吗?
感谢分享
引用:ToFind1991 发表于 2020-04-01 18:00
你好,我有个疑问,就是最后说分页拉取的时候,后一次是前一次的ack,会不会出现拉20条消息,有一条丢了,这 ...

分布拉取一般都是通过http接口,要么全部成功,要么全部失败。
服务端不会存储消息,如果客户端切换设备,或者同时有多个端如PC端、手机端,是不是意味着没有历史记录
引用:某非著名程序 发表于 2021-01-31 09:14
服务端不会存储消息,如果客户端切换设备,或者同时有多个端如PC端、手机端,是不是意味着没有历史记录

是的
文中第5条优化2一般一次性拉取,主流的的移动端IM(比如微信、手Q等)通常都是以“优化方案2”为主。然后第6条提到又分页拉取,这个分页也是拉取所有好友的分页消息,然后点进会话再拉取对应的离线消息吗?
引用:某非著名程序 发表于 2021-02-05 09:24
文中第5条优化2一般一次性拉取,主流的的移动端IM(比如微信、手Q等)通常都是以“优化方案2”为主。然后第 ...

微信是这个逻辑,但qq貌似有点差异
打赏楼主 ×
使用微信打赏! 使用支付宝打赏!

返回顶部