分布式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和