分布式唯一Id(雪花算法):原理+对比+方案

本文探讨了在高并发场景下如何保证分布式系统中的全局唯一ID生成,介绍了分布式唯一ID的需求背景,重点分析了UUID和数据库自增ID的不足,进而详细讲解了Twitter的SnowFlake算法,包括其组成、优缺点,以及为何雪花ID能提供有序且唯一的ID。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

集群高并发情况下如何保证分布式唯一全局Id生成

为什么需要分布式全局唯一Id,以及分布式Id的业务需求

在复杂分布式系统中,往往需要对大量的数据和消息进行唯一标识。

如在美团点评的金融、支付、餐饮、酒店;猫眼电影等产品的系统中数据日渐增长,对数据分库分表后需要有一个唯一Id来标识一条数据或消息;特别一点的如订单、骑手、优惠券也都需要有唯一Id坐标时。

此时一个能够生成全局唯一Id的系统是非常必要的

Id生成规则部分硬性要求

  1. 全局唯一;
  2. 趋势递增:在Mysql的InnoDB引擎中使用的是聚集索引,由于多数RDBMS使用Btree的数据结构来存储索引数据,在主键的选择上面我们应该尽量使用有序的主键来保证写入性能;
  3. 单调递增:尽量保证下一个Id一定大于上一个Id,例如事务版本号、IM增量消息、排序等特殊需求;
  4. 信息安全:如果Id是连续的,恶意用户的扒取工作就非常容易做了,直接按照顺序下载指定URL即可;如果是订单号就更危险了,竞对可以直接知道我们一天的单量.所以在一些应用场景下,需要Id无规则不规则,让竞争对手不好猜;
  5. 含时间戳:这样就能够在开发中快速了解这个分布式Id的生成时间。

Id生成系统的可用性要求

  • 高可用:发一个获取分布式Id的请求,服务器就要保证99.999%的情况下给我创建一个唯一分布式Id;
  • 低延迟:发一个获取分布式Id的请求,服务器要快,极速;
  • 高QPS:例如并发一口气10万个创建分布式Id请求同时杀过来,服务器要顶得住且一下子成功创建10万个分布式Id。

一般通用方案

  • UUID:UUID(Univesally Unique Identifler)的标准型包含32个16进制数字,以连字号分为五段,形式为8-4-4-4-12的36个字符
    • 性能非常高: 本地生成,没有网络消耗;
    • 如果只是考虑唯一性:OK,关键是他无序,入数据库性能比较差。

为什么无序的UUID会导致入库性能变差呢?

  1. 无序,无法预测他的生成顺序,不能生成递增有序的数字。首先分布式Id一般都会作为主键,但是按照mysql官方推荐的主键尽量越短越好,UUID每一个都很长,所以不是很推荐;
  2. 主键,ID作为主键时在特定的环境会存在一些问题。比如做DB主键的场景下,UUID就非常不适用MySQL官方有明确的建议主键尽量越短越好36个字符长度的UUID不符合要求;
  3. 索引,B+树索引的分裂
  4. 既然分布式Id是主键,然后主键是包含索引的,然后mysql的索引是通过B+树来实现的,每一次新的UUID数据的插入,为了查询的优化,都会对索引底层的B+树进行修改,因为UUID是无序的,所以每一次UUID数据的插入都会对主键地城的B+树进行很大的修改,这一点很不好.插入完全无序,不但会导致一些中间节点产生分裂,也会白白创造出很多不饱和的节点,这样大大降低了数据库插入的性能。
  • 数据库自增主键(小公司)
    • 在分布式里面,数据库的自增Id机制的主要原理是:数据库自增Id和mysql数据库的replace into实现的,这里的replace into跟insert功能类似;
    • 不同点在于: replace into首先尝试插入数据列表中,如果发现表中已经有此行数据(根据主键或唯一索引判断)则先删除,再插入,否则直接插入新数据。

REPLACE INTO 的含义是插入一条记录,如果表中唯一索引的值遇到冲突,则替换老数据

那数据库自增ID机制适合做分布式ID吗?答案是不太合适

  1. 系统水平扩展比较困难,比如定义好了步长和机器台数之后,如果要添加机器该怎么做?假设现在只有一台机器发号是1.2.3.4.5(步长是1),这个时候需要扩容机器一台.可以这样做;把第二台机器的初始值设置的比第一台超过很多,貌似还好,现在想象一下如果我们线上有100台机器,这个时候要扩容该怎么做?简直是噩梦.所以系统水平扩展方案复杂难以实现;
  2. 数据库压力还是很大,每次获取ID都得读写一次数据库,非常影响性能,不符合分布式ID里面的延迟低和高QPS的规则(在高并发下,如果都去数据库里面获取ID,那是非常影响性能的)。
  • Redis生成全局Id策略(部署麻烦)

因为Redis是单线的天生保证原子性,可以使用原子操作INCR和INCRBY来实现。

注意: 在Redis集群情况下,同样和Mysql一样需要设置不同的增长步长,同时key一定要设置有效期。

可以使用Redis集群来获取更高的吞吐量。

综上分析:那么问题就来了,自增id会担心主键重复,UUID不能保证有序性,有没有一种ID既是有序的,又是唯一的呢?当然有,就是雪花ID。

雪花ID算法

Twitter的分布式自增Id算法snowflake

最初Twitter把存储系统从Mysql迁移到Cassandra(由Facebook开发一套开源分布式NoSQL数据库系统)因为Cassandra没有顺序ID生成机制,所以开发了一套全局唯一ID生成服务。

Twitter的分布式雪花算法SnowFlake,经测试每秒能够产生26万个自增可排序ID。

  1. twitter的SnowFlake生成ID能够按照时间有序生成;

  2. SnowFlake算法生成id的结果是一个64bit大小的整数,为一个Long型(转换成字符串后长度为19);

  3. 分布式系统内不会产生ID碰撞(由datacenter和workerId作区分)并且效率较高。

雪花ID算法组成

在这里插入图片描述

  • 时间范围: 2 41 2^{41} 241 / (365*24*60*60*1000L) = 67.73年
  • 工作进程: 2 10 2^{10} 210 = 1024
  • 生成不碰撞序列的TPS: 2 10 2^{10} 210*1000=409.6万

号段解析

  • 1bit: 不用,因为二进制中最高位是符号位,1表示负数,0表示正数,生成的id一般都是用整数,所以最高位固定为0;
  • 41bit-时间戳: 用来记录时间戳,毫秒级;
  • 10bit-机器码: 用来记录工作机器的id,最大值为1023;
  • 2bit-序列号: 用来记录同一毫秒内产生的不同id,最大值为4095。

SnowFlake可以保证: 所有生成的id按时间趋势递增,整个分布式系统内不会产生重复id。

雪花ID的优缺点

优点

  • 毫秒数在高位,自增序列在低位,整个ID都是趋势递增的.不依赖数据库等第三方系统,以服务的方式部署,稳定性更高,生成的Id的性能也是非常高的.可以根据自身业务特性分配bit位,非常灵活。

缺点

  • 依赖机器时钟,如果机器时钟回拨,会导致重复ID生成.在单机上是递增的,但是由于设计到分布式环境,每台机器上的时钟不可能完全同步,有时候会出现不是全局递增的情况(此缺点可以认为无所谓,一般分布式id只要求趋势递增,而不会严格要求递增,90%的需求都只要求趋势递增)!
<think>嗯,用户让我介绍一下雪花算法生成唯一的UID。首先,我需要回忆一下雪花算法的基本结构。Snowflake是Twitter开源的分布式ID生成算法,对吧?它生成的是64位的唯一ID,通常用于分布式系统中确保ID唯一性。 用户可能是在准备面试,或者是想了解分布式ID生成机制。之前他们问过Spring Bean的生命周期,现在转向雪花算法,可能是想扩展对系统设计的理解。需要确保回答清晰,结构合理,覆盖关键点。 首先,我应该解释雪花算法的组成部分。64位的ID通常分为几个部分:时间戳、工作机器ID、序列号。具体每个部分占多少位呢?比如,时间戳一般是41位,工作机器ID包括数据中心ID和机器ID,各占5位,剩下的12位是序列号。不过不同的实现可能有调整,比如百度的UidGenerator可能调整了位数分配。 接下来,需要说明每个部分的作用。时间戳保证有序性,工作机器ID确保不同节点生成不同的ID,序列号处理同一节点同一毫秒的并发。还要提到时间回拨的问题,如何处理这种情况,比如等待或抛出异常。 然后,要讨论雪花算法的优点,比如高性能、低延迟、趋势递增,这对数据库索引友好。缺点的话,时钟回拨可能是个问题,而且工作机器ID需要手动配置,可能不适合动态扩缩容的场景。 用户可能需要知道实际应用中的例子,比如在分布式系统、订单ID生成中的应用。还可以对比其他分布式ID生成方案,比如UUID、数据库自增、Redis生成等,说明雪花算法的优势。 需要确保回答结构清晰,分点说明,可能用列表或分段来组织内容。还要注意使用中文,避免技术术语过多,但也要准确。如果有必要,可以提到改进方案,比如美团Leaf、百度UidGenerator,这样用户知道有优化的变种存在。 最后,检查是否有遗漏的关键点,比如生成ID长度、是否可能重复、高并发下的表现,以及如何配置工作机器ID。确保回答全面,覆盖用户可能关心的各个方面。</think>--- ### **雪花算法(Snowflake)核心原理** 雪花算法是Twitter开源的分布式唯一ID生成方案生成ID为**64位整数**,结构清晰且满足分布式系统的高并发、唯一性需求。 --- ### **ID结构分解(64位)** | 组成部分 | 位数 | 作用说明 | |--------------|-------|---------------------------------| | **符号位** | 1位 | 固定为0(保证ID为正整数) | | **时间戳** | 41位 | 记录当前时间与起始时间的差值(毫秒级)| | **工作机器ID**| 10位 | 支持最多$2^{10}=1024$个节点 | | **序列号** | 12位 | 单节点同一毫秒内的自增序号(支持$2^{12}=4096$/ms)| --- ### **工作流程** 1. **时间戳生成** - 使用当前时间减去预设的起始时间(如:2020-01-01),转化为毫秒值,占据高41位 - ✅ 优势:ID随时间递增,利于数据库索引优化 2. **工作机器ID分配** - 通过配置文件或服务注册中心分配唯一机器ID(如:5位数据中心ID + 5位机器ID) - ⚠️ 注意:需避免手动配置冲突(动态扩缩容场景需结合ZooKeeper等协调工具) 3. **序列号管理** - 同一机器同一毫秒内,通过自增序列号生成不同ID - 若当前毫秒序列号耗尽,则阻塞至下一毫秒 --- ### **核心优势** - **高性能**:单机每秒可生成约$409.6$万ID(理论值) - **趋势递增**:利于数据库B+树索引插入 - **去中心化**:无需依赖第三方服务(如数据库、Redis) --- ### **关键问题与解决方案** | 问题 | 解决方案 | |---------------------|---------------------------------------------| | **时钟回拨** | 1. 短暂回拨:等待时钟同步<br>2. 严重回拨:抛出异常 | | **机器ID耗尽** | 拆分位数(如:数据中心ID扩展至7位,机器ID缩至3位) | | **跨毫秒序列重置** | 毫秒变化时序列号归零 | --- ### **改进方案(工业级应用)** 1. **美团Leaf**:优化时钟回拨容忍度 2. **百度UidGenerator**:采用环形缓冲区预生成ID 3. **自定义调整位数**:根据业务需求调整时间戳/机器ID/序列号的占比 --- ### **代码逻辑示例(伪代码)** ```java public class Snowflake { private long lastTimestamp = -1L; private long sequence = 0L; public synchronized long nextId() { long currentTimestamp = getCurrentTimestamp(); if (currentTimestamp < lastTimestamp) { throw new ClockMovedBackException(); } if (currentTimestamp == lastTimestamp) { sequence = (sequence + 1) & MAX_SEQUENCE; if (sequence == 0) { // 当前毫秒序列号耗尽 currentTimestamp = waitNextMillis(lastTimestamp); } } else { sequence = 0L; } lastTimestamp = currentTimestamp; return (currentTimestamp << TIMESTAMP_SHIFT) | (machineId << MACHINE_SHIFT) | sequence; } } ``` --- ### **适用场景** - 分布式系统主键生成(如订单ID、用户ID) - 日志追踪唯一标识 - 高并发写入的数据库分库分表 --- ### **面试回答要点** "雪花算法通过时间戳、机器ID和序列号生成全局唯一ID,兼具有序性和高性能。核心需注意时钟回拨的容错处理,以及机器ID的分配策略。实际应用中需结合业务调整位数分配,或采用改进方案(如Leaf)提升稳定性。"
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值