谈谈常用的分布式 ID 设计方案

首先,分布式全局 ID 的解决方案有很多,比如:

  • 使用 Mysql 的全局表
  • 使用 Zookeeper 的有序节点
  • 使用 MongoDB 的 objectid
  • redis 的自增 id
  • UUID 等等
  • ......

这些方案只是解决基础的 id 唯一性问题,在实际生产环境中,需要构建一个全局唯一 id 还需要考虑更多的因素:

  • 有序性, 有序的 ID 能够更好地确认数据的位置,

以及 B+数据的存储结构中,范围查询的效率更高,并且可以提升 B+树数据维护的效率。

  • 安全性,避免恶意爬取数据造成数据泄露
  • 可用性,ID 生成系统的可用性要求非常高,一旦出现故障就会造成业务不可用的问题
  • 性能,全局 id 生成系统需要满足整个公司的业务需求,涉及亿级别的调用,对性能要求较高 因此,如果我们选择数据库的全局表,你每获取一次 id 就需要更新数据库,性能上限比较明显, 而且基于数据库构建高扩展和高性能的解决方案难度很大。

所以,目前市面上主流的解决方案是基于 Twitter 早期开源的 Snowflake 雪花算法(图片)。

它是由 64 位长度组成的全局 id 生成算法,通过对 64 位进行区间划分来表述不同含义实现唯一性。

它的好处是:

  • 算法实现简单
  • 不存在太多外部依赖
  • 可以生成有意义的有序编号
  • 基于位运算,性能也很好,Twitter 测试的峰值是 10 万个每秒。

另外,美团公司开源了一个全局唯一 id 生成系统 leaf,它里面也用到了雪花算法去构建全局唯一 id 并且在高性能和高可用方面,做了很多的优化,为美团内部业务提供了每天上亿次的调用。

相关推荐
G探险者5 小时前
《深入理解 Nacos 集群与 Raft 协议》系列五:为什么集群未过半,系统就不可用?从 Raft 的投票机制说起
分布式·后端
G探险者5 小时前
《深入理解 Nacos 集群与 Raft 协议》系列一:为什么 Nacos 集群必须过半节点存活?从 Raft 协议说起
分布式·后端
G探险者5 小时前
《深入理解 Nacos 集群与 Raft 协议》系列四:日志复制机制:Raft 如何确保提交可靠且幂等
分布式·后端
G探险者5 小时前
《深入理解 Nacos 集群与 Raft 协议》系列三:日志对比机制:Raft 如何防止数据丢失与错误选主
分布式·后端
G探险者5 小时前
《深入理解 Nacos 集群与 Raft 协议》系列二:Raft 为什么要“选主”?选主的触发条件与机制详解
分布式·后端
Vesan,7 小时前
网络通讯知识——通讯分层介绍,gRPC,RabbitMQ分层
网络·分布式·rabbitmq·无人机
火龙谷7 小时前
【hadoop】相关集群开启命令
大数据·hadoop·分布式
观无11 小时前
redis分布式锁
数据库·redis·分布式
颜淡慕潇11 小时前
Redis 实现分布式锁:深入剖析与最佳实践(含Java实现)
java·redis·分布式
啾啾Fun12 小时前
【Java微服务组件】分布式协调P4-一文打通Redisson:从API实战到分布式锁核心源码剖析
java·redis·分布式·微服务·lua·redisson