一、摘要
微信在立项之初，就已确立了利用数据版本号实现终端与后台的数据增量同步机制，确保发消息时消息可靠送达对方手机，避免了大量潜在的家庭纠纷。时至今日，微信已经走过第五个年头，这套同步机制仍然在消息收发、朋友圈通知、好友数据更新等需要数据同步的地方发挥着核心的作用。而在这同步机制的背后，需要一个高可用、高可靠的序列号生成器来产生同步数据用的版本号。这个序列号生成器我们称之为seqsvr，目前已经发展为一个每天万亿级调用的重量级系统，其中每次申请序列号平时调用耗时1ms，99.9%的调用耗时小于3ms，服务部署于数百台4核CPU服务器上。本文会重点介绍seqsvr的架构核心思想，以及seqsvr随着业务量快速上涨所做的架构演变。
二、背景
微信服务器端为每一份需要与客户端同步的数据(例如消息)都会赋予一个唯一的、递增的序列号(后文称为sequence)，作为这份数据的版本号。在客户端与服务器端同步的时候，客户端会带上已经同步下去数据的最大版本号，后台会根据客户端最大版本号与服务器端的最大版本号，计算出需要同步的增量数据，返回给客户端。这样不仅保证了客户端与服务器端的数据同步的可靠性，同时也大幅减少了同步时的冗余数据。
这里不用乐观锁机制来生成版本号，而是使用了一个独立的seqsvr来处理序列号操作，一方面因为业务有大量的sequence查询需求——查询已经分配出去的最后一个sequence，而基于seqsvr的查询操作可以做到非常轻量级，避免对存储层的大量IO查询操作;另一方面微信用户的不同种类的数据存在不同的Key-Value系统中，使用统一的序列号有助于避免重复开发，同时业务逻辑可以很方便地判断一个用户的各类数据是否有更新。
从seqsvr申请的、用作数据版本号的sequence，具有两种基本的性质：
递增的64位整型变量
每个用户都有自己独立的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)，基本没有任何硬盘系统能扛住。