引用：JackJiang 发表于 2019-10-17 18:59
你没看懂吧，说白了每次拿的是个起始值，然后在间隔内自已用的时候递增，下次再取的时候再取一个新的起始 ...

请教一下，这样理解是否正确，客户端上线后从服务端拿到自己的序列号起始值，发送消息时，客户端在本地递增序列号，服务端收到消息时，去维护更新该客户端的cur_seq和max_seq

引用：Tevins 发表于 2022-06-30 09:44
请教一下，这样理解是否正确，客户端上线后从服务端拿到自己的序列号起始值，发送消息时，客户端在本地递 ...

客户端从服务端拉序列号起始值时，服务端就会更新，发消息时不需要更新，否则就影响性能了

看完整个文章，比较迷惑的点是每个用户一个唯一自增id，和每个会话中的唯一自增id两者之间有什么关系吗?

为什么是个人，消息应该是群为单位吗

这个消息序号和id发号器给的消息id是不同的东西。这个是绝对有序的吗

引用：ZJoker 发表于 2022-11-04 23:00
这个消息序号和id发号器给的消息id是不同的东西。这个是绝对有序的吗

微信的这个序列号是顺序递增，但不保证连续

引用：JackJiang 发表于 2022-11-05 00:05
微信的这个序列号是顺序递增，但不保证连续

不绝对连续，那怎么保证消息丢失客户端拉取补偿呀

请问大佬，微信这种按用户维度的递增id，群消息的有序性，如何保证？

文中这一句：每个用户来申请sequence的时候，只需要将用户的cur_seq+=1，保存回数组，并返回给用户。
这个应该怎么理解？是指客户端每次发送消息的时候，先跟服务器申请sequence吗？只不过服务器将逻辑简化cur_seq+=1再返回给用户。

想问下 私聊看之前的文章是写扩散的  那么A给B发消息  消息id是uid层面的递增 那么一条消息实际是会产生两个消息id分别落在A和B的消息信箱 服务端按照uid划分set  set是异地多活来高可用性的吗？如果是  会不会出现A和B在生成自己的消息id的时候跨set  比如A在set1深圳部署 B在set2无锡部署  那么这条消息是有一半的概率跨机房获取消息id的？会慢很多？

有点不解：每个用户会在发送消息的时候去服务器申请一个初始seq，然后后续发消息的时候在这个基础上递增，而且这些初始值每个用户是独立的，那怎么保证一个会话里的消息顺序

这个是由客户端发起请求得到的序列号段吧，当客户端序列号段没有了，又重新获取，由于以用户的维度，只能在单方的消息里面保持顺序，但是解决不了如何把对方发来的消息和我方发的消息排序。