9种分布式ID⽣成⽅案，让你⼀次学个够
⼀、为什么要⽤分布式ID？
在说分布式ID的具体实现之前，我们来简单分析⼀下为什么⽤分布式ID？分布式ID应该满⾜哪些特征？
1、什么是分布式ID？
拿MySQL数据库举个栗⼦：
在我们业务数据量不⼤的时候，单库单表完全可以⽀撑现有业务，数据再⼤⼀点搞个MySQL主从同步读写分离也能对付。
但随着数据⽇渐增长，主从同步也扛不住了，就需要对数据库进⾏分库分表，但分库分表后需要有⼀个唯⼀ID来标识⼀条数据，数据库的⾃增ID 显然不能满⾜需求；特别⼀点的如订单、优惠券也都需要有唯⼀ID做标识。此时⼀个能够⽣成全局唯⼀ID的系统是⾮常必要的。那么这个全局唯⼀ID就叫分布式ID。
2、那么分布式ID需要满⾜哪些条件？
全局唯⼀：必须保证ID是全局性唯⼀的，基本要求
⾼性能：⾼可⽤低延时，ID⽣成响应要快，否则反倒会成为业务瓶颈
⾼可⽤：100%的可⽤性是骗⼈的，但是也要⽆限接近于100%的可⽤性
好接⼊：要秉着拿来即⽤的设计原则，在系统设计和实现上要尽可能的简单
趋势递增：最好趋势递增，这个要求就得看具体业务场景了，⼀般不严格要求
⼆、 分布式ID都有哪些⽣成⽅式？
今天主要分析⼀下以下9种，分布式ID⽣成器⽅式以及优缺点：
UUID
数据库⾃增ID
数据库多主模式
号段模式
Redis
雪花算法（SnowFlake）
滴滴出品（TinyID）
百度 （Uidgenerator）
美团（Leaf）
那么它们都是如何实现？以及各⾃有什么优缺点？我们往下看
以上图⽚源⾃⽹络，如有侵权联系删除
1、基于UUID
在Java的世界⾥，想要得到⼀个具有唯⼀性的ID，⾸先被想到可能就是UUID，毕竟它有着全球唯⼀的特性。那么UUID可以做分布式ID吗？答案
答案是可以的，但是并不推荐！
publicstaticvoidmain(String[] args){        String uuid = UUID.randomUUID().toString().replaceAll("-","");
System.out.println(uuid); }
UUID的⽣成简单到只有⼀⾏代码，输出结果
c2b8c2b9e46c47e3b30dca3b0d447718，但UUID却并不适⽤于实际的业务需求。像⽤作订单号UUID这样的字符串没有丝毫的意义，看不出和订单相关的有⽤信息；⽽对于数据库来说⽤作业务主键ID，它不仅是太长还是字符串，存储性能差查询也很耗时，所以不推荐⽤作分布式ID。
优点：
⽣成⾜够简单，本地⽣成⽆⽹络消耗，具有唯⼀性
缺点：
⽆序的字符串，不具备趋势⾃增特性
没有具体的业务含义
长度过长16 字节128位，36位长度的字符串，存储以及查询对MySQL的性能消耗较⼤，MySQL官⽅明确建议主键要尽量越短越好，作为数据库主键 UUID 的⽆序性会导致数据位置频繁变动，严重影响性能。
2、基于数据库⾃增ID
基于数据库的auto_increment⾃增ID完全可以充当分布式ID，具体实现：需要⼀个单独的MySQL实例⽤来⽣成ID，建表结构如下：CREATEDATABASE`SEQ_ID`;CREATETABLESEQID.SEQUENCE_ID
(idbigint(20)unsignedNOTNULLauto_increment,valuechar(10)NOTNULLdefault'',    PRIMARYKEY(id),)ENGINE=MyISAM; insertintoSEQUENCE_ID(value)VALUES('values');
当我们需要⼀个ID的时候，向表中插⼊⼀条记录返回主键ID，但这种⽅式有⼀个⽐较致命的缺点，访问量激增时MySQL本⾝就是系统的瓶颈，⽤它来实现分布式服务风险⽐较⼤，不推荐！
优点：
实现简单，ID单调⾃增，数值类型查询速度快
缺点：
DB单点存在宕机风险，⽆法扛住⾼并发场景
3、基于数据库集模式
前边说了单点数据库⽅式不可取，那对上边的⽅式做⼀些⾼可⽤优化，换成主从模式集。害怕⼀个主节点挂掉没法⽤，那就做双主模式集，也就是两个Mysql实例都能单独的⽣产⾃增ID。
会⽣成重复的ID怎么办？
那这样还会有个问题，两个MySQL实例的⾃增ID都从1开始，会⽣成重复的ID怎么办？
解决⽅案：设置起始值和⾃增步长
解决⽅案
MySQL_1 配置：
set@@auto_increment_offset =1;-- 起始值set@@auto_increment_increment =2;-- 步长
MySQL_2 配置：
set@@auto_increment_offset =2;-- 起始值set@@auto_increment_increment =2;-- 步长
这样两个MySQL实例的⾃增ID分别就是：
1、3、5、7、9
2、4、6、8、10
那如果集后的性能还是扛不住⾼并发咋办？就要进⾏MySQL扩容增加节点，这是⼀个⽐较⿇烦的事。
从上图可以看出，⽔平扩展的数据库集，有利于解决数据库单点压⼒的问题，同时为了ID⽣成特性，将⾃增步长按照机器数量来设置。
增加第三台MySQL实例需要⼈⼯修改⼀、⼆两台MySQL实例的起始值和步长，把第三台机器的ID起始⽣成位置设定在⽐现有最⼤⾃增ID的位置
必要时可能还需远⼀些，但必须在⼀、⼆两台MySQL实例ID还没有增长到第三台MySQL实例的起始ID值的时候，否则⾃增ID就要出现重复了，必要时可能还需要停机修改。
要停机修改
优点：
解决DB单点问题
缺点：
不利于后续扩容，⽽且实际上单个数据库⾃⾝压⼒还是⼤，依旧⽆法满⾜⾼并发场景。
4、基于数据库的号段模式
号段模式是当下分布式ID⽣成器的主流实现⽅式之⼀，号段模式可以理解为从数据库批量的获取⾃增ID，每次从数据库取出⼀个号段范围，例如(1,1000] 代表1000个ID，具体的业务服务将本号段，⽣成1~1000的⾃增ID并加载到内存。表结构如下：
CREATETABLEid_generator (idint(10)NOTNULL,  max_idbigint(20)NOTNULLCOMMENT'当前最⼤id',
stepint(20)NOTNULLCOMMENT'号段的布长',  biz_typeint(20)NOTNULLCOMMENT'业务类型',versionint(20)NOTNULLCOMMENT'版本号',  PRIMARYKEY(`id`))
biz_type ：代表不同业务类型
max_id ：当前最⼤的可⽤id
step ：代表号段的长度
version ：是⼀个乐观锁，每次都更新version，保证并发时数据的正确性
等这批号段ID⽤完，再次向数据库申请新号段，对max_id字段做⼀次update操作，update max_id= max_id + step，update成功则说明新号段获取成功，新的号段范围是(max_id ,max_id +step]。
updateid_generatorsetmax_id =#{max_id+step}, version = version + 1 where version = # {version} and biz_type = XXX
由于多业务端可能同时操作，所以采⽤版本号version乐观锁⽅式更新，这种分布式ID⽣成⽅式不强依赖于数据库，不会频繁的访问数据库，对数据库的压⼒⼩很多。
5、基于Redis模式
Redis也同样可以实现，原理就是利⽤redis的 incr命令实现ID的原⼦性⾃增。
127.0.0.1:6379>setseq_id1//初始化⾃增ID为1OK127.0.0.1:6379>incrseq_id//增加1，并返回递增后的数值(integer)2
⽤redis实现需要注意⼀点，要考虑到redis持久化的问题。redis有两种持久化⽅式RDB和AOF
RDB会定时打⼀个快照进⾏持久化，假如连续⾃增但redis没及时持久化，⽽这会Redis挂掉了，重启Redis后会出现ID重复的情况。AOF会对每条写命令进⾏持久化，即使Redis挂掉了也不会出现ID重复的情况，但由于incr命令的特殊性，会导致Redis重启恢复的数据时间过长。
6、基于雪花算法（Snowflake）模式
雪花算法（Snowflake）是twitter公司内部分布式项⽬采⽤的ID⽣成算法，开源后⼴受国内⼤⼚的好评，在该算法影响下各⼤公司相继开发出各具特⾊的分布式⽣成器。
以上图⽚源⾃⽹络，如有侵权联系删除
Snowflake⽣成的是Long类型的ID，⼀个Long类型占8个字节，每个字节占8⽐特，也就是说⼀个Long类型占64个⽐特。
Snowflake ID组成结构：正数位（占1⽐特）+ 时间戳（占41⽐特）+ 机器ID（占5⽐特）+ 数据中⼼（占5⽐特）+ ⾃增值（占12⽐特），总共64⽐特组成的⼀个Long类型。
第⼀个bit位（1bit）：Java中long的最⾼位是符号位代表正负，正数是0，负数是1，⼀般⽣成ID都为正数，所以默认为0。
时间戳部分（41bit）：毫秒级的时间，不建议存当前时间戳，⽽是⽤（当前时间戳 - 固定开始时间戳）的差值，可以使产⽣的ID从更⼩的值开始；41位的时间戳可以使⽤69年，(1L << 41) / (1000L 60
60 24 365) = 69年
⼯作机器id（10bit）：也被叫做workId，这个可以灵活配置，机房或者机器号组合都可以。
序列号部分（12bit），⾃增值⽀持同⼀毫秒内同⼀个节点可以⽣成4096个ID
根据这个算法的逻辑，只需要将这个算法⽤Java语⾔实现出来，封装为⼀个⼯具⽅法，那么各个业务应⽤可以直接使⽤该⼯具⽅法来获取分布式ID，只需保证每个业务应⽤有⾃⼰的⼯作机器id即可，⽽不需要单独去搭建⼀个获取分布式ID的应⽤。
Java版本的Snowflake算法实现：
/**
mysql删除重复的数据保留一条
* Twitter的SnowFlake算法，使⽤SnowFlake算法⽣成⼀个整数，然后转化为62进制变成⼀个短地址URL
*
*/publicclassSnowFlakeShortUrl{/**
* 起始的时间戳
*/privatefinalstaticlongSTART_TIMESTAMP =1480166465631L;/**
* 每⼀部分占⽤的位数
*/privatefinalstaticlongSEQUENCE_BIT =12;//序列号占⽤的位数privatefinalstaticlongMACHINE_BIT =5;//机器标识占⽤的位数privatefinalstaticlongDATA_CENTER_BIT =5;//数据中⼼占⽤的位数/**
* 每⼀部分的最⼤值
*/privatefinalstaticlongMAX_SEQUENCE =-1L^ (-1L<< SEQUENCE_BIT);privatefinalstaticlongMAX_MACHINE_NUM =-1L^ (-
1L<< MACHINE_BIT);privatefinalstaticlongMAX_DATA_CENTER_NUM =-1L^ (-1L<< DATA_CENTER_BIT);/**
* 每⼀部分向左的位移
*/privatefinalstaticlongMACHINE_LEFT = SEQUENCE_BIT;privatefinalstaticlongDATA_CENTER_LE
FT = SEQUENCE_BIT + MACHINE_BIT;privatefinalstaticlongTIMESTAMP_LEFT = DATA_CENTER_LEFT + DATA_CENTER_BIT;privatelongdataCenterId;//数据中⼼privatelongmachineId;//机器标识privatelongsequence =0L;//序列号privatelonglastTimeStamp =-1L;//上⼀次时间戳privatelonggetNextMill(){longmill = getNewTimeStamp();while(mill <= lastTimeStamp) {            mill = getNewTimeStamp();
}returnmill;    }privatelonggetNewTimeStamp(){returnSystem.currentTimeMillis();    }/**
* 根据指定的数据中⼼ID和机器标志ID⽣成指定的序列号
*

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。