请选择 进入手机版 | 继续访问电脑版

默认
打赏 发表评论 45
想开发IM:买成品怕坑?租第3方怕贵?找开源自已撸?尽量别走弯路了... 找站长给点建议
是否可以通过端上缓存最新的消息时间戳,拉取的时候带上时间戳向服务器请求,服务器返回>=时间戳的消息。

这样服务端只需一个表存储全量的消息即可。
而且对应多端的情况,也是同样的逻辑。

这样是否可行?
引用:lmyJavaDE1 发表于 2018-08-07 17:02
"进一步优化,解决重复拉取离线消息的问题:拉取了离线消息却没有ACK,服务器不会删除之前的离线消息,故下 ...

这里的去重说的是客户端去重,因为你客户端没有ack,服务端就没法删除已拉取的,所以下次还能拉到,而你客户端本地有缓存,下次再拉的消息,用消息id跟本地的比,已经存在的就表示重复,不保存就行了
签名: 天气忽然就这么冷了!
引用:江明 发表于 2021-07-23 11:01
是否可以通过端上缓存最新的消息时间戳,拉取的时候带上时间戳向服务器请求,服务器返回>=时间戳的消息。
...

可行,这就是个比较优秀的方案
签名: 天气忽然就这么冷了!
学习了
引用:某非著名程序 发表于 2021-02-05 09:24
文中第5条优化2一般一次性拉取,主流的的移动端IM(比如微信、手Q等)通常都是以“优化方案2”为主。然后第 ...

作者前后的描述其实并不矛盾,因为关注的重点不同。

前者主要涉及的是读扩散和写扩散的问题,
所谓读扩散,假设用户有500个好友,那就要执行500个HTTP请求,除了作者说的那些问题,还有
无效请求的问题,即某些好友并没有新增的离线消息。
所谓写扩散,就是有一个额外的「收件箱」,用于存储所有好友的离线消息,每次都要额外写入
一次,用户拉取所有离线消息只需要从这个收件箱拉取即可,拉取之后再在本地进行分组,可以
大大减少请求次数。

后者是在前者的基础上,考虑了离线消息比较多的情况,造成数据量很大,请求速度慢,本地频繁
存储后刷新引起卡顿,因此改成了分页拉取,减少每次拉取和要处理的数据量,边拉取边处理。
引用:lmyJavaDE1 发表于 2018-08-07 17:02
"进一步优化,解决重复拉取离线消息的问题:拉取了离线消息却没有ACK,服务器不会删除之前的离线消息,故下 ...

客户端上次拉过后,本地有缓存,这次再拉到就根据缓存来去掉,缓存里有的就是表示上次已拉过
签名: 天气忽然就这么冷了!
打赏楼主 ×
使用微信打赏! 使用支付宝打赏!

返回顶部