IM系统的消息序列号服务

一、方案比较

核心功能：生成唯一自增 序列号。比较以下三种方案：

• 全局：共用一个key，产生一个id，但是有热点性能问题
• 私有：为每个用户id私自，生成序列号id，每个用户在预分配的存储桶取，存储空间大，浪费大量空间
• 分段：分好段，每一段用户共享一个key，但是分段节点故障，可能存在短时不可用，需要仲裁器接入进行重新hash

二、架构设计（微信方案）

seq_alloc：当前id，预取（seq_info存到seq_stroe），每个seq_alloc管理号段

seq_arbitration仲裁器：如果这个seq_alloc管理号段挂掉， 每个seq_arbitration仲裁，进行重新一致性hash，会对老的序列号分配到新可用seq_alloc节点，挂了租约过程（比如说仲裁时间是10s，这个时间内 挂掉的seq_alloc 服务不可用）。仲裁本身也需要高可用。需要仲裁的可用性改造，改成多机器改造。

以上结构复杂，运维成本大。

三、架构设计（paxos kv）

paxos kv ：号段自增， 预估容量几万qps，简单易于运维，并且可以透明扩容