9种分布式ID生成之美团（Leaf）实战

2024-03-15 06:12
文章标签 实战 生成 id 分布式 leaf 之美团

本文主要是介绍9种分布式ID生成之美团（Leaf）实战，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

​​​​​

前几天写过一篇《一口气说出 9种 分布式ID生成方式，面试官有点懵了》，里边简单的介绍了九种分布式ID生成方式，但是对于像美团（Leaf）、滴滴（Tinyid）、百度（uid-generator）都是一笔带过。而通过读者留言发现，大家普遍对他们哥三更感兴趣，所以后边会结合实战，详细的对三种分布式ID生成器学习，今天先啃下美团（Leaf）。

不了解分布式ID的同学，先行去看《一口气说出 9种 分布式ID生成方式，面试官有点懵了》温习一下基础知识，这里就不再赘述了

美团（Leaf）

Leaf是美团推出的一个分布式ID生成服务，名字取自德国哲学家、数学家莱布尼茨的一句话：“There are no two identical leaves in the world.”（“世界上没有两片相同的树叶”），取个名字都这么有寓意，美团程序员牛掰啊！

Leaf的优势：高可靠、低延迟、全局唯一等特点。

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

接下来结合实战，详细的介绍一下Leaf的Leaf-segment号段模式和Leaf-snowflake模式

一、 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]。

由于依赖数据库，我们先设计一下表结构：

CREATE TABLE `leaf_alloc` (`biz_tag` varchar(128) NOT NULL DEFAULT '' COMMENT '业务key',`max_id` bigint(20) NOT NULL DEFAULT '1' COMMENT '当前已经分配了的最大id',`step` int(11) NOT NULL COMMENT '初始步长，也是动态调整的最小步长',`description` varchar(256) DEFAULT NULL COMMENT '业务key的描述',`update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '数据库维护的更新时间',PRIMARY KEY (`biz_tag`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

预先插入一条测试的业务数据

INSERT INTO `leaf_alloc` (`biz_tag`, `max_id`, `step`, `description`, `update_time`) VALUES ('leaf-segment-test', '0', '10', '测试', '2020-02-28 10:41:03');
  • 1

  • biz_tag：针对不同业务需求，用biz_tag字段来隔离，如果以后需要扩容时，只需对biz_tag分库分表即可

  • max_id：当前业务号段的最大值，用于计算下一个号段

  • step：步长，也就是每次获取ID的数量

  • description：对于业务的描述，没啥好说的

将Leaf项目下载到本地：https://github.com/Meituan-Dianping/Leaf

修改一下项目中的leaf.properties文件，添加数据库配置

leaf.name=com.sankuai.leaf.opensource.test
leaf.segment.enable=true
leaf.jdbc.url=jdbc:mysql://127.0.0.1:3306/xin-master?useUnicode=true&characterEncoding=utf8
leaf.jdbc.username=junkang
leaf.jdbc.password=junkangleaf.snowflake.enable=false

注意：leaf.snowflake.enable 与 leaf.segment.enable 是无法同时开启的，否则项目将无法启动。

配置相当的简单，直接启动LeafServerApplication后就OK了，接下来测试一下，leaf是基于Http请求的发号服务， LeafController 中只有两个方法，一个号段接口，一个snowflake接口，key就是数据库中预先插入的业务biz_tag。


@RestController
public class LeafController {private Logger logger = LoggerFactory.getLogger(LeafController.class);@Autowiredprivate SegmentService segmentService;@Autowiredprivate SnowflakeService snowflakeService;/*** 号段模式* @param key* @return*/@RequestMapping(value = "/api/segment/get/{key}")public String getSegmentId(@PathVariable("key") String key) {return get(key, segmentService.getId(key));}/*** 雪花算法模式* @param key* @return*/@RequestMapping(value = "/api/snowflake/get/{key}")public String getSnowflakeId(@PathVariable("key") String key) {return get(key, snowflakeService.getId(key));}private String get(@PathVariable("key") String key, Result id) {Result result;if (key == null || key.isEmpty()) {throw new NoKeyException();}result = id;if (result.getStatus().equals(Status.EXCEPTION)) {throw new LeafServerException(result.toString());}return String.valueOf(result.getId());}
}

访问：http://127.0.0.1:8080/api/segment/get/leaf-segment-test，结果正常返回，感觉没毛病，但当查了一下数据库表中数据时发现了一个问题。
在这里插入图片描述
在这里插入图片描述
通常在用号段模式的时候，取号段的时机是在前一个号段消耗完的时候进行的，可刚刚才取了一个ID，数据库中却已经更新了max_id，也就是说leaf已经多获取了一个号段，这是什么鬼操作？
在这里插入图片描述

Leaf为啥要这么设计呢？

Leaf 希望能在DB中取号段的过程中做到无阻塞！

当号段耗尽时再去DB中取下一个号段，如果此时网络发生抖动，或者DB发生慢查询，业务系统拿不到号段，就会导致整个系统的响应时间变慢，对流量巨大的业务，这是不可容忍的。

所以Leaf在当前号段消费到某个点时，就异步的把下一个号段加载到内存中。而不需要等到号段用尽的时候才去更新号段。这样做很大程度上的降低了系统的风险。

那么某个点到底是什么时候呢？

这里做了一个实验，号段设置长度为step=10，max_id=1，
在这里插入图片描述
当我拿第一个ID时，看到号段增加了，1/10
在这里插入图片描述
在这里插入图片描述
当我拿第三个Id时，看到号段又增加了，3/10
在这里插入图片描述
在这里插入图片描述
Leaf采用双buffer的方式，它的服务内部有两个号段缓存区segment。当前号段已消耗10%时，还没能拿到下一个号段，则会另启一个更新线程去更新下一个号段。

简而言之就是Leaf保证了总是会多缓存两个号段，即便哪一时刻数据库挂了，也会保证发号服务可以正常工作一段时间。

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

优点：

  • Leaf服务可以很方便的线性扩展，性能完全能够支撑大多数业务场景。
  • 容灾性高：Leaf服务内部有号段缓存，即使DB宕机，短时间内Leaf仍能正常对外提供服务。

缺点：

  • ID号码不够随机，能够泄露发号数量的信息，不太安全。
  • DB宕机会造成整个系统不可用（用到数据库的都有可能）。
二、Leaf-snowflake

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启动服务的过程大致如下：

  • 启动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.segment.enable=false
#leaf.jdbc.url=jdbc:mysql://127.0.0.1:3306/xin-master?useUnicode=true&characterEncoding=utf8
#leaf.jdbc.username=junkang
#leaf.jdbc.password=junkangleaf.snowflake.enable=true
leaf.snowflake.zk.address=127.0.0.1
leaf.snowflake.port=2181

    /*** 雪花算法模式* @param key* @return*/@RequestMapping(value = "/api/snowflake/get/{key}")public String getSnowflakeId(@PathVariable("key") String key) {return get(key, snowflakeService.getId(key));}

测试一下，访问：http://127.0.0.1:8080/api/snowflake/get/leaf-segment-test
在这里插入图片描述
优点：

  • ID号码是趋势递增的8byte的64位数字，满足上述数据库存储的主键要求。

缺点：

  • 依赖ZooKeeper，存在服务不可用风险（实在不知道有啥缺点了）
三、Leaf监控

请求地址：http://127.0.0.1:8080/cache

针对服务自身的监控，Leaf提供了Web层的内存数据映射界面，可以实时看到所有号段的下发状态。比如每个号段双buffer的使用情况，当前ID下发到了哪个位置等信息都可以在Web界面上查看。

在这里插入图片描述

总结

对于Leaf具体使用哪种模式，还是根据具体的业务场景使用，本文并没有对Leaf源码做过多的分析，因为Leaf 代码量简洁很好阅读。后续还会把其他几种分布式ID生成器，依次结合实战介绍给大家，欢迎大家关注。

今天就说这么多，如果本文对您有一点帮助，希望能得到您一个点赞👍哦

您的认可才是我写作的动力！

 

这篇关于9种分布式ID生成之美团（Leaf）实战的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！


http://www.chinasem.cn/article/811040。

相关文章

网页解析 lxml 库--实战

网页解析 lxml 库--实战

lxml库使用流程 lxml 是 Python 的第三方解析库，完全使用 Python 语言编写，它对 XPath表达式提供了良好的支 持，因此能够了高效地解析 HTML/XML 文档。本节讲解如何通过 lxml 库解析 HTML 文档。 pip install lxml lxm| 库提供了一个 etree 模块，该模块专门用来解析 HTML/XML 文档，下面来介绍一下 lxml 库
阅读更多...
AI一键生成 PPT

AI一键生成 PPT

AI一键生成 PPT 操作步骤 作为一名打工人，是不是经常需要制作各种PPT来分享我的生活和想法。但是，你们知道，有时候灵感来了，时间却不够用了！😩直到我发现了Kimi AI——一个能够自动生成PPT的神奇助手！🌟 什么是Kimi？ 一款月之暗面科技有限公司开发的AI办公工具，帮助用户快速生成高质量的演示文稿。 无论你是职场人士、学生还是教师，Kimi都能够为你的办公文
阅读更多...
性能分析之MySQL索引实战案例

性能分析之MySQL索引实战案例

文章目录 一、前言二、准备三、MySQL索引优化四、MySQL 索引知识回顾五、总结 一、前言 在上一讲性能工具之 JProfiler 简单登录案例分析实战中已经发现SQL没有建立索引问题，本文将一起从代码层去分析为什么没有建立索引？ 开源ERP项目地址：https://gitee.com/jishenghua/JSH_ERP 二、准备 打开IDEA找到登录请求资源路径位置
阅读更多...
pdfmake生成pdf的使用

pdfmake生成pdf的使用

实际项目中有时会有根据填写的表单数据或者其他格式的数据，将数据自动填充到pdf文件中根据固定模板生成pdf文件的需求 文章目录 利用pdfmake生成pdf文件1.下载安装pdfmake第三方包2.封装生成pdf文件的共用配置3.生成pdf文件的文件模板内容4.调用方法生成pdf 利用pdfmake生成pdf文件 1.下载安装pdfmake第三方包 npm i pdfma
阅读更多...
C#实战|大乐透选号器[6]：实现实时显示已选择的红蓝球数量

C#实战|大乐透选号器[6]：实现实时显示已选择的红蓝球数量

哈喽，你好啊，我是雷工。 关于大乐透选号器在前面已经记录了5篇笔记，这是第6篇； 接下来实现实时显示当前选中红球数量，蓝球数量； 以下为练习笔记。 01 效果演示 当选择和取消选择红球或蓝球时，在对应的位置显示实时已选择的红球、蓝球的数量； 02 标签名称 分别设置Label标签名称为：lblRedCount、lblBlueCount
阅读更多...
poj 1258 Agri-Net（最小生成树模板代码）

poj 1258 Agri-Net（最小生成树模板代码）

感觉用这题来当模板更适合。 题意就是给你邻接矩阵求最小生成树啦。~ prim代码：效率很高。172k...0ms。 #include<stdio.h>#include<algorithm>using namespace std;const int MaxN = 101;const int INF = 0x3f3f3f3f;int g[MaxN][MaxN];int n
阅读更多...
poj 1287 Networking（prim or kruscal最小生成树）

poj 1287 Networking（prim or kruscal最小生成树）

题意给你点与点间距离，求最小生成树。 注意点是，两点之间可能有不同的路，输入的时候选择最小的，和之前有道最短路WA的题目类似。 prim代码： #include<stdio.h>const int MaxN = 51;const int INF = 0x3f3f3f3f;int g[MaxN][MaxN];int P;int prim(){bool vis[MaxN];
阅读更多...
poj 2349 Arctic Network uva 10369（prim or kruscal最小生成树）

poj 2349 Arctic Network uva 10369（prim or kruscal最小生成树）

题目很麻烦，因为不熟悉最小生成树的算法调试了好久。 感觉网上的题目解释都没说得很清楚，不适合新手。自己写一个。 题意：给你点的坐标，然后两点间可以有两种方式来通信：第一种是卫星通信，第二种是无线电通信。 卫星通信：任何两个有卫星频道的点间都可以直接建立连接，与点间的距离无关； 无线电通信：两个点之间的距离不能超过D，无线电收发器的功率越大，D越大，越昂贵。 计算无线电收发器D
阅读更多...
hdu 1102 uva 10397（最小生成树prim）

hdu 1102 uva 10397（最小生成树prim）

hdu 1102: 题意： 给一个邻接矩阵，给一些村庄间已经修的路，问最小生成树。 解析： 把已经修的路的权值改为0，套个prim（）。 注意prim 最外层循坏为n-1。 代码： #include <iostream>#include <cstdio>#include <cstdlib>#include <algorithm>#include <cstri
阅读更多...
【生成模型系列（初级）】嵌入（Embedding）方程——自然语言处理的数学灵魂【通俗理解】

【生成模型系列（初级）】嵌入（Embedding）方程——自然语言处理的数学灵魂【通俗理解】

【通俗理解】嵌入（Embedding）方程——自然语言处理的数学灵魂 关键词提炼 #嵌入方程 #自然语言处理 #词向量 #机器学习 #神经网络 #向量空间模型 #Siri #Google翻译 #AlexNet 第一节：嵌入方程的类比与核心概念【尽可能通俗】 嵌入方程可以被看作是自然语言处理中的“翻译机”，它将文本中的单词或短语转换成计算机能够理解的数学形式，即向量。 正如翻译机将一种语言
阅读更多...

Copyright China编程 23002807@qq.com

沪ICP备2023033072号-2