文章目录

1、 Leaf-segment号段模式
- 1.1 数据库配置
- 1.2 导入并修改leaf项目
- 1.3 Leaf-segment双buffer模式
- 1.4 Leaf segment监控
- 1.5 优缺点
2.Leaf-snowflake
- 2.1 Leaf-snowflake的启动过程
- 2.2 优缺点

目前主流的分布式ID生成方式，大致都是基于数据库号段模式和雪花算法（snowflake），而美团（Leaf）刚好同时兼具了这两种方式，可以根据不同业务场景灵活切换。

1、 Leaf-segment号段模式

Leaf-segment号段模式是对直接用数据库自增ID充当分布式ID的一种优化，减少对数据库的频率操作。相当于从数据库批量的获取自增ID，每次从数据库取出一个号段范围，例如 (1,1000] 代表1000个ID，业务服务将号段在本地生成1~1000的自增ID并加载到内存。
大致流程如下：

号段耗尽之后再去数据库获取新的号段，可以大大的减轻数据库的压力。对max_id字段做一次update操作，update max_id= max_id + step，update成功则说明新号段获取成功，新的号段范围是(max_id ,max_id +step]。
号段模式有不懂的可以看看《分布式id解决方案—1.4节》

1.1 数据库配置

由于号段模式依赖于数据库表，我们先创建数据库和表：

创建数据库：leaf
创建数据表：

CREATE TABLE `leaf_alloc` (`biz_tag` varchar(128)  NOT NULL DEFAULT '',`max_id` bigint(20) NOT NULL DEFAULT '1',`step` int(11) NOT NULL,`description` varchar(256)  DEFAULT NULL,`update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,PRIMARY KEY (`biz_tag`)
) ENGINE=InnoDB;

初始化数据表：

insert into leaf_alloc(biz_tag, max_id, step, description) values('leaf-segment-test', 1, 2000, 'Test leaf Segment Mode Get Id')

这些字段在插入数据时有哪些注意事项呢？

biz_tag：针对不同业务需求，用biz_tag字段来隔离，如果以后需要扩容时，只需对biz_tag分库分表即可
max_id：当前业务号段的最大值，用于计算下一个号段
step：步长，也就是每次获取ID的数量
description：对于业务的描述，随意写

1.2 导入并修改leaf项目

我们需要先导入Leaf项目：点击此处下载
导入之后的项目如下：

在leaf-server项目下修改配置(leaf.properties)如下：

leaf.name=com.sankuai.leaf.opensource.test
leaf.segment.enable=true
leaf.jdbc.url=jdbc:mysql://localhost:3306/leaf?autoReconnect=true&useUnicode=true&characterEncoding=utf-8&&zeroDateTimeBehavior=CONVERT_TO_NULL&&serverTimezone=GMT%2B8
leaf.jdbc.username=root
leaf.jdbc.password=root
leaf.snowflake.enable=false

注意：leaf.segment和leaf.snowflake务必保证只有一个开启，由于本节使用的是segment（号段模式），所以开启此服务
然后由于我的mysql服务器是8.0.1版本，所以我将pom中的mysql-connector以及druid对做了相应的版本修改，注意如果你的mysql版本是5.x.x版本的就无须任何修改，否则的话就要到父级的pom下修改成和我同样的版本

druid:1.1.10
mysql-connector：8.0.13

启动项目leaf-server
访问地址：http://127.0.0.1:8080/api/segment/get/leaf-segment-test
注意：leaf-segment-test是我们的key，这个key来自于哪儿呢，来自于刚刚我们insert的biz_tag

1.3 Leaf-segment双buffer模式

下面在拓展讲一点：
leaf的号段模式在更新号段时是无阻塞的，当号段耗尽时再去DB中取下一个号段，如果此时网络发生抖动，或者DB发生慢查询，业务系统拿不到号段，就会导致整个系统的响应时间变慢，对流量巨大的业务，这是不可容忍的。

所以Leaf在当前号段消费到某个点时，就异步的把下一个号段加载到内存中。而不需要等到号段用尽的时候才去更新号段。这样做很大程度上的降低了系统的风险。
好，眼见为实，我们看看这个点到底什么时候会发生，由于我们初始化的时候把maxx_id和step设置的太大，我们修改一下，step=10，max_id=1，如下所示：

我们去访问地址：http://127.0.0.1:8080/api/segment/get/leaf-segment-test

我们可以看到我们id生成到2的时候，max_id就变成了11，我们再继续获取id

我们获取到3的时候，max_id就已经变成了21
这是怎么一回事呢？
Leaf-segment采用双buffer的方式，它的服务内部有两个号段缓存区segment。
当前号段已消耗10%时，还没能拿到下一个号段，则会另启一个更新线程去更新下一个号段。
简而言之就是Leaf保证了总是会多缓存两个号段，即便哪一时刻数据库挂了，也会保证发号服务可以正常工作一段时间。

那我们在平时开发时去怎么设置步长呢？

通常推荐号段（segment）长度设置为服务高峰期发号QPS的600倍（10分钟），这样即使DB宕机，Leaf仍能持续发号10-20分钟不受影响。

1.4 Leaf segment监控

访问：http://127.0.0.1:8080/cache
可以看到：

1.5 优缺点

优点：
Leaf服务可以很方便的线性扩展，性能完全能够支撑大多数业务场景。
容灾性高：Leaf服务内部有号段缓存，即使DB宕机，短时间内Leaf仍能正常对外提供服务。
缺点：
ID号码不够随机，能够泄露发号数量的信息，不太安全。
DB宕机会造成整个系统不可用（用到数据库的都有可能）。

2.Leaf-snowflake

在具体实现雪花算法之前，建议大家先去读一下《分布式id解决方案—1.5节》
我简单的给大家说一下雪花算法的原理：
Leaf-snowflake基本上就是沿用了snowflake的设计，ID组成结构：正数位（占1比特）+ 时间戳（占41比特）+ 机器ID（占5比特）+ 机房ID（占5比特）+ 自增值（占12比特），总共64比特组成的一个Long类型。

Leaf-snowflake不同于原始snowflake算法地方，主要是在workId的生成上，Leaf-snowflake依靠Zookeeper生成workId，也就是上边的机器ID（占5比特）+ 机房ID（占5比特）。Leaf中workId是基于ZooKeeper的顺序Id来生成的，每个应用在使用Leaf-snowflake时，启动时都会都在Zookeeper中生成一个顺序Id，相当于一台机器对应一个顺序节点，也就是一个workId。

好了说了那么多，我们看看Leaf-snowflake是怎么启动的？

2.1 Leaf-snowflake的启动过程

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

但Leaf-snowflake对Zookeeper是一种弱依赖关系，除了每次会去ZK拿数据以外，也会在本机文件系统上缓存一个workerID文件。一旦ZooKeeper出现问题，恰好机器出现故障需重启时，依然能够保证服务正常启动。

启动Leaf-snowflake模式也比较简单，启动本地ZooKeeper，修改一下项目中的leaf.properties文件，关闭leaf.segment模式，启用leaf.snowflake模式即可。

leaf.name=com.sankuai.leaf.opensource.test
leaf.segment.enable=false
leaf.snowflake.enable=true
leaf.snowflake.zk.address=127.0.0.1
leaf.snowflake.port=2181

注意：在启动项目之前，请保证已经正常启动zookeeper
访问：http://127.0.0.1:8080/api/snowflake/get/leaf-segment-test
可以看到：

2.2 优缺点

优点：
ID号码是趋势递增的8 byte的64位数字，满足上述数据库存储的主键要求。
缺点：
依赖ZooKeeper，存在服务不可用风险

至此Leaf的两种使用方法就结束了

美团Leaf实战（分布式Id算法）相关推荐

美团（Leaf）分布式ID算法
本文来说下美团(Leaf)分布式ID算法文章目录概述 Leaf特性 Leaf-segment数据库方案双buffer优化 Leaf高可用容灾 Leaf-snowflake方案弱依赖ZooKee ...
美团（Leaf）分布式ID算法(实战)
目录美团(Leaf) 一. Leaf-segment号段模式 Leaf-segment为啥要这么设计呢? 那么某个点到底是什么时候呢? 二.Leaf-snowflake 三.Leaf监控总结以下 ...
美团（Leaf）分布式ID生成器，好用的一批！
不了解分布式ID的同学,先行去看<一口气说出 9种分布式ID生成方式,面试官有点懵了>温习一下基础知识,这里就不再赘述了美团(Leaf) Leaf是美团推出的一个分布式ID生成服务,名 ...
美团leaf生成分布式唯一id
1. 介绍 https://github.com/Meituan-Dianping/Leaf.git 源码改为下载Leaf-feature-spring-boot-starter.zip包本地安装 ...
java id主键_JAVA主键ID生成工具类：改自twitter的分布式ID算法snowflake
祝大家新年快乐,有任何问题可与我联系: 关于snowflake算法的介绍和原理这里不过多说明了,网上有很多. 这里简单描述下SnowflakeUtil的优点: 1.做为底层工具使用,可用于数据库主键. ...
分布式 ID 生成系统 Leaf 的设计思路，源码解读
什么是分布式ID? ID 最大的特点是唯一而分布式 ID,就是指分布式系统下的 ID,它是全局唯一的. 为啥需要分布式ID呢? 这就和唯一息息相关了. 比如我们用 MySQL 存储数据,一 ...
jdbc 自增id 原理_面试被问分布式ID怎么办？滴滴（Tinyid）甩给他
点击" 程序员内点事 "关注,选择" 设置星标 " 坚持学习,好文每日送达! 引言接着<一口气说出 9种分布式ID生成方式,面试官有点懵了>来继 ...
分布式ID生成器的解决方案总结
转载自分布式ID生成器的解决方案总结在互联网的业务系统中,涉及到各种各样的ID,如在支付系统中就会有支付ID.退款ID等.那一般生成ID都有哪些解决方案呢?特别是在复杂的分布式系统业务场景中,我们 ...
分布式id那些事儿(建议收藏)
一.分布式系统 1.1 分布式系统的定义和应用场景分布式系统是由多个独立的计算机节点协同工作,以共同完成一个任务的系统.这些节点通过网络进行通信和协调,共享计算和存储资源,从而实现对更大规模问题的处 ...

美团Leaf实战（分布式Id算法）