分布式ID生成器_架构师之路

分布式ID生成器 | 架构师之路 一、需求缘起 几乎所有的业务系统，都有生成一个唯一记录标识的需求 ，例如： 消息标识： message-id 订单标识： order-id 帖子标识： tiezi-id 这个记录标识往往就是数据库中的 主键 ，数据库上会建立聚集索引 （ cluster index），即在物理存储上以这个字段排序。 这个记录标识上的查询，往往又有分页或者排序的业务需求 ，例如： 拉取最新的一页消息 select message-id/ order by time/ limit 100 拉取最新的一页订单 select order-id/ order by time/ limit 100 拉取最新的一页帖子 select tiezi-id/ order by time/ limit 100 所以往往要有一个 time字段，并且在 time字段上建立普通索引 （ non- cluster index）。 普通索引存储的是实际记录的指针，其访问效率会比聚集索引慢，如果 记录标识在生成时能够基本按照时间有序，则可以省去这个 time字段的 索引查询： select message-id/ (order by message-id)/limit 100 强调，能这么做的前提是， message-id的生成基本是 趋势时间递增的 。 这就引出了记录标识生成（也就是上文提到的三个 XXX-id）的两大核 心需求： 全局唯一 趋势有序 这也是本文要讨论的核心问题： 如何高效生成趋势有序的全局唯一 ID。 二、常见方法、不足与优化 方法一：使用数据库的 auto_increment 来生成全局唯一递增 ID 优点： 简单，使用数据库已有的功能 能够保证唯一性 能够保证递增性 步长固定 缺点： 可用性难以保证：数据库常见架构是一主多从 +读写分离，生成自 增 ID是写请求，主库挂了就玩不转了 扩展性差，性能有上限：因为写入是单点，数据库主库的写性能决 定 ID的生成性能上限，并且难以扩展 改进方法： 冗余主库，避免写入单点 数据水平切分，保证各主库生成的 ID不重复 如上图所述，由 1 个写库变成 3 个写库， 每个写库设置不同的 auto_increment 初始值，以及相同的增长步长 ，以保证每个数据库生 成的 ID 是不同的（上图中库 0 生成 0,3,6,9… ，库 1 生成 1,4,7,10 ，库 2 2,5,8,11… ） 改进后的架构保证了可用性，但缺点 是： 丧失了 ID 生成的“绝对递增性” ：先访问库 0 生成 0,3 ，再访问库 1 成 1 ......