是否可以通过端上缓存最新的消息时间戳，拉取的时候带上时间戳向服务器请求，服务器返回>=时间戳的消息。

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

这样是否可行？

引用：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，服务器不会删除之前的离线消息，故下 ...

客户端上次拉过后，本地有缓存，这次再拉到就根据缓存来去掉，缓存里有的就是表示上次已拉过

关于“Step 2：服务器查看用户B的状态，发现B的状态为“offline”（即B当前不在线）；”
当用户B在线，服务端推送下行消息给B的时候失败了，导致B的客户端未收取到消息，消息也没有存入到离线消息库，这种情况会导致用户B的客户端丢失消息吧。

引用：doublesouth 发表于 2023-06-08 19:49
关于“Step 2：服务器查看用户B的状态，发现B的状态为“offline”（即B当前不在线）；”
当用户B在线，服 ...

通常肯定是先持久化存库再下方，不然必定会有意外发生

我只是好奇，又查询又删除的，这数据库不会锁表吗？

引用：JackJiang 发表于 2023-06-08 21:20
通常肯定是先持久化存库再下方，不然必定会有意外发生

如果每条消息在下发之前都存入离线消息库，是不是还得监听客户端ack，如果确认客户端收到消息了再从离线库删除消息？
没有这个机制的话，离线消息库感觉存储的并不是都是离线消息，退化成存储了全量的消息。

引用：doublesouth 发表于 2023-06-09 12:42
如果每条消息在下发之前都存入离线消息库，是不是还得监听客户端ack，如果确认客户端收到消息了再从离线 ...

严谨来说，确实需要客户端ack的

服务端居然不存储消息吗？如果客户端卸载了软件，以前的消息其实是丢了？按道理无论在线还是离线都应该存消息的吧