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，简单易于运维，并且可以透明扩容
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
评论
登录后参与评论
推荐阅读
目录