mysql集群发号器_分布式——分布式发号器

今天停电，所以springboot源码看不了，手头刚好有本书，学习了下分布式发号器

一、方案

1、UUID

无法满足业务特性。UUID虽然能保证ID的唯一性，但是无法满足业务要求的很多其他特性，如有序性+可反解性(没有提供反解方法，例如反解得到时间戳)+可制造性(手工生成、洗脏数据难度变大)

占用空间大。UUID比较长，利用JDK生成的一个UUID占用36字节(由于包含a-f，数据库类型varchar类型)：8-4-4-4-12，如果建立B+树索引的话，导致单个索引节点包含关键字减少，索引节点变多，高度变高，性能下降

由于是无序的，作为InnoDB主键索引，可能会导致页分裂，降低插入性能同时，还产生了很多内存碎片

public classUUIDTest {public static voidmain(String[] args) {//JDK中uuid属于总共128个bit//time_low = 32bit//time_mid = 16bit//time_high_and_version= 16bit//variant_and_sequence= 16bit//node = 48bit//① 由于toString采用16进制(4bit)打印 8-4-4-4-12共36个字节//② version=4的uuid，随机数生成，没有机器码，所以分布式还是可能存在重复的

UUID uuid =UUID.randomUUID();

System.out.println(uuid.toString());//5db67001-7d8b-49a0-baa2-215629b00ae9

}

}

2、数据库生成

利用数据库作为发号器，有两种方法：表字段自增与自增序列sequence。虽然能保证id唯一性，但是会影响数据库的性能与伸缩性。

增加数据库压力，降低性能。Id的产生是一种频繁的操作，会频繁的请求数据库，导致数据库性能下降。

降低数据库审索引。无论表字段自增还是自增序列实现，都会影响数据库分表分库。

sequence是一种隐式字段，需要人工维护

--表字段自增 mysql中常用

id bigint(20) auto increment,--自增序列sequence oracle中常用

createsequence sequence_name

incrementby 1 　 --每次加的个数据

start with 1 　　 --从1开始计数

nomaxvalue　　　 --不设置最大值

nocycle　　　　　 --一直累加，不循环

cache 10;

sequence.nextval;--自增sequence并返回

3、Snowflake——雪花算法

Snowflake是Twitter开源的分布式发号器，类似uuid使用bit位控制生成。结构如下：

--总共64bit，

-- 时间戳放在高位，保证毫秒级的有序性；

-- 机器号+序列号处于低位，单机有序的，多机无序的--1bit：无效位，其实可以作为版本号--41bit：时间戳位--10bit：机器号--12bit：序列号

简单实现，具体的肯定比这个复杂得多：

public classSnowFlakeIdGenerator {private final long version;//版本号 1bit

private final long STARTTIMESTAMP = 1585286065061L;//创建ID生成器的时间

private long timestamp;//时间戳毫秒级 41bit

private final long mcid;//机器id 10bit

private int seq = -1;//自增seq

private long lastTimstamp = -1;//记录毫秒级

private long lastSeql = 0;//记录同毫秒级的sql

public SnowFlakeIdGenerator(long version,longmcid){//版本号校验

if (version>1 || version <0){throw new IllegalArgumentException("version must in {0,1}");

}//机器号校验

if (mcid>1023 || mcid < 0){throw new IllegalArgumentException("mcid must in {0-1023}");

}this.version =version;this.mcid =mcid;

}/*** 同毫秒级seq自增，

* 不同毫秒级seq归零

*@return

*/

private long getSeq(longcurrent){if (lastTimstamp ==current){//同毫秒级校验seq是否超出范围

if (seq > 1022){throw new IllegalArgumentException("seq arrive max,generator failed!");

}

}else{//不同毫秒级seq归零

lastTimstamp =current;

seq= -1;

System.out.println("============== 分割线 =================");

}return ++seq;

}private longgenerator(){long timestamp = System.currentTimeMillis()-STARTTIMESTAMP;long id = 0L;//1 + 41 + 10 + 12 由于时间处于高位，所以毫秒间是有序的

id |= version << 63;

id|= timestamp << 22;

id|= mcid << 12;

id|=getSeq(timestamp);returnid;

}public static voidmain(String[] args) {

ExecutorService pool= Executors.newFixedThreadPool(2);//开两个线程模拟分布式两台机器//毫秒间是有序的//毫秒内是单机有序的,整体是无序的

pool.submit(newRunnable() {

@Overridepublic voidrun() {

SnowFlakeIdGenerator idGenerator= new SnowFlakeIdGenerator(0L,0L);for (int i = 0; i < 1000; i++) {

System.out.println(idGenerator.generator());

}

}

});

pool.submit(newRunnable() {

@Overridepublic voidrun() {

SnowFlakeIdGenerator idGenerator1= new SnowFlakeIdGenerator(0,1L);for (int i = 0; i < 1000; i++) {

System.out.println(idGenerator1.generator());

}

}

});

pool.shutdown();

}

}

雪花算法优点：

占用空间比uuid小。由于返回的是一个长整型long，所以数据库字段可使用bigint属性创建，实际最大8字节。

粗略有序。通过时间戳+机器号+seq自增的设计实现了粗略有序，毫秒级内单机有序，多机无序，毫秒级间有序。作为InnoDB主键索引的话，降低页分裂的可能。

没有依赖于数据库等中间件，不受中间件限制。

雪花算法的缺点：

趋势递增：由于seq放在末位，会暴露业务信息，例如竞争对手可以通过ID判断出每天大致的业务量。

时间同步：依赖于系统时间，电子时间是需要同步的，例如每4年同步一次闰秒，可能会影响ID的生成。

4、开源项目——vesta-id-generator

自定义设计主要学习《可伸缩服务架构-框架与中间件》中的具体代码实现，snowflake的优化版。

书上提供的开源项目地址删除了，从github上找到了一个地址

采用两种粒度模式的ID：最大峰值型(秒级有序)、最小峰值型(毫秒级有序)

--两种类型的最大区别是：时间+序列号占用位数不同--最大峰值型(秒级有序)

--版本 ： 1bit 0或1，默认0，一个版本可坚持30年，两个就是60年了

--类型 ： 1bit 0或1，控制粒度

--生成方式 : 2bit 00或01或10或11：标识三种发布模式。

--秒级时间 : 30bit 秒级时间从0-2^30-1,2^30/60/60/24/365=34,可使用30年，毫秒级也是。

--序列号 : 20bit

--机器号 : 10bit 将序列号调整到机器号之前，避免递增趋势--最小峰值型(毫秒级有序)

--版本 ： 1bit

--类型 ： 1bit

--生成方式 : 2bit

--毫秒级 : 40bit

--序列号 : 10bit

--机器号 : 10bit