來(lái)自公眾號(hào)：程序員內(nèi)點(diǎn)事
作者程序員內(nèi)點(diǎn)事
不了解分布式ID的同學(xué)笛钝，先行去看《一口氣說(shuō)出 9種 分布式ID生成方式质况，面試官有點(diǎn)懵了》溫習(xí)一下基礎(chǔ)知識(shí)，這里就不再贅述了
美團(tuán)（Leaf）
Leaf是美團(tuán)推出的一個(gè)分布式ID生成服務(wù)玻靡，名字取自德國(guó)哲學(xué)家结榄、數(shù)學(xué)家萊布尼茨的一句話(huà)：“There are no two identical leaves in the world.”（“世界上沒(méi)有兩片相同的樹(shù)葉”），取個(gè)名字都這么有寓意囤捻，美團(tuán)程序員牛掰熬世省！
Leaf的優(yōu)勢(shì)：高可靠蝎土、低延遲视哑、全局唯一等特點(diǎn)。
目前主流的分布式ID生成方式誊涯，大致都是基于數(shù)據(jù)庫(kù)號(hào)段模式和雪花算法（snowflake）挡毅，而美團(tuán)（Leaf）剛好同時(shí)兼具了這兩種方式，可以根據(jù)不同業(yè)務(wù)場(chǎng)景靈活切換暴构。
接下來(lái)結(jié)合實(shí)戰(zhàn)跪呈，詳細(xì)的介紹一下Leaf的Leaf-segment號(hào)段模式和Leaf-snowflake模式
一、 Leaf-segment號(hào)段模式
Leaf-segment號(hào)段模式是對(duì)直接用數(shù)據(jù)庫(kù)自增ID充當(dāng)分布式ID的一種優(yōu)化取逾，減少對(duì)數(shù)據(jù)庫(kù)的頻率操作耗绿。相當(dāng)于從數(shù)據(jù)庫(kù)批量的獲取自增ID，每次從數(shù)據(jù)庫(kù)取出一個(gè)號(hào)段范圍砾隅，例如 (1,1000] 代表1000個(gè)ID误阻，業(yè)務(wù)服務(wù)將號(hào)段在本地生成1~1000的自增ID并加載到內(nèi)存.。
大致的流程入下圖所示：
號(hào)段耗盡之后再去數(shù)據(jù)庫(kù)獲取新的號(hào)段，可以大大的減輕數(shù)據(jù)庫(kù)的壓力堕绩。對(duì)max_id字段做一次update操作策幼，update max_id= max_id + step，update成功則說(shuō)明新號(hào)段獲取成功奴紧，新的號(hào)段范圍是(max_id ,max_id +step]特姐。
由于依賴(lài)數(shù)據(jù)庫(kù)，我們先設(shè)計(jì)一下表結(jié)構(gòu)：
CREATE TABLE `leaf_alloc` (
`biz_tag` varchar(128) NOT NULL DEFAULT '' COMMENT '業(yè)務(wù)key',
`max_id` bigint(20) NOT NULL DEFAULT '1' COMMENT '當(dāng)前已經(jīng)分配了的最大id',
`step` int(11) NOT NULL COMMENT '初始步長(zhǎng)黍氮，也是動(dòng)態(tài)調(diào)整的最小步長(zhǎng)',
`description` varchar(256) DEFAULT NULL COMMENT '業(yè)務(wù)key的描述',
`update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '數(shù)據(jù)庫(kù)維護(hù)的更新時(shí)間',
PRIMARY KEY (`biz_tag`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
預(yù)先插入一條測(cè)試的業(yè)務(wù)數(shù)據(jù)
INSERT INTO `leaf_alloc` (`biz_tag`, `max_id`, `step`, `description`, `update_time`) VALUES ('leaf-segment-test', '0', '10', '測(cè)試', '2020-02-28 10:41:03');
biz_tag：針對(duì)不同業(yè)務(wù)需求唐含，用biz_tag字段來(lái)隔離，如果以后需要擴(kuò)容時(shí)沫浆，只需對(duì)biz_tag分庫(kù)分表即可max_id：當(dāng)前業(yè)務(wù)號(hào)段的最大值捷枯，用于計(jì)算下一個(gè)號(hào)段step：步長(zhǎng)，也就是每次獲取ID的數(shù)量description：對(duì)于業(yè)務(wù)的描述专执，沒(méi)啥好說(shuō)的
將Leaf項(xiàng)目下載到本地：https://github.com/Meituan-Dianping/Leaf
修改一下項(xiàng)目中的leaf.properties文件淮捆，添加數(shù)據(jù)庫(kù)配置
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=junkang
leaf.snowflake.enable=false
注意：leaf.snowflake.enable 與 leaf.segment.enable 是無(wú)法同時(shí)開(kāi)啟的，否則項(xiàng)目將無(wú)法啟動(dòng)本股。
配置相當(dāng)?shù)暮?jiǎn)單攀痊，直接啟動(dòng)LeafServerApplication后就OK了，接下來(lái)測(cè)試一下拄显，leaf是基于Http請(qǐng)求的發(fā)號(hào)服務(wù)苟径， LeafController 中只有兩個(gè)方法，一個(gè)號(hào)段接口躬审，一個(gè)snowflake接口棘街，key就是數(shù)據(jù)庫(kù)中預(yù)先插入的業(yè)務(wù)biz_tag。
@RestController
public class LeafController {
private Logger logger = LoggerFactory.getLogger(LeafController.class);
@Autowired
private SegmentService segmentService;
@Autowired
private SnowflakeService snowflakeService;
/**
* 號(hào)段模式
* @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());
}
}
訪(fǎng)問(wèn)：http://127.0.0.1:8080/api/segment/get/leaf-segment-test承边，結(jié)果正常返回遭殉，感覺(jué)沒(méi)毛病，但當(dāng)查了一下數(shù)據(jù)庫(kù)表中數(shù)據(jù)時(shí)發(fā)現(xiàn)了一個(gè)問(wèn)題炒刁。
通常在用號(hào)段模式的時(shí)候恩沽，取號(hào)段的時(shí)機(jī)是在前一個(gè)號(hào)段消耗完的時(shí)候進(jìn)行的，可剛剛才取了一個(gè)ID翔始，數(shù)據(jù)庫(kù)中卻已經(jīng)更新了max_id罗心，也就是說(shuō)leaf已經(jīng)多獲取了一個(gè)號(hào)段，這是什么鬼操作城瞎？
Leaf為啥要這么設(shè)計(jì)呢渤闷？
Leaf 希望能在DB中取號(hào)段的過(guò)程中做到無(wú)阻塞！
當(dāng)號(hào)段耗盡時(shí)再去DB中取下一個(gè)號(hào)段脖镀，如果此時(shí)網(wǎng)絡(luò)發(fā)生抖動(dòng)飒箭，或者DB發(fā)生慢查詢(xún)，業(yè)務(wù)系統(tǒng)拿不到號(hào)段，就會(huì)導(dǎo)致整個(gè)系統(tǒng)的響應(yīng)時(shí)間變慢弦蹂，對(duì)流量巨大的業(yè)務(wù)肩碟，這是不可容忍的。
所以Leaf在當(dāng)前號(hào)段消費(fèi)到某個(gè)點(diǎn)時(shí)凸椿，就異步的把下一個(gè)號(hào)段加載到內(nèi)存中削祈。而不需要等到號(hào)段用盡的時(shí)候才去更新號(hào)段。這樣做很大程度上的降低了系統(tǒng)的風(fēng)險(xiǎn)脑漫。
那么****某個(gè)點(diǎn)到底是什么時(shí)候呢髓抑？
這里做了一個(gè)實(shí)驗(yàn)，號(hào)段設(shè)置長(zhǎng)度為step=10优幸，max_id=1
當(dāng)我拿第一個(gè)ID時(shí)吨拍，看到號(hào)段增加了，1/10
當(dāng)我拿第三個(gè)Id時(shí)网杆，看到號(hào)段又增加了羹饰，3/10
Leaf采用雙buffer的方式，它的服務(wù)內(nèi)部有兩個(gè)號(hào)段緩存區(qū)segment跛璧。當(dāng)前號(hào)段已消耗10%時(shí)严里，還沒(méi)能拿到下一個(gè)號(hào)段，則會(huì)另啟一個(gè)更新線(xiàn)程去更新下一個(gè)號(hào)段追城。
簡(jiǎn)而言之就是Leaf保證了總是會(huì)多緩存兩個(gè)號(hào)段，即便哪一時(shí)刻數(shù)據(jù)庫(kù)掛了燥撞，也會(huì)保證發(fā)號(hào)服務(wù)可以正常工作一段時(shí)間座柱。
通常推薦號(hào)段（segment）長(zhǎng)度設(shè)置為服務(wù)高峰期發(fā)號(hào)QPS的600倍（10分鐘），這樣即使DB宕機(jī)物舒，Leaf仍能持續(xù)發(fā)號(hào)10-20分鐘不受影響色洞。
優(yōu)點(diǎn)：
Leaf服務(wù)可以很方便的線(xiàn)性擴(kuò)展，性能完全能夠支撐大多數(shù)業(yè)務(wù)場(chǎng)景冠胯。
容災(zāi)性高：Leaf服務(wù)內(nèi)部有號(hào)段緩存火诸，即使DB宕機(jī)，短時(shí)間內(nèi)Leaf仍能正常對(duì)外提供服務(wù)荠察。
缺點(diǎn)：
ID號(hào)碼不夠隨機(jī)置蜀，能夠泄露發(fā)號(hào)數(shù)量的信息，不太安全悉盆。
DB宕機(jī)會(huì)造成整個(gè)系統(tǒng)不可用（用到數(shù)據(jù)庫(kù)的都有可能）盯荤。
二、Leaf-snowflake
Leaf-snowflake基本上就是沿用了snowflake的設(shè)計(jì)焕盟，ID組成結(jié)構(gòu)：正數(shù)位（占1比特）+ 時(shí)間戳（占41比特）+ 機(jī)器ID（占5比特）+ 機(jī)房ID（占5比特）+ 自增值（占12比特）秋秤，總共64比特組成的一個(gè)Long類(lèi)型。
Leaf-snowflake不同于原始snowflake算法地方，主要是在workId的生成上灼卢，Leaf-snowflake依靠Zookeeper生成workId绍哎，也就是上邊的機(jī)器ID（占5比特）+ 機(jī)房ID（占5比特）。Leaf中workId是基于ZooKeeper的順序Id來(lái)生成的鞋真，每個(gè)應(yīng)用在使用Leaf-snowflake時(shí)蛇摸，啟動(dòng)時(shí)都會(huì)都在Zookeeper中生成一個(gè)順序Id，相當(dāng)于一臺(tái)機(jī)器對(duì)應(yīng)一個(gè)順序節(jié)點(diǎn)灿巧，也就是一個(gè)workId赶袄。
Leaf-snowflake啟動(dòng)服務(wù)的過(guò)程大致如下：
啟動(dòng)Leaf-snowflake服務(wù)，連接Zookeeper抠藕，在leaf_forever父節(jié)點(diǎn)下檢查自己是否已經(jīng)注冊(cè)過(guò)（是否有該順序子節(jié)點(diǎn)）饿肺。
如果有注冊(cè)過(guò)直接取回自己的workerID（zk順序節(jié)點(diǎn)生成的int類(lèi)型ID號(hào)），啟動(dòng)服務(wù)盾似。
如果沒(méi)有注冊(cè)過(guò)敬辣，就在該父節(jié)點(diǎn)下面創(chuàng)建一個(gè)持久順序節(jié)點(diǎn)，創(chuàng)建成功后取回順序號(hào)當(dāng)做自己的workerID號(hào)零院，啟動(dòng)服務(wù)溉跃。
但Leaf-snowflake對(duì)Zookeeper是一種弱依賴(lài)關(guān)系，除了每次會(huì)去ZK拿數(shù)據(jù)以外告抄，也會(huì)在本機(jī)文件系統(tǒng)上緩存一個(gè)workerID文件撰茎。一旦ZooKeeper出現(xiàn)問(wèn)題，恰好機(jī)器出現(xiàn)故障需重啟時(shí)打洼，依然能夠保證服務(wù)正常啟動(dòng)龄糊。
啟動(dòng)Leaf-snowflake模式也比較簡(jiǎn)單，起動(dòng)本地ZooKeeper募疮，修改一下項(xiàng)目中的leaf.properties文件炫惩，關(guān)閉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=junkang
leaf.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));
}
測(cè)試一下他嚷，訪(fǎng)問(wèn)：http://127.0.0.1:8080/api/snowflake/get/leaf-segment-test
優(yōu)點(diǎn)：
- ID號(hào)碼是趨勢(shì)遞增的8byte的64位數(shù)字，滿(mǎn)足上述數(shù)據(jù)庫(kù)存儲(chǔ)的主鍵要求芭毙。
缺點(diǎn)：
- 依賴(lài)ZooKeeper筋蓖，存在服務(wù)不可用風(fēng)險(xiǎn)（實(shí)在不知道有啥缺點(diǎn)了）
三、Leaf監(jiān)控
請(qǐng)求地址：http://127.0.0.1:8080/cache
針對(duì)服務(wù)自身的監(jiān)控稿蹲，Leaf提供了Web層的內(nèi)存數(shù)據(jù)映射界面扭勉，可以實(shí)時(shí)看到所有號(hào)段的下發(fā)狀態(tài)。比如每個(gè)號(hào)段雙buffer的使用情況苛聘，當(dāng)前ID下發(fā)到了哪個(gè)位置等信息都可以在Web界面上查看涂炎。
總結(jié)
對(duì)于Leaf具體使用哪種模式忠聚，還是根據(jù)具體的業(yè)務(wù)場(chǎng)景使用，本文并沒(méi)有對(duì)Leaf源碼做過(guò)多的分析唱捣，因?yàn)長(zhǎng)eaf 代碼量簡(jiǎn)潔很好閱讀两蟀。后續(xù)還會(huì)把其他幾種分布式ID生成器，依次結(jié)合實(shí)戰(zhàn)介紹給大家震缭，歡迎大家關(guān)注赂毯。
