IM消息ID技术专题(一)：微信的海量IM聊天消息序列号生成实践（算法原理篇）

JackJiang · 6 年前

1、点评

对于IM系统来说，如何做到IM聊天消息离线差异拉取（差异拉取是为了节省流量）、消息多端同步、消息顺序保证等，是典型的IM技术难点。

就像即时通讯网整理的以下IM开发干货系列一样：

上面这些文章所涉及的IM聊天消息的省流量、可靠投递、离线拉取、时序性、一致性、多端同步等等问题，总结下来其实就是要解决好一个问题：即如何保证聊天消息的唯一性判定和顺序判定。

很多即时通讯网的群友在讨论这个问题的时候，普遍考虑的是使用整型自增序列号作为消息ID（即MsgId）：这样既能保证消息的唯一性又方便保证顺序性，但问题是在分布式情况下是很难保证消息id的唯一性且顺序递增的，维护id生成的一致性难度太大了（网络延迟、调试出错等等都可能导致不同的机器取到的消息id存在碰撞的可能）。

IM消息ID技术专题(一)：微信的海量IM聊天消息序列号生成实践（算法原理篇）_22.jpg

IM消息ID技术专题(一)：微信的海量IM聊天消息序列号生成实践（算法原理篇）_22.jpg

不过，通过本文中微信团队分享的微信消息序列号生成思路，实际上要解决消息的唯一性、顺序性问题，可以将一个技术点分解成两个：即将原先每条消息一个自增且唯一的消息ID分拆成两个关键属性——消息ID（msgId）、消息序列号（seqId），即消息ID只要保证唯一性而不需要兼顾顺序性（比如直接用UUID）、消息序列号只要保证顺序性而不需要兼顾唯一性（就像本文中微信的思路一样），这样的技术分解就能很好的解决原本一个消息ID既要保证唯一性又要保证顺序性的难题。

那么，如何优雅地解决“消息序列号只要保证顺序性而不需要兼顾唯一性”的问题呢？这就是本文所要分享的内容，强烈建议深入理解和阅读。

本文因篇幅较长，分为上下两篇，敬请点击阅读：
上篇：《微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）》（本文）
下篇：《微信技术分享：微信的海量IM聊天消息序列号生成实践（容灾方案篇）》

推荐：融云团队分享的消息ID生成文章也值得一读《融云技术分享：解密融云IM产品的聊天消息ID生成策略》，美团的这篇也不错《美团技术分享：深度解密美团的分布式ID生成算法》。

本文是“IM消息ID技术专题”系列文章的第1篇，专题总目录如下：

2、正文引言

微信在立项之初，就已确立了利用数据版本号（注：具体的实现也就是本文要分享的消息序列号）实现终端与后台的数据增量同步机制，确保发消息时消息可靠送达对方手机，避免了大量潜在的家庭纠纷。时至今日，微信已经走过第五个年头，这套同步机制仍然在消息收发、朋友圈通知、好友数据更新等需要数据同步的地方发挥着核心的作用。

而在这同步机制的背后，需要一个高可用、高可靠的消息序列号生成器来产生同步数据用的版本号（注：因为序列号天生的递增特性，完全可以当版本号来使用，但又不仅限于版本号的用途）。这个消息序列号生成器我们微信内部称之为 seqsvr ，目前已经发展为一个每天万亿级调用的重量级系统，其中每次申请序列号平时调用耗时1ms，99.9%的调用耗时小于3ms，服务部署于数百台4核 CPU 服务器上。

本篇将重点介绍微信的消息序列号生成器 seqsvr 的算法原理、架构核心思想，以及 seqsvr 随着业务量快速上涨所做的架构演变（下篇《微信技术分享：微信的海量IM聊天消息序列号生成实践（容灾方案篇）》会着重讨论分布式容灾方案，敬请关注）。

IM消息ID技术专题(一)：微信的海量IM聊天消息序列号生成实践（算法原理篇）_1370849023895.jpg

IM消息ID技术专题(一)：微信的海量IM聊天消息序列号生成实践（算法原理篇）_1370849023895.jpg

3、关于作者

曾钦松：微信高级工程师，负责过微信基础架构、微信翻译引擎、微信围棋PhoenixGo，致力于高可用高性能后台系统的设计与研发。2011年毕业于西安电子科技大学，早先曾在腾讯搜搜从事检索架构、分布式数据库方面的工作。

4、技术思路

微信服务器端为每一份需要与客户端同步的数据（例如聊天消息）都会赋予一个唯一的、递增的序列号（后文称为 sequence ），作为这份数据的版本号（这是利用了序列号递增的特性）。在客户端与服务器端同步的时候，客户端会带上已经同步下去数据的最大版本号，后台会根据客户端最大版本号与服务器端的最大版本号，计算出需要同步的增量数据，返回给客户端。这样不仅保证了客户端与服务器端的数据同步的可靠性，同时也大幅减少了同步时的冗余数据（就像这篇文章中讨论的一样：《如何保证IM实时消息的“时序性”与“一致性”？》）。

这里不用乐观锁机制来生成版本号，而是使用了一个独立的 seqsvr 来处理序列号操作：

1）一方面因为业务有大量的 sequence 查询需求——查询已经分配出去的最后一个 sequence ，而基于 seqsvr 的查询操作可以做到非常轻量级，避免对存储层的大量 IO 查询操作；
2）另一方面微信用户的不同种类的数据存在不同的 Key-Value 系统中，使用统一的序列号有助于避免重复开发，同时业务逻辑可以很方便地判断一个用户的各类数据是否有更新。

从 seqsvr 申请的、用作数据版本号的 sequence ，具有两种基本的性质：

1）递增的64位整型变量；
2）每个用户都有自己独立的64位 sequence 空间。

举个例子，小明当前申请的 sequence 为100，那么他下一次申请的 sequence ，可能为101，也可能是110，总之一定大于之前申请的100。而小红呢，她的 sequence 与小明的 sequence 是独立开的，假如她当前申请到的 sequence 为50，然后期间不管小明申请多少次 sequence 怎么折腾，都不会影响到她下一次申请到的值（很可能是51）。

这里用了每个用户独立的64位 sequence 的体系，而不是用一个全局的64位（或更高位） sequence ，很大原因是全局唯一的 sequence 会有非常严重的申请互斥问题，不容易去实现一个高性能高可靠的架构。对微信业务来说，每个用户独立的64位 sequence 空间已经满足业务要求。

目前 sequence 用在终端与后台的数据同步外，同时也广泛用于微信后台逻辑层的基础数据一致性cache中，大幅减少逻辑层对存储层的访问。虽然一个用于终端——后台数据同步，一个用于后台cache的一致性保证，场景大不相同。

但我们仔细分析就会发现，两个场景都是利用 sequence 可靠递增的性质来实现数据的一致性保证，这就要求我们的 seqsvr 保证分配出去的 sequence 是稳定递增的，一旦出现回退必然导致各种数据错乱、消息消失；另外，这两个场景都非常普遍，我们在使用微信的时候会不知不觉地对应到这两个场景：小明给小红发消息、小红拉黑小明、小明发一条失恋状态的朋友圈，一次简单的分手背后可能申请了无数次 sequence。

微信目前拥有数亿的活跃用户，每时每刻都会有海量 sequence 申请，这对 seqsvr 的设计也是个极大的挑战。那么，既要 sequence 可靠递增，又要能顶住海量的访问，要如何设计 seqsvr 的架构？我们先从 seqsvr 的架构原型说起。

5、具体的技术架构原型

不考虑 seqsvr 的具体架构的话，它应该是一个巨大的64位数组，而我们每一个微信用户，都在这个大数组里独占一格8 bytes 的空间，这个格子就放着用户已经分配出去的最后一个 sequence：cur_seq。每个用户来申请sequence的时候，只需要将用户的cur_seq+=1，保存回数组，并返回给用户。

IM消息ID技术专题(一)：微信的海量IM聊天消息序列号生成实践（算法原理篇）_a.jpg

IM消息ID技术专题(一)：微信的海量IM聊天消息序列号生成实践（算法原理篇）_a.jpg

▲ 图1：小明申请了一个sequence，返回101

5.1预分配中间层

任何一件看起来很简单的事，在海量的访问量下都会变得不简单。前文提到，seqsvr 需要保证分配出去的sequence 递增（数据可靠），还需要满足海量的访问量（每天接近万亿级别的访问）。满足数据可靠的话，我们很容易想到把数据持久化到硬盘，但是按照目前每秒千万级的访问量（~10^7 QPS），基本没有任何硬盘系统能扛住。

后台架构设计很多时候是一门关于权衡的哲学，针对不同的场景去考虑能不能降低某方面的要求，以换取其它方面的提升。仔细考虑我们的需求，我们只要求递增，并没有要求连续，也就是说出现一大段跳跃是允许的（例如分配出的sequence序列：1,2,3,10,100,101）。

于是我们实现了一个简单优雅的策略：

1）内存中储存最近一个分配出去的sequence：cur_seq，以及分配上限：max_seq；
2）分配sequence时，将cur_seq++，同时与分配上限max_seq比较：如果cur_seq > max_seq，将分配上限提升一个步长max_seq += step，并持久化max_seq；
3）重启时，读出持久化的max_seq，赋值给cur_seq。

IM消息ID技术专题(一)：微信的海量IM聊天消息序列号生成实践（算法原理篇）_b.jpg

▲ 图2：小明、小红、小白都各自申请了一个sequence，但只有小白的max_seq增加了步长100

这样通过增加一个预分配 sequence 的中间层，在保证 sequence 不回退的前提下，大幅地提升了分配 sequence 的性能。实际应用中每次提升的步长为10000，那么持久化的硬盘IO次数从之前~10^7 QPS降低到~10^3 QPS，处于可接受范围。在正常运作时分配出去的sequence是顺序递增的，只有在机器重启后，第一次分配的 sequence 会产生一个比较大的跳跃，跳跃大小取决于步长大小。

5.2分号段共享存储

请求带来的硬盘IO问题解决了，可以支持服务平稳运行，但该模型还是存在一个问题：重启时要读取大量的max_seq数据加载到内存中。

我们可以简单计算下，以目前 uid（用户唯一ID）上限2^32个、一个 max_seq 8bytes 的空间，数据大小一共为32GB，从硬盘加载需要不少时间。另一方面，出于数据可靠性的考虑，必然需要一个可靠存储系统来保存max_seq数据，重启时通过网络从该可靠存储系统加载数据。如果max_seq数据过大的话，会导致重启时在数据传输花费大量时间，造成一段时间不可服务。

为了解决这个问题，我们引入号段 Section 的概念，uid 相邻的一段用户属于一个号段，而同个号段内的用户共享一个 max_seq，这样大幅减少了max_seq 数据的大小，同时也降低了IO次数。

IM消息ID技术专题(一)：微信的海量IM聊天消息序列号生成实践（算法原理篇）_c.jpg

IM消息ID技术专题(一)：微信的海量IM聊天消息序列号生成实践（算法原理篇）_c.jpg

▲ 图3：小明、小红、小白属于同个Section，他们共用一个max_seq。在每个人都申请一个sequence的时候，只有小白突破了max_seq上限，需要更新max_seq并持久化

目前 seqsvr 一个 Section 包含10万个 uid，max_seq 数据只有300+KB，为我们实现从可靠存储系统读取max_seq 数据重启打下基础。

5.3工程实现

工程实现在上面两个策略上做了一些调整，主要是出于数据可靠性及灾难隔离考虑：

1）把存储层和缓存中间层分成两个模块 StoreSvr 及 AllocSvr 。StoreSvr 为存储层，利用了多机 NRW 策略来保证数据持久化后不丢失； AllocSvr 则是缓存中间层，部署于多台机器，每台 AllocSvr 负责若干号段的 sequence 分配，分摊海量的 sequence 申请请求。
2）整个系统又按 uid 范围进行分 Set，每个 Set 都是一个完整的、独立的 StoreSvr+AllocSvr 子系统。分 Set 设计目的是为了做灾难隔离，一个 Set 出现故障只会影响该 Set 内的用户，而不会影响到其它用户。

IM消息ID技术专题(一)：微信的海量IM聊天消息序列号生成实践（算法原理篇）_d.jpg

▲ 图4：原型架构图

6、本篇小结

写到这里把 seqsvr 基本原型讲完了，正是如此简单优雅的模型，可靠、稳定地支撑着微信五年来的高速发展。五年里访问量一倍又一倍地上涨，seqsvr 本身也做过大大小小的重构，但 seqsvr 的分层架构一直没有改变过，并且在可预见的未来里也会一直保持不变。

原型跟生产环境的版本存在一定差距，最主要的差距在于容灾上。像微信的 IM 类应用，对系统可用性非常敏感，而 seqsvr 又处于收发消息、朋友圈等功能的关键路径上，对可用性要求非常高，出现长时间不可服务是分分钟写故障报告的节奏。

本文的下篇《微信技术分享：微信的海量IM聊天消息序列号生成实践（容灾方案篇）会讲讲 seqsvr 的容灾方案演变。

另：2024年4月8日发布的《微信团队分享：来看看微信十年前的IM消息收发架构，你做到了吗》一文中提到的利用sequence序列号实现消息防丢机制的原理，也可以一并阅读之。

附录：更多QQ、微信团队原创技术文章

35 楼: tsukiyo · 3 个月前

学到了，非常好

34 楼: janice0721 · 4 个月前

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

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

33 楼: ArtanisL · 8 个月前

引用：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。

32 楼: ayuan9900 · 1 年前

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

31 楼: 愿意 · 1 年前

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

30 楼: 啥也不是 · 1 年前

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

29 楼: AnonXG · 1 年前

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

28 楼: 肥猫布里奇高 · 2 年前

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

27 楼: ZJoker · 2 年前

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

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

26 楼: JackJiang · 2 年前

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

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

25 楼: ZJoker · 2 年前

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

24 楼: ZJoker · 2 年前

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

23 楼: BrainWong · 2 年前

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

22 楼: JackJiang · 2 年前

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

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

21 楼: Tevins · 2 年前

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

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

20 楼: JackJiang · 2 年前

引用：binarywz 发表于 2022-06-22 23:15
同在思考这个问题，而且就算是seqsvr给也存在什么时机给的问题，假如端上本地申请了seq，但是发消息的时 ...

断网这种情况，没必要考虑的那么极端，断网的消息不能发就是不能发
不过按微信做事精益求精的态度，很可能在网络恢复后有个sql同步和重整的动作

19 楼: binarywz · 2 年前

引用：fanjunchao 发表于 2021-12-09 17:57
如果考虑多端问题，假设PC端和移动端“同时”发送消息，如何保证后续不会乱序？序列号由seqsvr给会不会更好 ...

同在思考这个问题，而且就算是seqsvr给也存在什么时机给的问题，假如端上本地申请了seq，但是发消息的时候网断了，那么分配到的seq该怎么处理，还是说直接丢弃

18 楼: fanjunchao · 3 年前

如果考虑多端问题，假设PC端和移动端“同时”发送消息，如何保证后续不会乱序？序列号由seqsvr给会不会更好？

17 楼: JackJiang · 3 年前

引用：深海发表于 2021-09-28 23:10
用户A发送消息msg1，本地生成的序列号是100，那消息被服务端转发给了用户B，请问用户B收到的msg1的序列号是 ...

转发的消息本质其实还是一条新消息，只是消息内容是转发内容而已

本文目录

1、点评

2、正文引言

3、关于作者

4、技术思路