漫谈分布式唯一ID

文章目录

  • 本系列
  • 前言
  • UUID
  • DB自增主键
  • Redis incr命令
  • 号段模式
  • 雪花算法

本系列

  • 漫谈分布式唯一ID(本文)
  • 分布式唯一ID生成(二):leaf
  • 分布式唯一ID生成(三):uid-generator
  • 分布式唯一ID生成(四):tinyid

前言

在大多数业务场景中,需要对每条数据分配一个唯一ID作为标识。大部分关系型数据库提供了自增主键功能来支持该需求

但若数据量较大,需要分库分表时,就不能使用每个数据库实例提供的自增键功能,因为不能保证在所有表中唯一,分布式全局唯一ID的需求应运而生

分布式唯一ID有以下功能需求:

  1. 全局唯一性:在某个业务场景下唯一,避免数据冲突,这是最基本的要求
  2. 高性能:生成速度快,不能阻塞业务流程
  3. 趋势递增:通常会将该ID作为数据库主键,由于mysql innoDB采用聚集索引,若新增的记录主键无序,可能造成 叶分裂空间利用率不高 的问题,降低写入性能
  4. 严格单调递增:适用于需要这种特性的场景,例如IM场景中需要根据此生成消息ID,用于给消息排序,并判断是否有消息丢失
  5. 安全性:防止泄露业务信息,若生成的ID严格递增,在电商场景可根据一段时间的id差算出订单量
  6. 方便追踪:例如在ID融入时间戳,就能知道是什么时间范围生成的

上述4,5需求是互斥的,无法同时满足。不同业务场景根据需求选择

还有一些非功能需求:

  1. 高可用:可用性至少5个9

  2. 低延迟:生成速度一定要快,TP50和TP99.9都要非常快,不能因为这个导致业务接口响应变慢

  3. 高并发:假如一下来10w个生成分布式 ID 的请求,要能扛得住

接下来介绍一些常见的分布式ID生成方案


UUID

UUID(Universally unique identifier)一般包含32个十六进制的字符,128位,通过一定的算法计算出来,通常基于时间戳,mac地址,随机数等

优点为:

  • 性能好:本地生成,无网络消耗
  • 唯一性:可以认为不会发生冲突

某些版本基于命名空间能保证唯一性,某些版本基于随机数生成,不保证唯一性,但出现相同UUID的概率非常小,根据百度百科的说法,以java.util.UUID为例,每秒产生10亿笔UUID,100年后只产生一次重复的几率是50%

缺点:

  • 没有趋势递增特性:作为数据库主键时插入性能不高,会导致叶分裂
  • 数据较宽:通常UUID为128bit,不能用mysql的bigint存储,需使用字符串类型,对性能有一定影响
  • 信息不安全:基于mac生成的uuid可能造成mac地址泄露

应用:生成traceId或logId


DB自增主键

以mysql为例,我们可以专门建一张表,利用其自增键来生成唯一ID

表结构如下:

CREATE TABLE unique_id (id bigint(20) unsigned NOT NULL auto_increment, value char(20) NOT NULL default '',PRIMARY KEY (id),UNIQUE KEY unique_v(value) 
) ENGINE=MyISAM;

使用以下sql获取id

begin; 
replace into unique_id (value) VALUES ('placeword'); 
select last_insert_id(); 
commit;

这里 使用replace而不是insert ,是为了保证整个表只有一条记录,因为不需要多余的记录也能生成自增id

这种方式利用数据库的自增主键保证生成id的唯一性,严格单调递增。缺点为:

  1. 性能问题:每次生成id需要一次数据库远程IO,发号器的瓶颈取决于db的读写性能
  2. 可用性问题:只用到一台db实例,存在单点问题,可用性没有保障

针对上面两个问题,可以引入多台mysql:每台实例的表使用不同的初始值

以2台mysql实例为例,分别做如下配置:

mysql1:

set @@auto_increment_offset = 1; -- 起始值 set @@auto_increment_increment = 2; -- 步长

mysql2:

set @@auto_increment_offset = 2; -- 起始值 set @@auto_increment_increment = 2; -- 步长

mysql1从 1 开始发号,mysql2从 2 开始发号,每次发号后递增2
这样mysql1生成的id序列为:

1,3,5,7,9....

mysql2为:

2,4,6,8....

当请求到来时,采用随机或轮询的方式请求这些实例,这样得到的id序列总体为趋势递增,既减少了单台实例的访问压力,也提高了可用性。缺点为:

  1. 从单调递增变为趋势递增
  2. 性能问题: 每次生成ID还是有一次远程数据库IO,对DB的压力还是大
  3. 伸缩性问题:当需要扩展更多的机器时,需要调整之前所有实例的步长,且需要保证再次期间生成ID不冲突,实现起来较麻烦

Redis incr命令

为了解决数据库自增键遇到的性能问题,可以利用 redis的incr 命令来生成不重复的递增ID。该策略相较于数据库方案,优点为:

  1. 从远程磁盘IO变为为远程内存IO性能有一定提升,毕竟redis号称10w qps

但为了保证唯一性需要费一番功夫,依次讨论redis的各种持久化策略:

  • 不开启 redis 持久化,则redis宕机后会丢失已生成的ID,再生成会导致ID重复
  • 开启 RDBAOF 中非AOF_FSYNC_ALWAYS模式的持久化,可能丢失最近一段时间的ID,一样会出现ID重复
  • 开启 AOF 中AOF_FSYNC_ALWAYS模式的持久化,能保证即使在宕机的情况下也不会出现ID重复,但性能会下降,相较于数据库方案没有太大的优势

号段模式

号段模式是为了解决数据库自增主键和redis incr方案中,每次获取ID都需要远程请求的问题

即每次从db获取一个ID范围,作为一个号段加载到内存,这样生成唯一ID时不需要每次都从数据库获取,而是从本地内存里获取,大大提高性能。本地缓存的号段用完时才请求db获取下一批号段

以mysql为例,数据库表结构如下:

CREATE TABLE unique_id ( id bigint(20) NOT NULL, max_id bigint(20) NOT NULL COMMENT '下个号段从哪开始分配', step int(10) NOT NULL COMMENT '一批ID的数量', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT

每次获取一个号段时,执行如下sql:

update unique_id set max_id = {max_id} + step  where max_id = {max_id} 

当执行成功后判断 affectRows等于1,就能保证只有当前实例获得了 [max_id,max_id + step) 这个区间的号段,就能愉快地在内存发号了

若affectRows不等于1,说明有其他实例获取了这个号段,需要重试再次获取

号段模式的优点如下:

  1. 性能很高:大部分情况下直接在内存发号,无需远程请求,号段范围越大,远程请求的比例越低
  2. 可用性较高:若数据库宕机,可以使用之前获取的号段进行发号,号段范围越大,能撑的时间越久
  3. 趋势递增

缺点如下:

  1. 号段浪费:若某实例在号段没用完时就重启或宕机,则其号段剩余的ID就浪费了。解决方案为较小号段长度,但根据优点中的描述,这会降低性能和可用性,因此需要选择一个适中的号段长度

  2. 不够平滑:当号段用完时,会请求一次数据库,如果此时网络抖动,会使得该次请求响应较慢

    1. 为了解决这种情况,可以在号段即将用完时就异步请求数据库获取下一个号段,而不是等到要用完再请求
  3. 可用性问题:和数据库自增键策略一样的单点问题


如何解决上面提到的可用性问题呢?使用多台实例。这里还是以2台实例为例进行说明:

每次生获取完号段后,将max_id增加 号段长度 * 实例数量

例如初始化时,mysql1.max_id=0,mysql2.max_id=1000。step都是1000

  • 第一次访问mysql1,获取[0:1000)的号段,将mysql1.max_id更新成2000
  • 第二次访问mysql2,获取[1000:2000)的号段,将mysql2.max_id更新成3000
  • 第三次访问mysql1,获取[2000:3000)的号段,将mysql1.max_id更新成4000
  • 第四次访问mysql2,获取[3000:4000)的号段,将mysql2.max_id更新成5000

这样既降低了单台数据库实例的访问压力,又提高了可用性

buffer数量设为多大?峰值qps的600倍,这样db宕机还能提供至少10分钟的服务(容灾性高)


优点:

  1. id位64bit的数字趋势递增
  2. 对db的压力小
  3. 可以很方便线性扩展:按照bizkey分库分表即可
  4. 高可用:内部有缓存,如果数量为峰值qps的600倍,那么db宕机10分钟内都可用
  5. id可以做到几乎单调递增
  6. 可自定义maxId大小,方便原有业务迁移

缺点:

  1. TP999波动大:其他时候查本地缓存,但当号段用完时要查读写一次db
    1. 解决:双buffer,例如当第一个buffer用到10%时就异步请求第二个buffer的号段
  2. id不够随机,泄露发号数量

雪花算法

雪花算法使用一个64位的数字来表示唯一ID,而这64位中的每一位怎么用,就是其精髓所在

标准的雪花算法每一位含义如下:

在这里插入图片描述

  • [0:0] 1位符号位:ID一般为正数,所以该位为0
  • [1:41] 41位时间:通常用来表示 当前时间 - 业务开始时间 的时间差,而不是相对于1970年的时间戳,这样能支持的时间更久,若41位时间戳的单位为毫秒,则能支持大约(1 << 41) / (1000 * 60 * 60 * 24 * 365) = 69年
  • [42:51] 10位机器:一般机器数没那么多,可以将 10位中分5位给机房,分5位给机器。这样就可以表示32个机房,每个机房下可以有32台机器
  • [52:63] 12位自增序列号:表示某台机器上在某一毫秒(如果表示时间的单位为毫秒)内的生成的ID序列号,每毫秒支持1<<12 = 4096个ID,按照 qps算有409.6万

位的分配可以根据业务的不同进行调整,例如若机器数没那么多,不需要10位表示,可增大时间位,以支持更长的时间范围。或者业务并发量不高时,可将时间单位改为秒,将节省出来的位用于表示其他含义

只要每个实例的机器ID不同,则不同机器间生成的ID一定不同,因为其[42:51]位不一样

这样划分后,在一毫秒内一个数据中心的一台机器上可以产生4096个的不重复的ID

其优点为:

  1. 不依赖数据库,性能和可用性非常好
  2. 如果时间戳在高位,能保证ID趋势递增
  3. 理论上支持超高的并发,因为qps有409万,基本不可能有业务的写操作能达到这个qps

缺点为:

  1. ID的生成强依赖于服务器时钟,如果发生时钟回拨,则可能和以前生成过的ID产生冲突

时钟回拨:硬件时钟可能会因为各种原因发生不准的情况,网络中提供了ntp服务来做时间校准,做校准的时候就会发生时钟的跳跃或者回拨的问题

  1. 10位的机器号较难指定,最好不要手工指定,而是实例去自动获取

针对时钟回拨问题,可分两种情况讨论:
  • 实例运行过程中发生时钟回拨:此时可以在内存中 记录上次时间戳,若这次获取的时间戳比上次小,说明发生了时钟回拨,可以等待一段时间再进行ID生成,若回拨幅度较大,则可选择继续等待,或给上层报错,因为在短时间内无法生成正确的ID

也可以完全不依赖系统时间,例如百度的uid-generator使用一个原子变量,每次加一来生成下一个时间

  • 实例重启过程中发生时钟回拨:此时没办法从内存中获取上次的时间戳,因此需要将上次时间戳放到外部存储中。美团leaf的方案为,每3s往zookeeper上报一次当前时间戳,这样在实例重启时,也能判断出是否发生了时钟回拨

但存在外部不能完全避免时钟回拨,例如在t时刻将t保存在zk,在 t+1 时刻分配了一个ID,在 t+2 时刻宕机,时钟回退了1s到t+1,此时检测 t+1 > zk 中的时间t,没问题。但依然会产生 t+1 时刻的重复ID

因此最保险的办法是:宕机后sleep一段时间再重启,这段时间要超过时钟回退的时间


针对机器号生成困难问题:有以下几种解决方案:
  • 使用zookeeper:每次实例启动时,都去zookeeper下创建一个节点,利用其节点编号当做机器id,zookeeper保证每次生成的节点编号唯一

  • 使用mysql:也可以在实例启动时,去数据库的表插入一条记录,利用自增主键当做机器ID,同样能保证机器ID的唯一性

适用场景:订单中,不想让别人根据早上和晚上的订单id号猜到销量的场景

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.rhkb.cn/news/468485.html

如若内容造成侵权/违法违规/事实不符,请联系长河编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

C语言:文件操作2(又一万字?)

关于文件操作这章内容&#xff0c;因为知道内容较多所以我分两篇发了&#xff0c;但是还是没料到第二篇还是这么多&#xff0c;达到了一万多字&#xff01;&#xff01;&#xff01;作者本人真的将知识点进行了超级详解分析并且举了很多例子来帮助读者理解&#xff0c;本文章较…

STM32标准库-待机模式

1.1 STM32待机模式简介 STM32单片机具有低功耗模式&#xff0c;包括睡眠、停止和待机三种。 运行状态下&#xff0c;HCLK为CPU提供时钟。HCLK由AHB预分频器分频后直接输出得到。 低功耗模式选择需考虑电源消耗、启动时间和唤醒源。 睡眠模式停CPU不停外设时钟&#xff1b; 停止…

C++内存分区

内存分区 C程序在执行时&#xff0c;将内存大方向划分为4个区域 代码区&#xff1a;存放函数体的二进制代码&#xff0c;由操作系统进行管理的 全局区&#xff1a;存放全局变量和静态变量以及常量&#xff08;不包括局部常量&#xff09; 栈区&#xff1a;由编译器自动分配释…

大数据面试题--kafka夺命连环问

1、kafka消息发送的流程&#xff1f; 在消息发送过程中涉及到两个线程&#xff1a;一个是 main 线程和一个 sender 线程。在 main 线程中创建了一个双端队列 RecordAccumulator。main 线程将消息发送给双端队列&#xff0c;sender 线程不断从双端队列 RecordAccumulator 中拉取…

ElasticSearch备考 -- 集群配置常见问题

一、集群开启xpack安全配置后无法启动 在配置文件中增加 xpack.security.enabled: true 后无法启动&#xff0c;日志中提示如下 Transport SSL must be enabled if security is enabled. Please set [xpack.security.transport.ssl.enabled] to [true] or disable security b…

LeetCode:485.最大连续1的个数——简单题简单做

目录 题目——485.最大连续1的个数 题目分析&#xff1a; 图解如下&#xff1a; 代码如下 题目——485.最大连续1的个数 给定一个二进制数组 nums &#xff0c; 计算其中最大连续 1 的个数。 示例 1&#xff1a; 输入&#xff1a;nums [1,1,0,1,1,1] 输出&#xff1a;3 解…

如何在Android中自定义property

在Android中创建自定义的属性&#xff08;Android property&#xff09;通常用于调试、性能调优或传递应用和系统之间的信息。 以下是如何在Android中创建和使用自定义属性的步骤&#xff1a; 1. 定义属性 在Android中&#xff0c;属性是以“属性名称属性值”形式定义的键值对…

web——sqliabs靶场——第二关

今天来搞第二关&#xff0c;来看看是什么咸蛋 1.判断是否存在sql注入漏洞 输入1 存在sql注入&#xff0c;报错语句为 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near LIMIT 0,1 …

时序预测 | Python基于CNN-transformer时间序列预测

时序预测 | Python基于CNN-transformer时间序列预测 目录 时序预测 | Python基于CNN-transformer时间序列预测预测效果基本介绍参考资料 预测效果 基本介绍 时序预测 | Python基于CNN-transformer时间序列预测 Cnn-transformer-自适应稀疏自注意力ASSA-对比归一化contranorm预…

windows中docker安装redis和redisinsight记录

创建一个Redis运行容器&#xff0c;命令如下 docker run -it -d --name redis -p 6379:6379 redis --bind 0.0.0.0 --protected-mode no -d 代表Redis容器后台运行 --name redis 给创建好的容器起名叫redis -p 6379:6379 将容器的6379端口映射到宿主机的6379端口&#xff0c;注…

ClickHouse创建账号和连接测试

在之前搭建ClickHouse的时候&#xff0c;把账户相关的去掉了&#xff0c;所以登录和连接的时候是不需要账号密码的&#xff0c;但是实际项目中&#xff0c;肯定是需要根据需要创建账号。 一&#xff0c;创建账号 1&#xff0c;进入到 /etc/clickhouse-server&#xff0c; 编辑…

基于微信小程序实现个人健康管理系统

作者主页&#xff1a;编程千纸鹤 作者简介&#xff1a;Java领域优质创作者、CSDN博客专家 、CSDN内容合伙人、掘金特邀作者、阿里云博客专家、51CTO特邀作者、多年架构师设计经验、多年校企合作经验&#xff0c;被多个学校常年聘为校外企业导师&#xff0c;指导学生毕业设计并参…

基于python的天气数据采集与可视化分析,对20个城市的天气适宜出行度分析

摘要 本项目旨在基于Python对20个城市的天气数据进行采集与可视化分析&#xff0c;以评估天气的适宜出行度。该分析通过四个主要指标进行量化&#xff0c;这些指标分别是天气状况良好率、空气质量优良率、气温适宜率和安全天气率。通过这些指标&#xff0c;我们能够有效地判断…

YOLOv11实战宠物狗分类

本文采用YOLOv11作为核心算法框架&#xff0c;结合PyQt5构建用户界面&#xff0c;使用Python3进行开发。YOLOv11以其高效的特征提取能力&#xff0c;在多个图像分类任务中展现出卓越性能。本研究针对5种宠物狗数据集进行训练和优化&#xff0c;该数据集包含丰富的宠物狗图像样本…

电信网关配置管理系统 upload_channels.php 文件上传致RCE漏洞复现

0x01 产品简介 中国电信集团有限公司(英文名称“China Telecom”、简称“中国电信”)成立于2000年9月,是中国特大型国有通信企业、上海世博会全球合作伙伴。电信网关配置管理系统是一个用于管理和配置电信网络中网关设备的软件系统。它可以帮助网络管理员实现对网关设备的远…

Halcon LED灯带检测分享

目录 原图 检出图 示例代码 函数说明 代码 原图 检出图 示例代码 函数说明 LEDSensitivity : 0.6 LEDMinSize : 35 LEDMaxSize : 400 LEDMethod : 1 LEDType :1 LED (Image, LEDDefectTrans, LEDSensitivity, LEDMethod, LEDType, LEDMinSize, LEDMaxSize, R, G, B,…

Pytest-Bdd-Playwright 系列教程(7):使用测试代码生成辅助工具

Pytest-Bdd-Playwright 系列教程&#xff08;7&#xff09;&#xff1a;测试代码生成辅助工具的使用 前言一、代码生成辅助工具的设计思路1.1 功能概览1.2 适用人群 二、如何使用 pytest-bdd 代码生成器三、代码生成器的实际应用场景3.1 初学者的学习和实践3.2 大规模功能测试3…

【每日刷题】Day152

【每日刷题】Day152 &#x1f955;个人主页&#xff1a;开敲&#x1f349; &#x1f525;所属专栏&#xff1a;每日刷题&#x1f34d; &#x1f33c;文章目录&#x1f33c; 1. LCR 176. 判断是否为平衡二叉树 - 力扣&#xff08;LeetCode&#xff09; 2. 最大子矩阵_牛客题霸…

【Linux】vmlinux、vmlinuz、zImage、bzImage 的区别

vmlinux vmlinux 是静态链接的可执行文件&#xff0c;但是无法直接加载启动&#xff0c;并且是非压缩的。 zImage and bzImage zImage 和 bzImage 都是 linux 的镜像&#xff08;image &#xff09;&#xff0c;前者用于老系统&#xff0c;后者用于新系统&#xff0c;都采用了…

MaxK B:基于 LLM 大语言模型的知识库问答系统!

推荐一个基于大模型的企业级知识库问答系统&#xff0c;支持管理企业知识库、对话问答、RAG 等功能。 企业知识管理的智能化革新在数字化时代&#xff0c;知识管理对于企业的重要性不言而喻。 MaxK B是一个基于 LLM 大语言模型的知识库问答系统&#xff0c;正是为了解决这一挑…