共计 3368 个字符,预计需要花费 9 分钟才能阅读完成。
常见 ID 解决方案的比照
形容 | 长处 | 毛病 | 毛病 |
---|---|---|---|
UUID | UUID 是通用惟一标识码的缩写,其目标是上分布式系统中的所有元素都有惟一的辨识信息,而不须要通过地方控制器来指定惟一标识。 | 1. 升高全局节点的压力,使得主键生成速度更快;2. 生成的主键全局惟一;3. 跨服务器合并数据不便 | 1. UUID 占用 16 个字符,空间占用较多;2. 不是递增有序的数字,数据写入 IO 随机性很大,且索引效率降落 |
数据库主键自增 | MySQL 数据库设置主键且主键主动增长 | 1. INT 和 BIGINT 类型占用空间较小;2. 主键主动增长,IO 写入连续性好;3. 数字类型查问速度优于字符串 | 1. 并发性能不高,受限于数据库性能;2. 分库分表,须要革新,简单;3. 自增:数据量泄露 |
Redis 自增 | Redis 计数器,原子性自增 | 应用内存,并发性能好 | 1. 数据失落;2. 自增:数据量泄露 |
雪花算法(snowflake) | 赫赫有名的雪花算法,分布式 ID 的经典解决方案 | 1. 不依赖内部组件;2. 性能好 | 1. 时钟回拨;2. 趋势递增不是相对递增;3. 不能在一台服务器上部署多个分布式 ID 服务; |
风行的分布式 ID 解决方案
雪花算法(snowflake)
雪花算法是由符号位 + 工夫戳 + 工作机器 id+ 序列号组成
解释
- 符号位为 0,0 示意负数,ID 为负数。
- 工夫戳位不必多说,用来寄存工夫戳,单位是 ms。
- 工作机器 id 位用来寄存机器的 id,通常分为 5 个区域位 + 5 个服务器标识位。
Twitter 的 Snowflake 算法 Java 实现
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());
}
}
}
号段模式
号段模式能够了解为从数据库批量的获取自增 ID,每次从数据库取出一个号段范畴,例如 (1,1000] 代表 1000 个 ID,具体的业务服务将本号段,生成 1~1000 的自增 ID 并加载到内存。表构造如下:
CREATE TABLE id_generator (id int(10) NOT NULL,
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`)
)
- 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
生成形式不强依赖于数据库,不会频繁的拜访数据库,对数据库的压力小很多。
其余解决方案
- 滴滴出品(TinyID)Github 地址:https://github.com/didi/tinyid
- 百度(Uidgenerator)GitHub 地址:https://github.com/baidu/uid-…
- 美团(Leaf)github 地址:https://github.com/Meituan-Di…
正文完