【分布式ID解决方案】怎样生成高可用高性能的分布式系统ID？

什么是分布式系统唯一ID

可能有的小伙伴没有接触过分布式系统，也就没有什么概念，简单通俗的讲：一个程序同时分布在两台服务器上并且同时在运行，这个时候要保证两台服务器的处理数据一致性，那么对应的数据ID应该要全局唯一，这样才能知道告诉程序处理哪条数据，并且保持每台服务器上面的数据一致。

分布式系统唯一ID的生成要求

在分布式高并发的应用场景中，ID的生成不像小项目，单纯依靠数据库自增就可以解决，所以满足以下特点才是最优的：

• 分布式ID生成方案需要满足全局唯一的特性，这个是基本要求，ID不能重复
• 尽量是数字类型并趋势递增，保证mysql写入性能（索引）
• 长度尽可能短，能够提高查询效率
• ID生成足够快，满足高并发的要求
• ID不要连续，保证信息的安全性，但是又希望能够趋势递增

分布式ID生成方案

1.UUID

特点：

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

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

• ID太长
• 生成的是字符串，不是数字，可读性差
• 不是趋势递增
• 信息不安全：基于MAC地址生成UUID的算法可能会造成MAC地址泄露

代码实现：

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

2.数据库主键自增

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

• 实现简单（数据库设置参数即可）
• 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; 

3.Snowflake雪花算法

核心思想：使用一个 64 bit 的 long 型的数字作为全局唯一 id

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
• 美团的Leaf

4.百度UidGenerator

UidGenerator 提供了两种生成唯一ID方式，分别是 DefaultUidGenerator 和 CachedUidGenerator，官方建议如果有性能考虑的话使用 CachedUidGenerator 方式实现。

UidGenerator 也是基于雪花算法snowflake演变而来，只不过它们又有所区别。不同的是UidGenerator 由 1-28-22-13 的格式进行划分。如下表示：
0 - 0000000000 0000000000 00000000 - 0000000000 0000000000 00 - 0000000000000

特点：

• 第1位仍然占用1bit，其值始终是0。
• 第2位开始的28位是时间戳，28-bit位可表示2^28个数，这里不再是以毫秒而是以秒为单位，每个数代表秒则可用（1L<<28）/ (360024365) ≈ 8.51 年的时间。
• 中间的22位 workId （数据中心+工作机器）则由 22-bit位组成，可表示 2^22 = 4194304个工作ID
• 最后由13-bit位构成自增序列，可表示2^13 = 8192个数

其中 workId （机器 id），最多可支持约420w次机器启动。内置实现为在启动时由数据库分配（表名为 WORKER_NODE），默认分配策略为用后即弃，后续可提供复用策略。

DROP TABLE IF EXISTS WORKER_NODE;
CREATE TABLE WORKER_NODE
(
ID BIGINT NOT NULL AUTO_INCREMENT COMMENT 'auto increment id',
HOST_NAME VARCHAR(64) NOT NULL COMMENT 'host name',
PORT VARCHAR(64) NOT NULL COMMENT 'port',
TYPE INT NOT NULL COMMENT 'node type: ACTUAL or CONTAINER',
LAUNCH_DATE DATE NOT NULL COMMENT 'launch date',
MODIFIED TIMESTAMP NOT NULL COMMENT 'modified time',
CREATED TIMESTAMP NOT NULL COMMENT 'created time',
PRIMARY KEY(ID)
)
 COMMENT='DB WorkerID Assigner for UID Generator',ENGINE = INNODB;

DefaultUidGenerator 就是正常的根据时间戳和机器位还有序列号的生成方式，和雪花算法很相似，对于时钟回拨也只是抛异常处理。仅有一些不同，如以秒为为单位而不再是毫秒

CachedUidGenerator 实现 使用 RingBuffer 缓存生成的id。数组每个元素成为一个slot。RingBuffer容量，默认为Snowflake算法中sequence最大值（2^13 = 8192）。可通过 boostPower 配置进行扩容，以提高 RingBuffer 读写吞吐量。
CachedUidGenerator采用了双RingBuffer，Uid-RingBuffer用于存储Uid、Flag-RingBuffer用于存储Uid状态(是否可填充、是否可消费)。
由于数组元素在内存中是连续分配的，可最大程度利用CPU cache以提升性能。但同时会带来「伪共享」FalseSharing问题，为此在Tail、Cursor指针、Flag-RingBuffer中采用了CacheLine 补齐方式。
RingBuffer填充时机：

初始化预填充 RingBuffer初始化时，预先填充满整个RingBuffer。
即时填充 Take消费时，即时检查剩余可用slot量(tail - cursor)，如小于设定阈值，则补全空闲slots。阈值可通过paddingFactor来进行配置
周期填充 通过Schedule线程，定时补全空闲slots。可通过scheduleInterval配置，以应用定时填充功能，并指定Schedule时间间隔

5.美团的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();
}

6.Redis方案实现

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

优点：

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

缺点：

• 强依赖于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;
	}

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

---

文章转载自：https://www.cnblogs.com/yanghanwen/p/12249111.html