目錄

闡述背景

Leaf snowflake 模式介紹

Leaf segment 模式介紹

Leaf 改造支持 RPC

闡述背景

不吹噓，不夸張，項目中用到 ID 生成的場景確實挺多。比如業(yè)務(wù)要做冪等的時候，如果沒有合適的業(yè)務(wù)字段去做唯一標(biāo)識，那就需要單獨生成一個唯一的標(biāo)識，這個場景相信大家不陌生。

很多時候為了圖方便可能就是寫一個簡單的 ID 生成工具類，直接開用。做的好點的可能單獨出一個 Jar 包讓其他項目依賴，做的不好的很有可能就是 Copy 了 N 份一樣的代碼。

單獨搞一個獨立的 ID 生成服務(wù)非常有必要，當(dāng)然我們也沒必要自己做造輪子，有現(xiàn)成開源的直接用就是了。如果人手夠，不差錢，自研也可以。

今天為大家介紹一款美團開源的 ID 生成框架 Leaf，在 Leaf 的基礎(chǔ)上稍微擴展下，增加 RPC 服務(wù)的暴露和調(diào)用，提高 ID 獲取的性能。

Leaf 介紹

Leaf 最早期需求是各個業(yè)務(wù)線的訂單 ID 生成需求。在美團早期，有的業(yè)務(wù)直接通過 DB 自增的方式生成 ID，有的業(yè)務(wù)通過 redis 緩存來生成 ID，也有的業(yè)務(wù)直接用 UUID 這種方式來生成 ID。以上的方式各自有各自的問題，因此我們決定實現(xiàn)一套分布式 ID 生成服務(wù)來滿足需求。

具體 Leaf 設(shè)計文檔見：https://tech.meituan.com/2017/04/21/mt-leaf.html^[1]

目前 Leaf 覆蓋了美團點評公司內(nèi)部金融、餐飲、外賣、酒店旅游、貓眼電影等眾多業(yè)務(wù)線。在 4C8G VM 基礎(chǔ)上，通過公司 RPC 方式調(diào)用，QPS 壓測結(jié)果近 5w/s，TP999 1ms。

snowflake 模式

snowflake 是 Twitter 開源的分布式 ID 生成算法，被廣泛應(yīng)用于各種生成 ID 的場景。Leaf 中也支持這種方式去生成 ID。

使用步驟如下：

修改配置 leaf.snowflake.enable=true 開啟 snowflake 模式。

修改配置 leaf.snowflake.zk.address 和 leaf.snowflake.port 為你自己的 Zookeeper 地址和端口。

想必大家很好奇，為什么這里依賴了 Zookeeper 呢？

那是因為 snowflake 的 ID 組成中有 10bit 的 workerId，如下圖：

snowflake組成

一般如果服務(wù)數(shù)量不多的話手動設(shè)置也沒問題，還有一些框架中會采用約定基于配置的方式，比如基于 IP 生成 wokerID，基于 hostname 最后幾位生成 wokerID，手動在機器上配置，手動在程序啟動時傳入等等方式。

Leaf 中為了簡化 wokerID 的配置，所以采用了 Zookeeper 來生成 wokerID。就是用了 Zookeeper 持久順序節(jié)點的特性自動對 snowflake 節(jié)點配置 wokerID。

如果你公司沒有用 Zookeeper，又不想因為 Leaf 去單獨部署 Zookeeper 的話，你可以將源碼中這塊的邏輯改掉，比如自己提供一個生成順序 ID 的服務(wù)來替代 Zookeeper。

segment 模式

segment 是 Leaf 基于數(shù)據(jù)庫實現(xiàn)的 ID 生成方案，如果調(diào)用量不大，完全可以用 Mysql 的自增 ID 來實現(xiàn) ID 的遞增。

Leaf 雖然也是基于 Mysql，但是做了很多的優(yōu)化，下面簡單的介紹下 segment 模式的原理。

首先我們需要在數(shù)據(jù)庫中新增一張表用于存儲 ID 相關(guān)的信息。

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;

biz_tag 用于區(qū)分業(yè)務(wù)類型，比如下單，支付等。如果以后有性能需求需要對數(shù)據(jù)庫擴容，只需要對 biz_tag 分庫分表就行。

max_id 表示該 biz_tag 目前所被分配的 ID 號段的最大值。

step 表示每次分配的號段長度。

下圖是 segment 的架構(gòu)圖：

segment架構(gòu)

從上圖我們可以看出，當(dāng)多個服務(wù)同時對 Leaf 進行 ID 獲取時，會傳入對應(yīng)的 biz_tag，biz_tag 之間是相互隔離的，互不影響。

比如 Leaf 有三個節(jié)點，當(dāng) test_tag 第一次請求到 Leaf1 的時候，此時 Leaf1 的 ID 范圍就是 1~1000。

當(dāng) test_tag 第二次請求到 Leaf2 的時候，此時 Leaf2 的 ID 范圍就是 1001~2000。

當(dāng) test_tag 第三次請求到 Leaf3 的時候，此時 Leaf3 的 ID 范圍就是 2001~3000。

比如 Leaf1 已經(jīng)知道自己的 test_tag 的 ID 范圍是 1~1000，那么后續(xù)請求過來獲取 test_tag 對應(yīng) ID 時候，就會從 1 開始依次遞增，這個過程是在內(nèi)存中進行的，性能高。不用每次獲取 ID 都去訪問一次數(shù)據(jù)庫。

問題一

這個時候又有人說了，如果并發(fā)量很大的話，1000 的號段長度一下就被用完了啊，此時就得去申請下一個范圍，這期間進來的請求也會因為 DB 號段沒有取回來，導(dǎo)致線程阻塞。

放心，Leaf 中已經(jīng)對這種情況做了優(yōu)化，不會等到 ID 消耗完了才去重新申請，會在還沒用完之前就去申請下一個范圍段。并發(fā)量大的問題你可以直接將 step 調(diào)大即可。

問題二

這個時候又有人說了，如果 Leaf 服務(wù)掛掉某個節(jié)點會不會有影響呢？

首先 Leaf 服務(wù)是集群部署，一般都會注冊到注冊中心讓其他服務(wù)發(fā)現(xiàn)。掛掉一個沒關(guān)系，還有其他的 N 個服務(wù)。問題是對 ID 的獲取有問題嗎? 會不會出現(xiàn)重復(fù)的 ID 呢？

答案是沒問題的，如果 Leaf1 掛了的話，它的范圍是 1~1000，假如它當(dāng)前正獲取到了 100 這個階段，然后服務(wù)掛了。服務(wù)重啟后，就會去申請下一個范圍段了，不會再使用 1~1000。所以不會有重復(fù) ID 出現(xiàn)。

Leaf 改造支持 RPC

如果你們的調(diào)用量很大，為了追求更高的性能，可以自己擴展一下，將 Leaf 改造成 Rpc 協(xié)議暴露出去。

首先將 Leaf 的 Spring 版本升級到 5.1.8.RELEASE，修改父 pom.xml 即可。

<spring.version>5.1.8.RELEASE</spring.version>

然后將 Spring Boot 的版本升級到 2.1.6.RELEASE，修改 leaf-server 的 pom.xml。

<spring-boot-dependencies.version>2.1.6.RELEASE</spring-boot-dependencies.version>

還需要在 leaf-server 的 pom 中增加 nacos 相關(guān)的依賴，因為我們 kitty-cloud 是用的 nacos。同時還需要依賴 dubbo，才可以暴露 rpc 服務(wù)。

<dependency><groupId>com.cxytiandi</groupId><artifactId>kitty-spring-cloud-starter-nacos</artifactId><version>1.0-SNAPSHOT</version> </dependency> <dependency><groupId>com.cxytiandi</groupId><artifactId>kitty-spring-cloud-starter-dubbo</artifactId><version>1.0-SNAPSHOT</version> </dependency> <dependency><groupId>org.apache.logging.log4j</groupId><artifactId>log4j-core</artifactId> </dependency>

在 resource 下創(chuàng)建 bootstrap.properties 文件，增加 nacos 相關(guān)的配置信息。

spring.application.name=LeafSnowflake dubbo.scan.base-packages=com.sankuai.inf.leaf.server.controller dubbo.protocol.name=dubbo dubbo.protocol.port=20086 dubbo.registry.address=spring-cloud://localhost spring.cloud.nacos.discovery.server-addr=47.105.66.210:8848 spring.cloud.nacos.config.server-addr=${spring.cloud.nacos.discovery.server-addr}

Leaf 默認暴露的 Rest 服務(wù)是 LeafController 中，現(xiàn)在的需求是既要暴露 Rest 又要暴露 RPC 服務(wù)，所以我們抽出兩個接口。一個是 Segment 模式，一個是 Snowflake 模式。

Segment 模式調(diào)用客戶端

/*** 分布式ID服務(wù)客戶端-Segment模式** @作者 尹吉歡* @個人微信 jihuan900* @微信公眾號 猿天地* @GitHub https://github.com/yinjihuan* @作者介紹 http://cxytiandi.com/about* @時間 2020-04-06 16:20*/ @FeignClient("${kitty.id.segment.name:LeafSegment}") public interface DistributedIdLeafSegmentRemoteService {@RequestMapping(value = "/api/segment/get/{key}")String getSegmentId(@PathVariable("key") String key); }

Snowflake 模式調(diào)用客戶端

/*** 分布式ID服務(wù)客戶端-Snowflake模式** @作者 尹吉歡* @個人微信 jihuan900* @微信公眾號 猿天地* @GitHub https://github.com/yinjihuan* @作者介紹 http://cxytiandi.com/about* @時間 2020-04-06 16:20*/ @FeignClient("${kitty.id.snowflake.name:LeafSnowflake}") public interface DistributedIdLeafSnowflakeRemoteService {@RequestMapping(value = "/api/snowflake/get/{key}")String getSnowflakeId(@PathVariable("key") String key); }

使用方可以根據(jù)使用場景來決定用 RPC 還是 Http 進行調(diào)用，如果用 RPC 就@Reference 注入 Client，如果要用 Http 就用@Autowired 注入 Client。

最后改造 LeafController 同時暴露兩種協(xié)議即可。

@Service(version = "1.0.0", group = "default") @RestController public class LeafController implements DistributedIdLeafSnowflakeRemoteService, DistributedIdLeafSegmentRemoteService {private Logger logger = LoggerFactory.getLogger(LeafController.class);@Autowiredprivate SegmentService segmentService;@Autowiredprivate SnowflakeService snowflakeService;@Overridepublic String getSegmentId(@PathVariable("key") String key) {return get(key, segmentService.getId(key));}@Overridepublic 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());} }

擴展后的源碼參考：https://github.com/yinjihuan/Leaf/tree/rpc_support^[2]

參考資料

[1]

mt-leaf.html: https://tech.meituan.com/2017/04/21/mt-leaf.html

[2]

Leaf/tree/rpc_support: https://github.com/yinjihuan/Leaf/tree/rpc_support

[3]

kitty: https://github.com/yinjihuan/kitty

往期推薦

4種分布式Session的實現(xiàn)方式！老大直呼666...

最簡單的6種防止數(shù)據(jù)重復(fù)提交的方法！(干貨)

關(guān)注下方二維碼，每一天都有干貨！

總結(jié)

以上是生活随笔為你收集整理的超简单的分布式ID生成方案！美团开源框架介绍的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。