请问IM中消息id在服务端存储时不是顺序的问题，该怎么处理？

消息id的生产可以基于一个会话不严格自增，但这只是在业务服务器上生成的，而不是存在存储中的顺序，可能生成的id是1、2、3，但是在存储中存的是2、1、3，请问大佬们这种有什么解决办法吗，或者别的消息id生成解决方案？

存储时的顺序无所谓的，只要你的消息id是趋势递增（不需要严格递增）就可以，因为你用的时候，按消息id排序就可以

另外，我整理的消息id这个技术专题，你可以好好读一读：

• 《IM消息ID技术专题(一)：微信的海量IM聊天消息序列号生成实践（算法原理篇）》
• 《IM消息ID技术专题(二)：微信的海量IM聊天消息序列号生成实践（容灾方案篇）》
• 《IM消息ID技术专题(三)：解密融云IM产品的聊天消息ID生成策略》
• 《IM消息ID技术专题(四)：深度解密美团的分布式ID生成算法》
• 《IM消息ID技术专题(五)：开源分布式ID生成器UidGenerator的技术实现》
• 《IM消息ID技术专题(六)：深度解密滴滴的高性能ID生成器(Tinyid)》
  

尤其是微信的第一篇！

引用：JackJiang 发表于 2020-12-28 12:13
存储时的顺序无所谓的，只要你的消息id是趋势递增（不需要严格递增）就可以，因为你用的时候，按消息id排序 ...

好的，我有一个疑问，假如消息生成的顺序是 1 2 3，这时候插入的顺序是 1 3 2，而且推给客户端顺序是 1 3 2，当我推到3时候，客户端来拉取最新消息，然后更新拉取位置为3，这时候再取给客户端推送2，发现2小于最新消息位置3，是不是就造成客户端拉取不到这个2的消息，或者我针对这个2的消息单独做什么处理吗？

引用：JackJiang 发表于 2020-12-28 12:14
另外，我整理的消息id这个技术专题，你可以好好读一读：

多谢哥！

引用：手写的从前 发表于 2020-12-28 12:42
好的，我有一个疑问，假如消息生成的顺序是 1 2 3，这时候插入的顺序是 1 3 2，而且推给客户端顺序是 1 3 ...

感觉你推和拉的逻辑很混乱，有清晰的处理思路吗

引用：JackJiang 发表于 2020-12-28 12:55
感觉你推和拉的逻辑很混乱，有清晰的处理思路吗

推是给客户端推送通知，代表有新消息了，然后客户端带着本地的消息位置取服务端拉新的消息，这种逻辑。
这个时候，服务端生成的消息id是 1 2 3 ，存到存储的顺序是1 3 2 ，当客户端被通知3这条消息的时候，取服务端拉新消息然后更新拉取位置是3
然后服务端又推送新消息（这个时候是2），客户端带着消息位置取拉，3 大于2，这个时候怎么特殊处理下？或者别的解决方案

引用：手写的从前 发表于 2020-12-28 18:28
推是给客户端推送通知，代表有新消息了，然后客户端带着本地的消息位置取服务端拉新的消息，这种逻辑。
...

你的客户端逻辑时，每条消息都是先收到通知，然后再去拉取这条新消息？

引用：JackJiang 发表于 2020-12-28 22:32
你的客户端逻辑时，每条消息都是先收到通知，然后再去拉取这条新消息？

计划按照这种方式去做，这样通用型比较好

这个不知道啊！

引用：阿白_A9Kd6 发表于 2020-12-30 12:13
这个不知道啊！

有什么好的想法吗？
或者解决方案

引用：JackJiang 发表于 2020-12-28 22:32
你的客户端逻辑时，每条消息都是先收到通知，然后再去拉取这条新消息？

.