常见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...