引用：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，然后后续发消息的时候在这个基础上递增，而且这些初始值每个用户是独立的，那怎么保证一个会话里的消息顺序

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

引用：ayuan9900 发表于 2023-10-09 16:54
这个是由客户端发起请求得到的序列号段吧，当客户端序列号段没有了，又重新获取，由于以用户的维度，只能在 ...

我觉得楼上的分析过程有问题。这个seq是服务端生成并且服务端自己使用的，客户端发消息不会给这条消息附带上seq，客户端只在同步的时候用seq，要不然多设备发消息的时候用本地拉取的seq，那消息的时序全乱套了。首先微信写扩散，A发送消息给B，写到B的inbox里面，写inbox的时候会为这条消息分配seq1，同时A发送消息也会给A的inbox写入，这个时候同样会为这条消息分配seq2。注意seq是单用户内唯一，即用户inbox维度的唯一，seq1是B inbox，seq2是A inbox。

引用：ArtanisL 发表于 2024-07-11 20:58
我觉得楼上的分析过程有问题。这个seq是服务端生成并且服务端自己使用的，客户端发消息不会给这条消息附 ...

哥，能详细讲一下嘛，这块我好像也有点晕