IM系统的消息序列号服务

2021-02-14 12:18:13 浏览数 (1)

一、方案比较

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

  • 全局:共用一个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,简单易于运维,并且可以透明扩容

0 人点赞