分布式ID的实现方案

1. 什么是分布式ID

​ 对于低访问量的系统来说，无需对数据库进行分库分表，单库单表完全可以应对，但是随着系统访问量的上升，单表单库的访问压力逐渐增大，这时候就需要采用分库分表的方案，来缓解压力。

​ 在实际的业务场景中，我们常常需要一个唯一ID来确保数据的唯一性，对于单表单库来说，我们通常采用自增ID来作为标识，但是分库分表之后，自增ID的唯一性就无法保证。

​ 如上图所示，同一业务下的3张数据表，可能存在相同的ID，导致无法根据ID来确保数据的唯一性，因此，在分库分表的架构中，我们就需要使用分布式ID，来确保同一业务下的多张数据表或者多张数据库，数据的唯一性。

2. 分布式ID的实现方案

1. 基于UUID生成

​ UUID是一组由32位的16进制数据所构成，所以可以生成16^32个数据，也就是说，平均每纳秒可以生成1兆组数据，约100亿年才可以使用完。

​ UUID的格式为8-4-4-4-12，如：62f51e7e-a3ca-45ab-bf3f-2c3279f2991e，在JDK中，可以通过如下方式生成一组UUID：

    public static void main(String[] args) {UUID uuid = UUID.randomUUID();System.out.println("UUID：" + uuid);}

UUID：e27cc5fa-8655-4095-b682-e12d178791dd

​ 虽然UUID的实现方案简单便捷，但是由于其长度较长，在数据库中存储会占用过多资源，并且如果作为主键，由于UUID的无序性，会导致其存储的数据位置频繁变动，对性能影响较大。

2. 基于数据库生成

1. 基于特定起始值和步长分配ID

​ 例如现在分了3张表，分别是table_1、table_2、table_3，那么可以给table_1分配自增ID的起始值是1；为table_2分配自增ID的起始值是2，为table_3分配自增ID的起始值是3，步长均为3，这样同一业务下的这3张表，也可以确保其ID的唯一性。

以MySQL为例，可以在MySQL的配置文件中，设置自增ID起始值和步长

自增ID起始值：auto_increment_increment = value

自增ID步长：auto_increment_offset = value

​ 以上方式，虽然可以实现全局唯一ID的生成，但是该方案高度依赖数据库，一旦数据库发生异常，便直接影响业务，并且在主库发生异常，主从切换不一致时，可能会出现ID重复的异常。

2. 基于特定数据表分配ID

​ 可以新建一张数据表，专门存放当前最新的ID，每次需要获取ID值时，都将该数据表中的ID自增一次，并返回最新的ID值。

​ 以上方式，同样可以生成全局唯一ID，但是也同样高度依赖数据库，在进行实际的业务场景中，增加了一次与业务无关的读写操作，在高并发场景下，ID数据表的压力很大，对系统的QPS影响较大，并且当数据库发生异常时，也会直接影响原有的业务执行。

3. 基于Redis生成

​ 可以通过Redis的INCR和INCRBY指令来实行分布式ID的生成，每次请求时，都从Redis中获取一次分布式ID。

​ 当QPS较小时，此种方案可以应对，但是对于高并发场景，此种方案对于单台Redis服务器的性能要求较高，因此，需要搭建Redis集群，来缓解单台Redis服务器的压力，但是对于Redis集群来说，分布式ID的生成又会出现MySQL集群出现的问题，并且此种方案同样高度依赖Redis，一旦Redis服务器出现异常，就会影响到整个业务流程，同时此种方案引入了Redis中间件，增加了系统的复杂度。

4. 基于雪花算法生成

​ 雪花算法是由Twitter开源的一个分布式ID生成的解决方案，该分布式ID总共占用64bit存储空间，对于Java来说，正好使用long类型来进行存储。

第1位：始终是0，可以看做是符号位，不使用。

第2-42位：总共41位，表示时间戳，单位是毫秒，总共可以表示2^41个数字，即69年的时间。

第43-52位：总共10位，表示机器数，总共可以表示2^10=1024台机器，通常情况下，不需要部署这么多台机器，因此，一般将前5位表示数据中心，后5位表示机器数，即总共可以表示32个数据中心，每个数据中心有32台机器。

第53-64位：总共12位，表示自增序列，可以表示2^12=4096个数。

​ 这样划分之后，相当于在1ms之内，一个数据中心的一台服务器中，可以产生4096个不重复的有序ID。

​ 具体的Java代码实现如下：

/**** 雪花算法** @author niutucode*/
public class Snowflake {/*** 开始时间戳*/private static final long START_TIMESTAMP = 1736820033851L;/*** 机器位数*/private static final long MACHINE_BIT = 10L;/*** 序列号位数*/private static final long SEQUENCE_BIT = 12L;/*** 机器最大值 1023*/private static final long MAX_MACHINE_NUM = ~(-1L << MACHINE_BIT);/*** 序列号最大值 4095*/private static final long MAX_SEQUENCE = ~(-1L << SEQUENCE_BIT);/*** 机器标识向左移动的位数*/private static final long MACHINE_LEFT = SEQUENCE_BIT;/*** 时间戳向左移动的位数*/private static final long TIMESTAMP_LEFT = SEQUENCE_BIT + MACHINE_BIT;/*** 机器ID*/private long machineId;/*** 序列号*/private long sequence = -1L;/*** 上一次时间戳*/private long lastTimeStamp = 0L;/*** 构造器** @param machineId 机器ID*/public Snowflake(long machineId) {if (machineId > MAX_MACHINE_NUM || machineId < 0) {throw new IllegalArgumentException("机器ID不能大于" + MAX_MACHINE_NUM + "或者小于0");}this.machineId = machineId;}/*** 产生下一个时间戳** @param lastTimeStamp 上一次生成的时间戳* @return 下一个时间戳*/private long nextTimestamp(long lastTimeStamp) {long timestamp = System.currentTimeMillis();while (timestamp <= lastTimeStamp) {timestamp = System.currentTimeMillis();}return timestamp;}/*** 获取分布式ID* 该方法需线程安全，如果在分布式系统中，应该使用分布式锁来保证该方法的线程安全，如果不设置，在高并发场景中，      * 可能会出现多个线程生成同一ID的异常* @return 分布式ID*/public synchronized long nextId() {long timestamp = System.currentTimeMillis();if (timestamp < lastTimeStamp) {throw new RuntimeException("时钟回拨异常");}if (timestamp == lastTimeStamp) {// 相同毫秒内，序列号自增sequence = (sequence + 1) & MAX_SEQUENCE;// 同一毫秒的序列数已经达到最大if (sequence == 0) {timestamp = nextTimestamp(lastTimeStamp);}} else {sequence = 0L;}lastTimeStamp = timestamp;return (timestamp - START_TIMESTAMP) << TIMESTAMP_LEFT | machineId << MACHINE_LEFT | sequence;}
}

public static void main(String[] args) {Snowflake snowflake = new Snowflake(0);System.out.println("分布式ID：" + snowflake.nextId());
}

分布式ID：9161748250624

​ 通过雪花算法生成分布式ID，生成的ID是有序递增的，不依赖于第三方系统，在高并发场景下，依然具有良好的性能，相较于UUID方式生成分布式ID，该方式性能更高，占用空间小，且递增有序，可读性更好。

​ 但是雪花算法也存在一定的局限性，当系统发生时钟回拨时，该方法就会处于不可用的状态，可以使用百度的UidGenerator或者美团的Leaf规避这一风险，在实际的开发中，可以根据需要，选择合适的方案，来实现分布式ID的生成。