默认
引用：ArtanisL 发表于 2024-07-11 20:58 哥，能详细讲一下嘛，这块我好像也有点晕 |
引用：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。 |
| 这个是由客户端发起请求得到的序列号段吧，当客户端序列号段没有了，又重新获取，由于以用户的维度，只能在单方的消息里面保持顺序，但是解决不了如何把对方发来的消息和我方发的消息排序。 |
| 有点不解：每个用户会在发送消息的时候去服务器申请一个初始seq，然后后续发消息的时候在这个基础上递增，而且这些初始值每个用户是独立的，那怎么保证一个会话里的消息顺序 |
|
想问下 私聊看之前的文章是写扩散的 那么A给B发消息 消息id是uid层面的递增 那么一条消息实际是会产生两个消息id分别落在A和B的消息信箱 服务端按照uid划分set set是异地多活来高可用性的吗？如果是 会不会出现A和B在生成自己的消息id的时候跨set 比如A在set1深圳部署 B在set2无锡部署 那么这条消息是有一半的概率跨机房获取消息id的？会慢很多？ |
|
文中这一句：每个用户来申请sequence的时候，只需要将用户的cur_seq+=1，保存回数组，并返回给用户。 这个应该怎么理解？是指客户端每次发送消息的时候，先跟服务器申请sequence吗？只不过服务器将逻辑简化cur_seq+=1再返回给用户。 |
| 请问大佬，微信这种按用户维度的递增id，群消息的有序性，如何保证？ |
引用：JackJiang 发表于 2022-11-05 00:05 不绝对连续，那怎么保证消息丢失客户端拉取补偿呀 |
引用：ZJoker 发表于 2022-11-04 23:00 微信的这个序列号是顺序递增，但不保证连续 |
| 这个消息序号和id发号器给的消息id是不同的东西。这个是绝对有序的吗 |
|
为什么是个人，消息应该是群为单位吗 |
|
看完整个文章，比较迷惑的点是每个用户一个唯一自增id，和每个会话中的唯一自增id两者之间有什么关系吗? |
引用：Tevins 发表于 2022-06-30 09:44 客户端从服务端拉序列号起始值时，服务端就会更新，发消息时不需要更新，否则就影响性能了 |
引用：JackJiang 发表于 2019-10-17 18:59 请教一下，这样理解是否正确，客户端上线后从服务端拿到自己的序列号起始值，发送消息时，客户端在本地递增序列号，服务端收到消息时，去维护更新该客户端的cur_seq和max_seq |
引用：binarywz 发表于 2022-06-22 23:15 断网这种情况，没必要考虑的那么极端，断网的消息不能发就是不能发 不过按微信做事精益求精的态度，很可能在网络恢复后有个sql同步和重整的动作 |
引用：fanjunchao 发表于 2021-12-09 17:57 同在思考这个问题，而且就算是seqsvr给也存在什么时机给的问题，假如端上本地申请了seq，但是发消息的时候网断了，那么分配到的seq该怎么处理，还是说直接丢弃 |
|
如果考虑多端问题，假设PC端和移动端“同时”发送消息，如何保证后续不会乱序？序列号由seqsvr给会不会更好？ |
引用：深海 发表于 2021-09-28 23:10 转发的消息本质其实还是一条新消息，只是消息内容是转发内容而已 |
| 用户A发送消息msg1，本地生成的序列号是100，那消息被服务端转发给了用户B，请问用户B收到的msg1的序列号是多少，是用户B本地生成的新序列号对吧 |
Copyright © 2014-2024 即时通讯网 - 即时通讯开发者社区 / 版本 V4.4
苏州网际时代信息科技有限公司 (苏ICP备16005070号-1）
首页
组图打开中，请稍候......
收藏
支持
反对