在公众号上看到一篇写得不错的分布式 Id 生成方式，特意搬过来，提升下 CSDN 的技术水平 ，并且加了自己的实践，不能算是抄袭啊，原作者如果想要删除本文，请私信我
本人实践项目：https://gitee.com/sanri/example/tree/master/testdistributedid
为什么要用分布式 ID
在业务数据量不大的时候，这时我们单表可以解决，我认为 mysql 单表最好不要超过 500 万，这个时候可以使用 Mysql 的自增 ID ，但如果业务起来了，分库分表后，多库生成的 Id 就会冲突，主键的唯一性就得不到保证了。此时一个能够生成 全局唯一ID 的系统是非常必要的。那么这个全局唯一ID就叫分布式ID。
分布式 ID 需要满足什么条件
- 全局唯一：必须保证ID是全局性唯一的，基本要求
- 高性能：高可用低延时，ID生成响应要块，否则反倒会成为业务瓶颈
- 高可用：100%的可用性是骗人的，但是也要无限接近于100%的可用性
- 好接入：要秉着拿来即用的设计原则，在系统设计和实现上要尽可能的简单
- 趋势递增：最好趋势递增，这个要求就得看具体业务场景了，一般不严格要求
分布式 ID 都有哪些生成方式
今天主要分析一下以下9种，分布式ID生成器方式以及优缺点：
- UUID
- 数据库自增ID
- 数据库多主模式
- 号段模式
- Redis
- 雪花算法（SnowFlake）
- 滴滴出品（TinyID）
- 百度 （Uidgenerator）
- 美团（Leaf）
基于UUID
在Java的世界里，想要得到一个具有唯一性的ID，首先被想到可能就是UUID，毕竟它有着全球唯一的特性。那么UUID可以做分布式ID吗？答案是可以的，但是并不推荐！
public String generateId(int bizType) {
return UUID.randomUUID().toString().replace("-","");
}
UUID的生成简单到只有一行代码，输出结果 c2b8c2b9e46c47e3b30dca3b0d447718，但UUID却并不适用于实际的业务需求。像用作订单号UUID这样的字符串没有丝毫的意义，看不出和订单相关的有用信息；而对于数据库来说用作业务主键ID，它不仅是太长还是字符串，存储性能差查询也很耗时，所以不推荐用作分布式ID。
优点：
- 生成足够简单，本地生成无网络消耗，具有唯一性
缺点：
- 无序的字符串，不具备趋势自增特性
- 没有具体的业务含义
- 长度过长16 字节128位，36位长度的字符串，存储以及查询对MySQL的性能消耗较大，MySQL官方明确建议主键要尽量越短越好，作为数据库主键
UUID的无序性会导致数据位置频繁变动，严重影响性能。
基于数据库自增 ID
基于数据库的auto_increment自增ID完全可以充当分布式ID，具体实现：需要一个单独的MySQL实例用来生成ID，建表结构如下：
create table SEQUENCE_ID(
id bigint(20) unsigned not null auto_increment,
value char(1) not null default '',
primary key (id)
) engine= innodb;
这张表就相当于是 oracle 的序列，当我们需要一个ID的时候，向表中插入一条记录返回主键ID，但这种方式有一个比较致命的缺点，访问量激增时MySQL本身就是系统的瓶颈，用它来实现分布式服务风险比较大，不推荐！
优点：
- 实现简单，ID单调自增，数值类型查询速度快
缺点：
- DB单点存在宕机风险，无法扛住高并发场景
基于数据库集群模式
前边说了单点数据库方式不可取，那对上边的方式做一些高可用优化，换成主从模式集群。害怕一个主节点挂掉没法用，那就做双主模式集群，也就是两个Mysql实例都能单独的生产自增ID。
那这样还会有个问题，两个MySQL实例的自增ID都从1开始，会生成重复的ID怎么办？
解决方案：设置起始值和自增步长
mysql1 产生的 id ：1,3,5,7
mysql2 产生的 id ：2,4,6,8
但这样扩容比较麻烦 ，需要人工修改第一台和第台 mysql 实例的起始值和自增步长 把第三台机器的ID起始生成位置设定在比现有最大自增ID的位置远一些，但必须在一、二两台MySQL实例ID还没有增长到第三台MySQL实例的起始ID值的时候，否则自增ID就要出现重复了，必要时可能还需要停机修改。
优点：
- 解决DB单点问题
缺点：
- 不利于后续扩容，而且实际上单个数据库自身压力还是大，依旧无法满足高并发场景。
基于数据库号段模式
号段模式是当下分布式ID生成器的主流实现方式之一，号段模式可以理解为从数据库批量的获取自增ID，每次从数据库取出一个号段范围，例如 (1,1000] 代表1000个ID，具体的业务服务将本号段，生成1~1000的自增ID并加载到内存，这种方式比较重要，我也将主要介绍这种方式。 建立数据表
CREATE TABLE id_generator (
id int(10) NOT NULL auto_increment,
max_id bigint(20) NOT NULL COMMENT '当前最大id',
step int(20) NOT NULL COMMENT '号段的步长',
biz_type int(20) NOT NULL COMMENT '业务类型',
version int(20) NOT NULL COMMENT '版本号',
PRIMARY KEY (`id`)
) engine= innodb;
考虑到并发修改，使用 version 做一个乐观锁，也可以使用事务锁，但性能会降低
首次使用时需要初始化号段，可使用 sql , 也可以在应用启动时候去初始化某个业务的号段
-- 初始化号段表
insert into id_generator(max_id,step,biz_type,version) values (0,1000,1000,0);
业务端每次去数据库取一个号段，并更新数据版本和 max_id
-- 取某个业务的 max_id
select id,max_id,step,biz_type,version from id_generator where biz_type = ?
-- 更新 max_id 取到号段
update id_generator set max_id = max_id + step ,version = version + 1 where id = ? and max_id = ? and version = ?
业务端取完之后，可以将所有 id 存在一个 BlockQueue 中，当 blockQueue 中的 id 量不够的时候（我们可以设置一个 阈值如 50% ），向数据库异步发起一个请求获取 id ，这个时候如果消费端消息完了，可以用到 blockQueue 的阻塞功能 ，blockQueue 也支持并发修改
这种方式不能分库分表，但可以使用主从，因为这种分布式ID生成方式不强依赖于数据库，不会频繁的访问数据库，对数据库的压力小很多，如果主库挂了，业务端还是在一段时间内是有 id 可用的，可以在这段时间内快速做主从切换
基于 Redis 模式
可以用 redis 的 incr 命令实现 id 的原子性自增
set seq_id 1
incr seq_id
那如果 redis down 了怎么办，可以使用 redis 主从模式+哨兵模式，如果在高峰时候 redis down 了 ， 在切换从库的时候怎么办呢，在切换这个期间也是有空档的，如果非要这样的高可用，则可以使用 redis 的号段模式，incr 可以加一个号段 ， 并把加载到的 id 存到应用本地，如果 redis down 机，应用在 redis 切换从库还是有 id 可用的。
incrby seq_id 1000
基于雪花算法 (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 版本在我的 实践项目 有，这里就不贴代码了
基于大厂写好的分布式 ID 生成工具
TinyId , Uidgenerator ,Leaf 大都是基于雪花算法的改进或使用号段模式，我们没必要重复造轮子，有开源好用的，就直接拿来用。
我的实践中集成了百度的 UID 生成，百度是基于雪花算法的，其它的就没弄了，好像是要单独启服务的
这种公共服务可以部署成服务，使用多实例来提供高可用性，多台server之间因为生成算法的原子性，而保证每台server上的可用号段不重，从而使id生成不重。
友情链接
我的一个工具 sanri-tools , 可以做 kafka 监控(主题,消费组,分区,反序列化) , redis 数据查看(可以反序列化字段信息看到真实数据),数据表管理,代码生成