请教个关于IM中使用批量ack应答来标记消息送达的问题

想请教一下，像比如服务端推送了1666661，1666662，1666667，1666669四条消息，以ack合并的模式，如果收到了124三条，服务端标记了4，实际上会丢失了3，这种情况是怎么解决呢？
消息id类似于雪花算法是趋势递增。
如果是绝对递增的 1 2 3 4。这样的逻辑可以参考tcp滑动窗口解决，雪花算法这种如何处理呢？

引用：frfr46467979 发表于 2022-10-06 16:10
还有一个疑问，比方说发送了 1234 ，4条消息。本地做持久化12 4 ，其中3没收到，本地记录的还是4，这时候 ...

你读一下这两篇：

《IM消息送达保证机制实现(二)：保证离线消息的可靠投递》
《IM群聊消息如此复杂，如何保证不丢不重？》

引用：JackJiang 发表于 2022-10-06 10:52
你不要被一些文章的理论误导了，合并批量ACK应答是有前提的，前提是在消息能严格保证顺序、保证送达率的情 ...

还有一个疑问，比方说发送了 1234 ，4条消息。本地做持久化12 4 ，其中3没收到，本地记录的还是4，这时候客户端下线了，下次上线时拿着4往服务端拉离线消息，3是不是就被丢失了？
服务端要如何处理这种情况？

你不要被一些文章的理论误导了，合并批量ACK应答是有前提的，前提是在消息能严格保证顺序、保证送达率的情况下才能这么玩。

否则消息肯定会被错误标记送达而误丢。

所以，在没有搞定批量ACK应答的前提条件之前，还是老老实实逐条应答。有一个例外就是，除非你的产品定义上，能接受因错误标记送达而误丢的这种几率