分布式ID

分布式 ID

何为 ID？

日常开发中，我们需要对系统中的各种数据使用 ID 唯一表示，比如用户 ID 对应且仅对应一个人，商品 ID 对应且仅对应一件商品，订单 ID 对应且仅对应一个订单。

我们现实生活中也有各种 ID，比如身份证 ID 对应且仅对应一个人、地址 ID 对应且仅对应

简单来说，ID 就是数据的唯一标识。

何为分布式 ID？

分布式 ID 是分布式系统下的 ID。分布式 ID 不存在与现实生活中，属于计算机系统中的一个概念。

我简单举一个分库分表的例子。

我司的一个项目，使用的是单机 MySQL 。但是，没想到的是，项目上线一个月之后，随着使用人数越来越多，整个系统的数据量将越来越大。

单机 MySQL 已经没办法支撑了，需要进行分库分表（推荐 Sharding-JDBC）。

在分库之后， 数据遍布在不同服务器上的数据库，数据库的自增主键已经没办法满足生成的主键唯一了。我们如何为不同的数据节点生成全局唯一主键呢？

这个时候就需要生成分布式 ID了。

分布式 ID 需要满足哪些要求?

分布式 ID 作为分布式系统中必不可少的一环，很多地方都要用到分布式 ID。

一个最基本的分布式 ID 需要满足下面这些要求：

• 全局唯一 ：ID 的全局唯一性肯定是首先要满足的！
• 高性能 ： 分布式 ID 的生成速度要快，对本地资源消耗要小。
• 高可用 ：生成分布式 ID 的服务要保证可用性无限接近于 100%。
• 方便易用 ：拿来即用，使用方便，快速接入！

除了这些之外，一个比较好的分布式 ID 还应保证：

• 安全 ：ID 中不包含敏感信息。
• 有序递增 ：如果要把 ID 存放在数据库的话，ID 的有序性可以提升数据库写入速度。并且，很多时候 ，我们还很有可能会直接通过 ID 来进行排序。
• 有具体的业务含义 ：生成的 ID 如果能有具体的业务含义，可以让定位问题以及开发更透明化（通过 ID 就能确定是哪个业务）。
• 独立部署 ：也就是分布式系统单独有一个发号器服务，专门用来生成分布式 ID。这样就生成 ID 的服务可以和业务相关的服务解耦。不过，这样同样带来了网络调用消耗增加的问题。总的来说，如果需要用到分布式 ID 的场景比较多的话，独立部署的发号器服务还是很有必要的。

分布式 ID 常见解决方案

数据库

数据库主键自增

这种方式就比较简单直白了，就是通过关系型数据库的自增主键产生来唯一的 ID。

以 MySQL 举例，我们通过下面的方式即可。

1.创建一个数据库表。

CREATE TABLE sequence_id (
id bigint(20) unsigned NOT NULL AUTO_INCREMENT,
stub char(10) NOT NULL DEFAULT ‘’,
PRIMARY KEY (id),
UNIQUE KEY stub (stub)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

stub 字段无意义，只是为了占位，便于我们插入或者修改数据。并且，给 stub 字段创建了唯一索引，保证其唯一性。

2.通过 replace into 来插入数据。

BEGIN;
REPLACE INTO sequence_id (stub) VALUES (‘stub’);
SELECT LAST_INSERT_ID();
COMMIT;

插入数据这里，我们没有使用 insert into 而是使用 replace into 来插入数据，具体步骤是这样的：

1)第一步： 尝试把数据插入到表中。

2)第二步： 如果主键或唯一索引字段出现重复数据错误而插入失败时，先从表中删除含有重复关键字值的冲突行，然后再次尝试把数据插入到表中。

这种方式的优缺点也比较明显：

• 优点 ：实现起来比较简单、ID 有序递增、存储消耗空间小
• 缺点 ： 支持的并发量不大、存在数据库单点问题（可以使用数据库集群解决，不过增加了复杂度）、ID 没有具体业务含义、安全问题（比如根据订单 ID 的递增规律就能推算出每天的订单量，商业机密啊！ ）、每次获取 ID 都要访问一次数据库（增加了对数据库的压力，获取速度也慢）

数据库号段模式

数据库主键自增这种模式，每次获取 ID 都要访问一次数据库，ID 需求比较大的时候，肯定是不行的。

如果我们可以批量获取，然后存在在内存里面，需要用到的时候，直接从内存里面拿就舒服了！这也就是我们说的 基于数据库的号段模式来生成分布式 ID。

数据库的号段模式也是目前比较主流的一种分布式 ID 生成方式。像滴滴开源的Tinyid 就是基于这种方式来做的。不过，TinyId 使用了双号段缓存、增加多 db 支持等方式来进一步优化。

以 MySQL 举例，我们通过下面的方式即可。

1.创建一个数据库表。

CREATE TABLE sequence_id_generator (
id int(10) NOT NULL,
current_max_id bigint(20) NOT NULL COMMENT ‘当前最大id’,
step int(10) NOT NULL COMMENT ‘号段的长度’,
version int(20) NOT NULL COMMENT ‘版本号’,
biz_type int(20) NOT NULL COMMENT ‘业务类型’,
PRIMARY KEY (id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

current_max_id 字段和step字段主要用于获取批量 ID，获取的批量 id 为： current_max_id ~ current_max_id+step。

version 字段主要用于解决并发问题（乐观锁）,biz_type 主要用于表示业余类型。

2.先插入一行数据。

INSERT INTO sequence_id_generator (id, current_max_id, step, version, biz_type)
VALUES
(1, 0, 100, 0, 101);

3.通过 SELECT 获取指定业务下的批量唯一 ID

SELECT current_max_id, step,version FROM sequence_id_generator where biz_type = 101

结果：

id current_max_id step version biz_type
1 0 100 1 101

4.不够用的话，更新之后重新 SELECT 即可。

UPDATE sequence_id_generator SET current_max_id = 0+100, version=version+1 WHERE version = 0 AND biz_type = 101
SELECT current_max_id, step,version FROM sequence_id_generator where biz_type = 101

结果：

id current_max_id step version biz_type
1 100 100 1 101

相比于数据库主键自增的方式，数据库的号段模式对于数据库的访问次数更少，数据库压力更小。

另外，为了避免单点问题，你可以从使用主从模式来提高可用性。

数据库号段模式的优缺点:

• 优点 ：ID 有序递增、存储消耗空间小
• 缺点 ：存在数据库单点问题（可以使用数据库集群解决，不过增加了复杂度）、ID 没有具体业务含义、安全问题（比如根据订单 ID 的递增规律就能推算出每天的订单量，商业机密啊！ ）

NoSQL

一般情况下，NoSQL 方案使用 Redis 多一些。我们通过 Redis 的 incr 命令即可实现对 id 原子顺序递增。

127.0.0.1:6379> set sequence_id_biz_type 1
OK
127.0.0.1:6379> incr sequence_id_biz_type
(integer) 2
127.0.0.1:6379> get sequence_id_biz_type
“2”

为了提高可用性和并发，我们可以使用 Redis Cluser。Redis Cluser 是 Redis 官方提供的 Redis 集群解决方案（3.0+版本）。

除了 Redis Cluser 之外，你也可以使用开源的 Redis 集群方案Codis （大规模集群比如上百个节点的时候比较推荐）。

除了高可用和并发之外，我们知道 Redis 基于内存，我们需要持久化数据，避免重启机器或者机器故障后数据丢失。Redis 支持两种不同的持久化方式：快照（snapshotting，RDB）、只追加文件（append-only file, AOF）。 并且，Redis 4.0 开始支持 RDB 和 AOF 的混合持久化（默认关闭，可以通过配置项 aof-use-rdb-preamble 开启）。

关于 Redis 持久化，我这里就不过多介绍。不了解这部分内容的小伙伴，可以看看 JavaGuide 对于 Redis 知识点的总结。

Redis 方案的优缺点：

• 优点 ： 性能不错并且生成的 ID 是有序递增的
• 缺点 ： 和数据库主键自增方案的缺点类似

除了 Redis 之外，MongoDB ObjectId 经常也会被拿来当做分布式 ID 的解决方案。

MongoDB ObjectId 一共需要 12 个字节存储：

• 0~3：时间戳
• 3~6： 代表机器 ID
• 7~8：机器进程 ID
• 9~11 ：自增值

MongoDB 方案的优缺点：

• 优点 ： 性能不错并且生成的 ID 是有序递增的
• 缺点 ： 需要解决重复 ID 问题（当机器时间不对的情况下，可能导致会产生重复 ID） 、有安全性问题（ID 生成有规律性）

算法

UUID

UUID 是 Universally Unique Identifier（通用唯一标识符） 的缩写。UUID 包含 32 个 16 进制数字（8-4-4-4-12）。

JDK 就提供了现成的生成 UUID 的方法，一行代码就行了。

//输出示例：cb4a9ede-fa5e-4585-b9bb-d60bce986eaa
UUID.randomUUID()

RFC 4122 中关于 UUID 的示例是这样的：

我们这里重点关注一下这个 Version(版本)，不同的版本对应的 UUID 的生成规则是不同的。

5 种不同的 Version(版本)值分别对应的含义（参考维基百科对于 UUID 的介绍）：

• 版本 1 : UUID 是根据时间和节点 ID（通常是 MAC 地址）生成；
• 版本 2 : UUID 是根据标识符（通常是组或用户 ID）、时间和节点 ID 生成；
• 版本 3、版本 5 : 版本 5 - 确定性 UUID 通过散列（hashing）名字空间（namespace）标识符和名称生成；
• 版本 4 : UUID 使用随机性或伪随机性生成。

下面是 Version 1 版本下生成的 UUID 的示例：

JDK 中通过 UUID 的 randomUUID() 方法生成的 UUID 的版本默认为 4。

UUID uuid = UUID.randomUUID();
int version = uuid.version();// 4

另外，Variant(变体)也有 4 种不同的值，这种值分别对应不同的含义。这里就不介绍了，貌似平时也不怎么需要关注。

需要用到的时候，去看看维基百科对于 UUID 的 Variant(变体) 相关的介绍即可。

从上面的介绍中可以看出，UUID 可以保证唯一性，因为其生成规则包括 MAC 地址、时间戳、名字空间（Namespace）、随机或伪随机数、时序等元素，计算机基于这些规则生成的 UUID 是肯定不会重复的。

虽然，UUID 可以做到全局唯一性，但是，我们一般很少会使用它。

比如使用 UUID 作为 MySQL 数据库主键的时候就非常不合适：

• 数据库主键要尽量越短越好，而 UUID 的消耗的存储空间比较大（32 个字符串，128 位）。
• UUID 是无顺序的，InnoDB 引擎下，数据库主键的无序性会严重影响数据库性能。

最后，我们再简单分析一下 UUID 的优缺点 （面试的时候可能会被问到的哦！） :

• 优点 ：生成速度比较快、简单易用
• 缺点 ： 存储消耗空间大（32 个字符串，128 位） 、 不安全（基于 MAC 地址生成 UUID 的算法会造成 MAC 地址泄露)、无序（非自增）、没有具体业务含义、需要解决重复 ID 问题（当机器时间不对的情况下，可能导致会产生重复 ID）

Snowflake(雪花算法)

Snowflake 是 Twitter 开源的分布式 ID 生成算法。Snowflake 由 64 bit 的二进制数字组成，这 64bit 的二进制被分成了几部分，每一部分存储的数据都有特定的含义：

• 第 0 位： 符号位（标识正负），始终为 0，没有用，不用管。
• 第 1~41 位 ：一共 41 位，用来表示时间戳，单位是毫秒，可以支撑 2 ^41 毫秒（约 69 年）
• 第 42~52 位 ：一共 10 位，一般来说，前 5 位表示机房 ID，后 5 位表示机器 ID（实际项目中可以根据实际情况调整）。这样就可以区分不同集群/机房的节点。
• 第 53~64 位 ：一共 12 位，用来表示序列号。 序列号为自增值，代表单台机器每毫秒能够产生的最大 ID 数(2^12 = 4096),也就是说单台机器每毫秒最多可以生成 4096 个 唯一 ID。

如果你想要使用 Snowflake 算法的话，一般不需要你自己再造轮子。有很多基于 Snowflake 算法的开源实现比如美团 的 Leaf、百度的 UidGenerator，并且这些开源实现对原有的 Snowflake 算法进行了优化。

另外，在实际项目中，我们一般也会对 Snowflake 算法进行改造，最常见的就是在 Snowflake 算法生成的 ID 中加入业务类型信息。

我们再来看看 Snowflake 算法的优缺点 ：

• 优点 ：生成速度比较快、生成的 ID 有序递增、比较灵活（可以对 Snowflake 算法进行简单的改造比如加入业务 ID）
• 缺点 ： 需要解决重复 ID 问题（依赖时间，当机器时间不对的情况下，可能导致会产生重复 ID）。

开源框架

UidGenerator(百度)

UidGenerator 是百度开源的一款基于 Snowflake(雪花算法)的唯一 ID 生成器。

不过，UidGenerator 对 Snowflake(雪花算法)进行了改进，生成的唯一 ID 组成如下。

可以看出，和原始 Snowflake(雪花算法)生成的唯一 ID 的组成不太一样。并且，上面这些参数我们都可以自定义。

UidGenerator 官方文档中的介绍如下：

自 18 年后，UidGenerator 就基本没有再维护了，我这里也不过多介绍。想要进一步了解的朋友，可以看看 UidGenerator 的官方介绍。

Leaf(美团)

Leaf 是美团开源的一个分布式 ID 解决方案 。这个项目的名字 Leaf（树叶） 起源于德国哲学家、数学家莱布尼茨的一句话： “There are no two identical leaves in the world”（世界上没有两片相同的树叶） 。这名字起得真心挺不错的，有点文艺青年那味了！

Leaf 提供了 号段模式 和 Snowflake(雪花算法) 这两种模式来生成分布式 ID。并且，它支持双号段，还解决了雪花 ID 系统时钟回拨问题。不过，时钟问题的解决需要弱依赖于 Zookeeper 。

Leaf 的诞生主要是为了解决美团各个业务线生成分布式 ID 的方法多种多样以及不可靠的问题。

Leaf 对原有的号段模式进行改进，比如它这里增加了双号段避免获取 DB 在获取号段的时候阻塞请求获取 ID 的线程。简单来说，就是我一个号段还没用完之前，我自己就主动提前去获取下一个号段（图片来自于美团官方文章：《Leaf——美团点评分布式 ID 生成系统》）。

根据项目 README 介绍，在 4C8G VM 基础上，通过公司 RPC 方式调用，QPS 压测结果近 5w/s，TP999 1ms。

Tinyid(滴滴)

Tinyid 是滴滴开源的一款基于数据库号段模式的唯一 ID 生成器。

数据库号段模式的原理我们在上面已经介绍过了。Tinyid 有哪些亮点呢？

为了搞清楚这个问题，我们先来看看基于数据库号段模式的简单架构方案。（图片来自于 Tinyid 的官方 wiki:《Tinyid 原理介绍》）

在这种架构模式下，我们通过 HTTP 请求向发号器服务申请唯一 ID。负载均衡 router 会把我们的请求送往其中的一台 tinyid-server。

这种方案有什么问题呢？在我看来（Tinyid 官方 wiki 也有介绍到），主要由下面这 2 个问题：

• 获取新号段的情况下，程序获取唯一 ID 的速度比较慢。
• 需要保证 DB 高可用，这个是比较麻烦且耗费资源的。

除此之外，HTTP 调用也存在网络开销。

Tinyid 的原理比较简单，其架构如下图所示：

相比于基于数据库号段模式的简单架构方案，Tinyid 方案主要做了下面这些优化：

• 双号段缓存 ：为了避免在获取新号段的情况下，程序获取唯一 ID 的速度比较慢。 Tinyid 中的号段在用到一定程度的时候，就会去异步加载下一个号段，保证内存中始终有可用号段。
• 增加多 db 支持 ：支持多个 DB，并且，每个 DB 都能生成唯一 ID，提高了可用性。
• 增加 tinyid-client ：纯本地操作，无 HTTP 请求消耗，性能和可用性都有很大提升。

Tinyid 的优缺点这里就不分析了，结合数据库号段模式的优缺点和 Tinyid 的原理就能知道。

分布式ID方案

下表为一些常用方案对比：

目前流行的分布式ID解决方案有两种：「号段模式」和「雪花算法」。

「号段模式」依赖于数据库，但是区别于数据库主键自增的模式。假设100为一个号段100，200，300，每取一次可以获得100个ID，性能显著提高。

「雪花算法」是由符号位+时间戳+工作机器id+序列号组成的，如图所示：

符号位为0，0表示正数，ID为正数。

时间戳位不用多说，用来存放时间戳，单位是ms。

工作机器id位用来存放机器的id，通常分为5个区域位+5个服务器标识位。

序号位是自增。

雪花算法能存放多少数据？时间范围：2^41 / (3652460601000) = 69年 工作进程范围：2^10 = 1024 序列号范围：2^12 = 4096，表示1ms可以生成4096个ID。

根据这个算法的逻辑，只需要将这个算法用Java语言实现出来，封装为一个工具方法，那么各个业务应用可以直接使用该工具方法来获取分布式ID，只需保证每个业务应用有自己的工作机器id即可，而不需要单独去搭建一个获取分布式ID的应用。下面是推特版的Snowflake算法：

public class SnowFlake {  
  
    /**  
     * 起始的时间戳  
     */  
    private final static long START_STMP = 1480166465631L;  
  
    /**  
     * 每一部分占用的位数  
     */  
    private final static long SEQUENCE_BIT = 12; //序列号占用的位数  
    private final static long MACHINE_BIT = 5;   //机器标识占用的位数  
    private final static long DATACENTER_BIT = 5;//数据中心占用的位数  
  
    /**  
     * 每一部分的最大值  
     */  
    private final static long MAX_DATACENTER_NUM = -1L ^ (-1L << DATACENTER_BIT);  
    private final static long MAX_MACHINE_NUM = -1L ^ (-1L << MACHINE_BIT);  
    private final static long MAX_SEQUENCE = -1L ^ (-1L << SEQUENCE_BIT);  
  
    /**  
     * 每一部分向左的位移  
     */  
    private final static long MACHINE_LEFT = SEQUENCE_BIT;  
    private final static long DATACENTER_LEFT = SEQUENCE_BIT + MACHINE_BIT;  
    private final static long TIMESTMP_LEFT = DATACENTER_LEFT + DATACENTER_BIT;  
  
    private long datacenterId;  //数据中心  
    private long machineId;     //机器标识  
    private long sequence = 0L; //序列号  
    private long lastStmp = -1L;//上一次时间戳  
  
    public SnowFlake(long datacenterId, long machineId) {  
        if (datacenterId > MAX_DATACENTER_NUM || datacenterId < 0) {  
            throw new IllegalArgumentException("datacenterId can't be greater than MAX_DATACENTER_NUM or less than 0");  
        }  
        if (machineId > MAX_MACHINE_NUM || machineId < 0) {  
            throw new IllegalArgumentException("machineId can't be greater than MAX_MACHINE_NUM or less than 0");  
        }  
        this.datacenterId = datacenterId;  
        this.machineId = machineId;  
    }  
  
    /**  
     * 产生下一个ID  
     *  
     * @return  
     */  
    public synchronized long nextId() {  
        long currStmp = getNewstmp();  
        if (currStmp < lastStmp) {  
            throw new RuntimeException("Clock moved backwards.  Refusing to generate id");  
        }  
  
        if (currStmp == lastStmp) {  
            //相同毫秒内，序列号自增  
            sequence = (sequence + 1) & MAX_SEQUENCE;  
            //同一毫秒的序列数已经达到最大  
            if (sequence == 0L) {  
                currStmp = getNextMill();  
            }  
        } else {  
            //不同毫秒内，序列号置为0  
            sequence = 0L;  
        }  
  
        lastStmp = currStmp;  
  
        return (currStmp - START_STMP) << TIMESTMP_LEFT //时间戳部分  
                | datacenterId << DATACENTER_LEFT       //数据中心部分  
                | machineId << MACHINE_LEFT             //机器标识部分  
                | sequence;                             //序列号部分  
    }  
  
    private long getNextMill() {  
        long mill = getNewstmp();  
        while (mill <= lastStmp) {  
            mill = getNewstmp();  
        }  
        return mill;  
    }  
  
    private long getNewstmp() {  
        return System.currentTimeMillis();  
    }  
  
    public static void main(String[] args) {  
        SnowFlake snowFlake = new SnowFlake(2, 3);  
  
        for (int i = 0; i < (1 << 12); i++) {  
            System.out.println(snowFlake.nextId());  
        }  
  
    }  
}

今天主要分析一下以下9种，分布式ID生成器方式以及优缺点：

• UUID
• 数据库自增ID
• 数据库多主模式
• 号段模式
• Redis
• 雪花算法（SnowFlake）
• 滴滴出品（TinyID）
• 百度 （Uidgenerator）
• 美团（Leaf）

那么它们都是如何实现？以及各自有什么优缺点？我们往下看

图片源自网络

以上图片源自网络，如有侵权联系删除

1. 基于UUID

在Java的世界里，想要得到一个具有唯一性的ID，首先被想到可能就是UUID，毕竟它有着全球唯一的特性。那么UUID可以做分布式ID吗？答案是可以的，但是并不推荐！

public static void main(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`;  
CREATETABLE SEQID.SEQUENCE_ID (  
idbigint(20) unsignedNOTNULL auto_increment,  
valuechar(10) NOTNULLdefault'',  
PRIMARY KEY (id),  
) ENGINE=MyISAM;

insert into SEQUENCE_ID(value)  VALUES ('values');

当我们需要一个ID的时候，向表中插入一条记录返回主键ID，但这种方式有一个比较致命的缺点，访问量激增时MySQL本身就是系统的瓶颈，用它来实现分布式服务风险比较大，不推荐！

优点：

• 实现简单，ID单调自增，数值类型查询速度快

缺点：

• DB单点存在宕机风险，无法扛住高并发场景

3. 基于数据库集群模式

前边说了单点数据库方式不可取，那对上边的方式做一些高可用优化，换成主从模式集群。害怕一个主节点挂掉没法用，那就做双主模式集群，也就是两个Mysql实例都能单独的生产自增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并加载到内存。表结构如下：

CREATETABLE id_generator (  
idint(10) NOTNULL,  
max_id bigint(20) NOTNULLCOMMENT'当前最大id',  
step int(20) NOTNULLCOMMENT'号段的布长',  
biz_type int(20) NOTNULLCOMMENT'业务类型',  
versionint(20) NOTNULLCOMMENT'版本号',  
PRIMARY KEY (`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]。

update id_generator 
set max_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> set seq_id 1     // 初始化自增ID为1
OK
127.0.0.1:6379> incr seq_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算法实现：

/**  
 * Twitter的SnowFlake算法,使用SnowFlake算法生成一个整数，然后转化为62进制变成一个短地址URL * <p>  
 * https://github.com/beyondfengyu/SnowFlake */public class SnowFlakeShortUrl {  
  
 /**  
 * 起始的时间戳 */ privatefinalstaticlong START_TIMESTAMP = 1480166465631L;  
  
    /**  
 * 每一部分占用的位数 */ privatefinalstaticlong SEQUENCE_BIT = 12;   //序列号占用的位数  
 privatefinalstaticlong MACHINE_BIT = 5;     //机器标识占用的位数  
 privatefinalstaticlong DATA_CENTER_BIT = 5; //数据中心占用的位数  
  
 /** * 每一部分的最大值 */ privatefinalstaticlong MAX_SEQUENCE = -1L ^ (-1L << SEQUENCE_BIT);  
    privatefinalstaticlong MAX_MACHINE_NUM = -1L ^ (-1L << MACHINE_BIT);  
    privatefinalstaticlong MAX_DATA_CENTER_NUM = -1L ^ (-1L << DATA_CENTER_BIT);  
  
    /**  
 * 每一部分向左的位移 */ privatefinalstaticlong MACHINE_LEFT = SEQUENCE_BIT;  
    privatefinalstaticlong DATA_CENTER_LEFT = SEQUENCE_BIT + MACHINE_BIT;  
    privatefinalstaticlong TIMESTAMP_LEFT = DATA_CENTER_LEFT + DATA_CENTER_BIT;  
  
    privatelong dataCenterId;  //数据中心  
 privatelong machineId;     //机器标识  
 privatelong sequence = 0L; //序列号  
 privatelong lastTimeStamp = -1L;  //上一次时间戳  
  
 private long getNextMill() {  
 long mill = getNewTimeStamp();  
        while (mill <= lastTimeStamp) {  
 mill = getNewTimeStamp();  
        }  
 return mill;  
    }  
  
 private long getNewTimeStamp() {  
 return System.currentTimeMillis();  
    }  
  
 /**  
 * 根据指定的数据中心ID和机器标志ID生成指定的序列号 * * @param dataCenterId 数据中心ID  
 * @param machineId    机器标志ID  
 */ public SnowFlakeShortUrl(long dataCenterId, long machineId) {  
 if (dataCenterId > MAX_DATA_CENTER_NUM || dataCenterId < 0) {  
 thrownew IllegalArgumentException ("DtaCenterId can't be greater than MAX_DATA_CENTER_NUM or less than 0！");  
        }  
 if (machineId > MAX_MACHINE_NUM || machineId < 0) {  
 thrownew IllegalArgumentException ("MachineId can't be greater than MAX_MACHINE_NUM or less than 0！");  
        }  
 this.dataCenterId = dataCenterId;  
        this.machineId = machineId;  
    }  
  
 /**  
 * 产生下一个ID * * @return  
 */  
 public synchronized long nextId() {  
 long currTimeStamp = getNewTimeStamp();  
        if (currTimeStamp < lastTimeStamp) {  
 thrownew RuntimeException ("Clock moved backwards.  Refusing to generate id");  
        }  
  
 if (currTimeStamp == lastTimeStamp) {  
 //相同毫秒内，序列号自增  
 sequence = (sequence + 1) & MAX_SEQUENCE;  
            //同一毫秒的序列数已经达到最大  
 if (sequence == 0L) {  
 currTimeStamp = getNextMill();  
            }  
 } else {  
 //不同毫秒内，序列号置为0  
 sequence = 0L;  
        }  
  
 lastTimeStamp = currTimeStamp;  
  
        return (currTimeStamp - START_TIMESTAMP) << TIMESTAMP_LEFT //时间戳部分  
 | dataCenterId << DATA_CENTER_LEFT //数据中心部分  
 | machineId << MACHINE_LEFT //机器标识部分  
 | sequence;                             //序列号部分  
 }  
  
 public static void main(String[] args) {  
 SnowFlakeShortUrl snowFlake = new SnowFlakeShortUrl(2, 3);  
  
        for (int i = 0; i < (1 << 4); i++) {  
 //10进制  
 System.out.println(snowFlake.nextId());  
        }  
 }
}

7. 百度（uid-generator）

uid-generator是由百度技术部开发，项目GitHub地址 github.com/baidu/uid-g…

uid-generator是基于Snowflake算法实现的，与原始的snowflake算法不同在于，uid-generator支持自定义时间戳、工作机器ID和 序列号 等各部分的位数，而且uid-generator中采用用户自定义workId的生成策略。

uid-generator需要与数据库配合使用，需要新增一个WORKER_NODE表。当应用启动时会向数据库表中去插入一条数据，插入成功后返回的自增ID就是该机器的workId数据由host，port组成。

对于uid-generator ID组成结构：

workId，占用了22个bit位，时间占用了28个bit位，序列化占用了13个bit位，需要注意的是，和原始的snowflake不太一样，时间的单位是秒，而不是毫秒，workId也不一样，而且同一应用每次重启就会消费一个workId。

参考文献 github.com/baidu/uid-g…

8. 美团（Leaf）

Leaf由美团开发，github地址：github.com/Meituan-Dia…

Leaf同时支持号段模式和snowflake算法模式，可以切换使用。

号段模式

先导入源码 github.com/Meituan-Dia… ，在建一张表leaf_alloc

DROPTABLEIFEXISTS`leaf_alloc`;  
  
CREATETABLE`leaf_alloc` (  
`biz_tag`varchar(128) NOTNULLDEFAULT''COMMENT'业务key',  
`max_id`bigint(20) NOTNULLDEFAULT'1'COMMENT'当前已经分配了的最大id',  
`step`int(11) NOTNULLCOMMENT'初始步长，也是动态调整的最小步长',  
`description`varchar(256) DEFAULTNULLCOMMENT'业务key的描述',  
`update_time`timestampNOTNULLDEFAULTCURRENT_TIMESTAMPONUPDATECURRENT_TIMESTAMPCOMMENT'数据库维护的更新时间',  
PRIMARY KEY (`biz_tag`)  
) ENGINE=InnoDB;

然后在项目中开启号段模式，配置对应的数据库信息，并关闭snowflake模式

leaf.name=com.sankuai.leaf.opensource.test
leaf.segment.enable=true
leaf.jdbc.url=jdbc:mysql://localhost:3306/leaf_test?useUnicode=true&characterEncoding=utf8&characterSetResults=utf8
leaf.jdbc.username=root
leaf.jdbc.password=root
leaf.snowflake.enable=false
#leaf.snowflake.zk.address=
#leaf.snowflake.port=

启动leaf-server 模块的 LeafServerApplication项目就跑起来了

号段模式获取分布式自增ID的测试url ：http：<//localhost>：8080/api/segment/get/leaf-segment-test

监控号段模式：http://localhost:8080/cache

snowflake模式

Leaf的snowflake模式依赖于ZooKeeper，不同于原始snowflake算法也主要是在workId的生成上，Leaf中workId是基于ZooKeeper的顺序Id来生成的，每个应用在使用Leaf-snowflake时，启动时都会都在Zookeeper中生成一个顺序Id，相当于一台机器对应一个顺序节点，也就是一个workId。

leaf.snowflake.enable=true
leaf.snowflake.zk.address=127.0.0.1
leaf.snowflake.port=2181

snowflake模式获取分布式自增ID的测试url：http://localhost:8080/api/snowflake/get/test

9、滴滴（Tinyid）

Tinyid由滴滴开发，Github地址：github.com/didi/tinyid…

Tinyid是基于号段模式原理实现的与Leaf如出一辙，每个服务获取一个号段（1000,2000]、（2000,3000]、（3000,4000]

在这里插入图片描述

Tinyid提供http和tinyid-client两种方式接入

Http方式接入

（1）导入Tinyid源码：

git clone github.com/didi/tinyid…

（2）创建数据表：

CREATETABLE`tiny_id_info` (  
`id`bigint(20) unsignedNOTNULL AUTO_INCREMENT COMMENT'自增主键',  
`biz_type`varchar(63) NOTNULLDEFAULT''COMMENT'业务类型，唯一',  
`begin_id`bigint(20) NOTNULLDEFAULT'0'COMMENT'开始id，仅记录初始值，无其他含义。初始化时begin_id和max_id应相同',  
`max_id`bigint(20) NOTNULLDEFAULT'0'COMMENT'当前最大id',  
`step`int(11) DEFAULT'0'COMMENT'步长',  
`delta`int(11) NOTNULLDEFAULT'1'COMMENT'每次id增量',  
`remainder`int(11) NOTNULLDEFAULT'0'COMMENT'余数',  
`create_time`timestampNOTNULLDEFAULT'2010-01-01 00:00:00'COMMENT'创建时间',  
`update_time`timestampNOTNULLDEFAULT'2010-01-01 00:00:00'COMMENT'更新时间',  
`version`bigint(20) NOTNULLDEFAULT'0'COMMENT'版本号',  
PRIMARY KEY (`id`),  
UNIQUEKEY`uniq_biz_type` (`biz_type`)  
) ENGINE=InnoDB AUTO_INCREMENT=1DEFAULTCHARSET=utf8 COMMENT'id信息表';  
  
CREATETABLE`tiny_id_token` (  
`id`int(11) unsignedNOTNULL AUTO_INCREMENT COMMENT'自增id',  
`token`varchar(255) NOTNULLDEFAULT''COMMENT'token',  
`biz_type`varchar(63) NOTNULLDEFAULT''COMMENT'此token可访问的业务类型标识',  
`remark`varchar(255) NOTNULLDEFAULT''COMMENT'备注',  
`create_time`timestampNOTNULLDEFAULT'2010-01-01 00:00:00'COMMENT'创建时间',  
`update_time`timestampNOTNULLDEFAULT'2010-01-01 00:00:00'COMMENT'更新时间',  
PRIMARY KEY (`id`)  
) ENGINE=InnoDB AUTO_INCREMENT=1DEFAULTCHARSET=utf8 COMMENT'token信息表';  
  
INSERTINTO`tiny_id_info` (`id`, `biz_type`, `begin_id`, `max_id`, `step`, `delta`, `remainder`, `create_time`, `update_time`, `version`)  
VALUES  
(1, 'test', 1, 1, 100000, 1, 0, '2018-07-21 23:52:58', '2018-07-22 23:19:27', 1);  
  
INSERTINTO`tiny_id_info` (`id`, `biz_type`, `begin_id`, `max_id`, `step`, `delta`, `remainder`, `create_time`, `update_time`, `version`)  
VALUES  
(2, 'test_odd', 1, 1, 100000, 2, 1, '2018-07-21 23:52:58', '2018-07-23 00:39:24', 3);  
  
  
INSERTINTO`tiny_id_token` (`id`, `token`, `biz_type`, `remark`, `create_time`, `update_time`)  
VALUES  
(1, '0f673adf80504e2eaa552f5d791b644c', 'test', '1', '2017-12-14 16:36:46', '2017-12-14 16:36:48');  
  
INSERTINTO`tiny_id_token` (`id`, `token`, `biz_type`, `remark`, `create_time`, `update_time`)  
VALUES  
(2, '0f673adf80504e2eaa552f5d791b644c', 'test_odd', '1', '2017-12-14 16:36:46', '2017-12-14 16:36:48');

（3）配置数据库：

datasource.tinyid.names=primary
datasource.tinyid.primary.driver-class-name=com.mysql.jdbc.Driver
datasource.tinyid.primary.url=jdbc:mysql://ip:port/databaseName?autoReconnect=true&useUnicode=true&characterEncoding=UTF-8
datasource.tinyid.primary.username=root
datasource.tinyid.primary.password=123456

（4）启动tinyid-server后测试

获取分布式自增ID: 
http://localhost:9999/tinyid/id/nextIdSimple?bizType=test&token=0f673adf80504e2eaa552f5d791b644c'
返回结果: 3

批量获取分布式自增ID:
http://localhost:9999/tinyid/id/nextIdSimple?bizType=test&token=0f673adf80504e2eaa552f5d791b644c&batchSize=10'返回结果:  4,5,6,7,8,9,10,11,12,13

Java客户端方式接入

重复Http方式的（2）（3）操作

引入依赖

<dependency>            
  <groupId>com.xiaoju.uemc.tinyid</groupId>                <artifactId>tinyid-client</artifactId>            <version>${tinyid.version}</version>        
</dependency>

配置文件

tinyid.server = localhost:9999
tinyid.token = 0f673adf80504e2eaa552f5d791b644c

test 、tinyid.token是在数据库表中预先插入的数据，test 是具体业务类型，tinyid.token表示可访问的业务类型

// 获取单个分布式自增ID
Long id =  TinyId . nextId( " test " );
// 按需批量分布式自增
IDList< Long > ids =  TinyId . nextId( " test " , 10 );

参考文章：
(……) 「Java面试指北」为什么需要分布式ID？大厂的分布式 ID 生成方案是什么样的？| JavaGuide - SegmentFault 思否
一口气说出9种分布式ID生成方式，面试官有点懵了！ (qq.com)
【面朝大厂】面试官：说几种常用的分布式 ID 解决方案 (qq.com)