万亿级调用下的优雅——微信序列号生成器架构设计及演变(上)

版权声明：本文由曾钦松原创文章，转载请注明出处: 
文章原文连接：https://www.qcloud.com/community/article/200

来源：腾云阁 https://www.qcloud.com/community

 

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

而在这同步机制的背后，须要一个高可用、高可靠的序列号生成器来产生同步数据用的版本号。这个序列号生成器咱们称之为seqsvr，目前已经发展为一个天天万亿级调用的重量级系统，其中每次申请序列号平时调用耗时1ms，99.9%的调用耗时小于3ms，服务部署于数百台4核CPU服务器上。本文会重点介绍seqsvr的架构核心思想，以及seqsvr随着业务量快速上涨所作的架构演变。

背景

微信服务器端为每一份须要与客户端同步的数据（例如消息）都会赋予一个惟一的、递增的序列号（后文称为sequence），做为这份数据的版本号。在客户端与服务器端同步的时候，客户端会带上已经同步下去数据的最大版本号，后台会根据客户端最大版本号与服务器端的最大版本号，计算出须要同步的增量数据，返回给客户端。这样不只保证了客户端与服务器端的数据同步的可靠性，同时也大幅减小了同步时的冗余数据。

这里不用乐观锁机制来生成版本号，而是使用了一个独立的seqsvr来处理序列号操做，一方面由于业务有大量的sequence查询需求——查询已经分配出去的最后一个sequence，而基于seqsvr的查询操做能够作到很是轻量级，避免对存储层的大量IO查询操做；另外一方面微信用户的不一样种类的数据存在不一样的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的架构原型提及。

架构原型

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

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

预分配中间层

任何一件看起来很简单的事，在海量的访问量下都会变得不简单。前文提到，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

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

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

分号段共享存储

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

咱们能够简单计算下，以目前uid（用户惟一ID）上限2^32个、一个max_seq 8bytes的空间，数据大小一共为32GB，从硬盘加载须要很多时间。另外一方面，出于数据可靠性的考虑，必然须要一个可靠存储系统来保存max_seq数据，重启时经过网络从该可靠存储系统加载数据。若是max_seq数据过大的话，会致使重启时在数据传输花费大量时间，形成一段时间不可服务。

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

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

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

工程实现

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

1. 把存储层和缓存中间层分红两个模块StoreSvr及AllocSvr。StoreSvr为存储层，利用了多机NRW策略来保证数据持久化后不丢失；AllocSvr则是缓存中间层，部署于多台机器，每台AllocSvr负责若干号段的sequence分配，分摊海量的sequence申请请求。

2. 整个系统又按uid范围进行分Set，每一个Set都是一个完整的、独立的StoreSvr+AllocSvr子系统。分Set设计目的是为了作灾难隔离，一个Set出现故障只会影响该Set内的用户，而不会影响到其它用户。

图4. 原型架构图

小结

写到这里把seqsvr基本原型讲完了，正是如此简单优雅的模型，可靠、稳定地支撑着微信五年来的高速发展。五年里访问量一倍又一倍地上涨，seqsvr自己也作过大大小小的重构，但seqsvr的分层架构一直没有改变过，而且在可预见的将来里也会一直保持不变。 原型跟生产环境的版本存在必定差距，最主要的差距在于容灾上。像微信的IM类应用，对系统可用性很是敏感，而seqsvr又处于收发消息、朋友圈等功能的关键路径上，对可用性要求很是高，出现长时间不可服务是分分钟写故障报告的节奏。下一篇文章会讲讲seqsvr的容灾方案演变。