分布式ID解决方案

分布式ID解决方案

---

• 在分布式高并发的应用场景中，ID的生成不像小项目，单纯依靠数据库自增就可以解决
• 分布式ID生成方案需要满足全局唯一的特性，这个是基本要求，ID不能重复
• 尽量是数字类型并趋势递增，保证mysql写入性能（索引）
• 长度尽可能短，能够提高查询效率
• ID生成足够快，满足高并发的要求
• ID不要连续，保证信息的安全性，但是又希望能够趋势递增

---

UUID

特点

说到分布式ID,UUID总是能不假思索，脱口而出，毕竟

• 全球唯一
• 生成方便快捷
• 不连续

作为小项目的ID不存在什么问题，但是作为分布式系统的ID,就存在一些缺点,不利于MySql索引的修改和数据的查询

• 太长
• 是字符串，不是数字，可读性差
• 不是趋势递增
• 信息不安全：基于MAC地址生成UUID的算法可能会造成MAC地址泄露，这个漏洞曾被用于寻找梅丽莎病毒的制作者位置

实现

String str = UUID.randomUUID().toString().toUpperCase().replace("-", "").toLowerCase();

---

数据库主键

特点

数据库主键自增，一般针对MySql（免费，分布式系统可能分库，用Oracle也太浪费钱了吧），用数据库自增主键有以下优点

• 实现简单（感觉还是没有UUID简单，哈哈）
• ID是数字的，并且自增，和MySql特性完美契合
• 具有一定的业务可读性

但是数据库主键自增，也有一定的局限性

• 步长一般是当前数据库的数量，步长一旦确定了，不方便扩容（当然也可以先预留一些扩容的位置，但是预留多少又是个问题，多了ID间隔大，浪费，小了怕不够）,扩容也可以让偏移量为超过已用id的数，然后修改所有数据库服务器的步长，但是当数据库较多时，比较麻烦
• 强依赖DB，当DB异常时整个系统不可用，属于致命问题。配置主从复制可以尽可能的增加可用性，但是数据一致性在特殊情况下难以保证。主从切换时的不一致可能会导致重复发号。
• ID发号性能瓶颈限制在单台MySQL的读写性能

实现

-- mysql
set global auto_increment_increment=2; -- 步长
set global auto_increment_offset=5; -- 初始值偏移量（这个值目前没起作用，有待考究）
-- oralce用Sequence
CREATE SEQUENCE  SEQ_TEST_ID
    MINVALUE 5
    MAXVALUE 999999999999 
    START WITH 5 -- 初始值偏移量
    INCREMENT BY 2 -- 步长
    NOCYCLE
    nocache; 

---

类Snowflake算法

特点

snowflake的结构如下(每部分用-分开):
0 - 0000000000 0000000000 0000000000 0000000000 0 - 00000 - 00000 - 000000000000

• 第一位为未使用，为0
• 接下来的41位为毫秒级时间(41位的长度可以使用69年)
• 后面5位是datacenterId和5位workerId(10位的长度最多支持部署1024个节点）
• 最后12位是毫秒内的计数（12位的计数顺序号支持每个节点每毫秒产生4096个ID序号）

一共加起来刚好64位，为一个Long型(转换成十进制字符串后长度最多19位)

优点：

• 每秒能够生成百万个不同的ID，性能佳
• 时间戳值在高位，中间是固定的机器码，自增的序列在地位，整个ID是趋势递增的
• 能够根据业务场景数据库节点布置灵活挑战bit位划分，灵活度高

缺点：

• 强依赖于机器时钟，如果时钟回拨，会导致重复的ID生成，所以一般基于此的算法发现时钟回拨，都会抛异常处理，阻止ID生成，这可能导致服务不可用
• 在单机上是递增的，但是由于涉及到分布式环境，每台机器上的时钟不可能完全同步，也许有时候也会出现不是全局递增的情况

实现

• Twitter开源的snowflake算法
• Mongodb的objectID
• 百度UidGenerator

---

基于Redis

特点

Redis的INCR命令能够将key中存储的数字值增一，得益于此操作的原子特性，我们能够巧妙地使用此来做分布式ID地生成方案，还可以配合其他如时间戳值、机器标识等联合使用
优点：

• 有序递增，可读性强
• 能够满足一定性能

缺点：

• 强依赖于Redis，可能存在单点问题
• 占用宽带，而且需要考虑网络延时等问题带来地性能冲击。

实现

需要注意的一点是，GenericJackson2JsonRedisSerializer、Jackson2JsonRedisSerializer以及JdkSerializationRedisSerializer序列化方式不支持INCR命令，会抛出value is not an integer or out of range异常，因为这些序列化方式在redis里面存储的是字符串，不支持加减操作
GenericToStringSerializer、StringRedisSerializer将字符串的值直接转为字节数组，所以保存到redis中是数字，所以可以进行加减

//自增方法
public long incr(String key, long delta) {
		if (delta < 0) {
			throw new RuntimeException("递增因子必须大于0");
		}
		return redisTemplate.opsForValue().increment(key, delta);
	}
// 实际使用的redisTemplate，可以直接注入到代码中，直接操作redis
@Bean 
	public RedisTemplate<String, Object> redisTemplate() {
		RedisTemplate<String, Object> redisTemplate = new RedisTemplate<String, Object>();
		RedisSerializer<?> stringSerializer = new StringRedisSerializer();
		redisTemplate.setKeySerializer(stringSerializer);
		redisTemplate.setValueSerializer(stringSerializer);
		redisTemplate.setHashKeySerializer(stringSerializer);
		redisTemplate.setHashValueSerializer(stringSerializer);
		redisTemplate.setDefaultSerializer(stringSerializer);
		redisTemplate.setConnectionFactory(redisConnectionFactory());
		return redisTemplate;
	}

---

美团的Leaf方案

特点

Leaf-segment

依赖数据库，但是每次取id是取一个号段（长度step），用表来实现。biz_tag用来区分业务，max_id表示该biz_tag目前所被分配的ID号段的最大值，step表示每次分配的号段长度。

优点：

• Leaf服务可以很方便的线性扩展，性能完全能够支撑大多数业务场景。
• ID号码是趋势递增的8byte的64位数字，满足上述数据库存储的主键要求。
• 容灾性高：Leaf服务内部有号段缓存，即使DB宕机，短时间内Leaf仍能正常对外提供服务。
• 可以自定义max_id的大小，非常方便业务从原有的ID方式上迁移过来。

缺点：

• ID号码不够随机，能够泄露发号数量的信息，不太安全,比如竞对在两天中午12点分别下单，通过订单id号相减就能大致计算出公司一天的订单量，这个是不能忍受的
• TP999数据波动大，当号段使用完之后还是会hang在更新数据库的I/O上，tg999数据会出现偶尔的尖刺。
• DB宕机会造成整个系统不可用

双buffer优化

  Leaf 取号段的时机是在号段消耗完的时候进行的，也就意味着号段临界点的ID下发时间取决于下一次从DB取回号段的时间，并且在这期间进来的请求也会因为DB号段没有取回来，导致线程阻塞。如果请求DB的网络和DB的性能稳定，这种情况对系统的影响是不大的，但是假如取DB的时候网络发生抖动，或者DB发生慢查询就会导致整个系统的响应时间变慢。
  为此，我们希望DB取号段的过程能够做到无阻塞，不需要在DB取号段的时候阻塞请求线程，即当号段消费到某个点时就异步的把下一个号段加载到内存中。而不需要等到号段用尽的时候才去更新号段。这样做就可以很大程度上的降低系统的TP999指标
  采用双buffer的方式，Leaf服务内部有两个号段缓存区segment。当前号段已下发10%时，如果下一个号段未更新，则另启一个更新线程去更新下一个号段。当前号段全部下发完后，如果下个号段准备好了则切换到下个号段为当前segment接着下发，循环往复

• 每个biz-tag都有消费速度监控，通常推荐segment长度设置为服务高峰期发号QPS的600倍（10分钟），这样即使DB宕机，Leaf仍能持续发号10-20分钟不受影响。
• 每次请求来临时都会判断下个号段的状态，从而更新此号段，所以偶尔的网络抖动不会影响下个号段的更新

Leaf-snowflake方案

Leaf-snowflake方案完全沿用snowflake方案的bit位设计，即是“1+41+10+12”的方式组装ID号。对于workerID的分配，当服务集群数量较小的情况下，完全可以手动配置。Leaf服务规模较大，动手配置成本太高。所以使用Zookeeper持久顺序节点的特性自动对snowflake节点配置wokerID。Leaf-snowflake是按照下面几个步骤启动的：

1. 启动Leaf-snowflake服务，连接Zookeeper，在leaf_forever父节点下检查自己是否已经注册过（是否有该顺序子节点）
2. 如果有注册过直接取回自己的workerID（zk顺序节点生成的int类型ID号），启动服务
3. 如果没有注册过，就在该父节点下面创建一个持久顺序节点，创建成功后取回顺序号当做自己的workerID号，启动服务
   特点：

• 弱依赖ZooKeeper（需要通过ZK分发workId,在本机文件系统上缓存一个workerID文件，可以提高系统可用性）
• 和所有类snowflake算法一样，需要解决时钟问题

实现

-- Leaf-segment批量取id
Begin
UPDATE table SET max_id=max_id+step WHERE biz_tag=xxx
SELECT tag, max_id, step FROM table WHERE biz_tag=xxx
Commit

// Leaf-segment jvm缓存id
AtomicLong atomicLong = new AtomicLong(maxId);
if(atomicLong.get()<=maxId+step) {//如果小于当前号段最大值
	id = atomicLong.getAndIncrement();
}

---