那么，seqsvr最核心的点是什么呢?每个uid的sequence申请要递增不回退。这里我们发现，如果seqsvr满足这么一个约束：任意时刻任意uid有且仅有一台AllocSvr提供服务，就可以比较容易地实现sequence递增不回退的要求。
图5. 两台AllocSvr服务同个uid造成sequence回退。Client读取到的sequence序列为101、201、102
但也由于这个约束，多台AllocSvr同时服务同一个号段的多主机模型在这里就不适用了。我们只能采用单点服务的模式，当某台AllocSvr发生服务不可用时，将该机服务的uid段切换到其它机器来实现容灾。这里需要引入一个仲裁服务，探测AllocSvr的服务状态，决定每个uid段由哪台AllocSvr加载。出于可靠性的考虑，仲裁模块并不直接操作AllocSvr，而是将加载配置写到StoreSvr持久化，然后AllocSvr定期访问StoreSvr读取最新的加载配置，决定自己的加载状态。
图6. 号段迁移示意。通过更新加载配置把0~2号段从AllocSvrA迁移到AllocSvrB
同时，为了避免失联AllocSvr提供错误的服务，返回脏数据，AllocSvr需要跟StoreSvr保持租约。这个租约机制由以下两个条件组成：
租约失效：AllocSvr N秒内无法从StoreSvr读取加载配置时，AllocSvr停止服务
租约生效：AllocSvr读取到新的加载配置后，立即卸载需要卸载的号段，需要加载的新号段等待N秒后提供服务
图7. 租约机制。AllocSvrB严格保证在AllocSvrA停止服务后提供服务
这两个条件保证了切换时，新AllocSvr肯定在旧AllocSvr下线后才开始提供服务。但这种租约机制也会造成切换的号段存在小段时间的不可服务，不过由于微信后台逻辑层存在重试机制及异步重试队列，小段时间的不可服务是用户无感知的，而且出现租约失效、切换是小概率事件，整体上是可以接受的。
到此讲了AllocSvr容灾切换的基本原理，接下来会介绍整个seqsvr架构容灾架构的演变
五、容灾1.0架构：主备容灾
最初版本的seqsvr采用了主机+冷备机容灾模式：全量的uid空间均匀分成N个Section，连续的若干个Section组成了一个Set，每个Set都有一主一备两台AllocSvr。正常情况下只有主机提供服务;在主机出故障时，仲裁服务切换主备，原来的主机下线变成备机，原备机变成主机后加载uid号段提供服务。
图8. 容灾1.0架构：主备容灾
可能看到前文的叙述，有些同学已经想到这种容灾架构。一主机一备机的模型设计简单，并且具有不错的可用性——毕竟主备两台机器同时不可用的概率极低，相信很多后台系统也采用了类似的容灾策略。
设计权衡
主备容灾存在一些明显的缺陷，比如备机闲置导致有一半的空闲机器;比如主备切换的时候，备机在瞬间要接受主机所有的请求，容易导致备机过载。既然一主一备容灾存在这样的问题，为什么一开始还要采用这种容灾模型?事实上，架构的选择往往跟当时的背景有关，seqsvr诞生于微信发展初期，也正是微信快速扩张的时候，选择一主一备容灾模型是出于以下的考虑：
架构简单，可以快速开发
机器数少，机器冗余不是主要问题
Client端更新AllocSvr的路由状态很容易实现
前两点好懂，人力、机器都不如时间宝贵。而第三点比较有意思，下面展开讲下
微信后台绝大部分模块使用了一个自研的RPC框架，seqsvr也不例外。在这个RPC框架里，调用端读取本地机器的client配置文件，决定去哪台服务端调用。这种模型对于无状态的服务端，是很好用的，也很方便实现容灾。我们可以在client配置文件里面写“对于号段x，可以去SvrA、SvrB、SvrC三台机器的任意一台访问”，实现三主机容灾。
但在seqsvr里，AllocSvr是预分配中间层，并不是无状态的。而前面我们提到，AllocSvr加载哪些uid号段，是由保存在StoreSvr的加载配置决定的。那么这时候就尴尬了，业务想要申请某个uid的sequence，Client端其实并不清楚具体去哪台AllocSvr访问，client配置文件只会跟它说“AllocSvrA、AllocSvrB…这堆机器的某一台会有你想要的sequence”。换句话讲，原来负责提供服务的AllocSvrA故障，仲裁服务决定由AllocSvrC来替代AllocSvrA提供服务，Client要如何获知这个路由信息的变更?