引用：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离线聊天消息同步策略的的一些疑惑》，回复你了

您好，我想问一下，在推送系统的场景下，消息存储用什么数据库比较好，我感觉直接用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怎么实现重发消息

自已实现。

你好，我有个疑问，就是最后说分页拉取的时候，后一次是前一次的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貌似有点差异