麻豆精品三级无码,美女操逼逼,欧美操逼操逼操,丁香五月天啪啪,激情乱伦AV,在线观看A片,成人依人网,久久免费精品

不了解分布式ID的同學(xué)，先行去看《一口氣說出 9種分布式ID生成方式，面試官有點懵了》溫習(xí)一下基礎(chǔ)知識，這里就不再贅述了

美團（Leaf）

Leaf是美團推出的一個分布式ID生成服務(wù)，名字取自德國哲學(xué)家、數(shù)學(xué)家萊布尼茨的一句話：“There are no two identical leaves in the world.”（“世界上沒有兩片相同的樹葉”），取個名字都這么有寓意，美團程序員牛掰啊！

Leaf的優(yōu)勢：高可靠、低延遲、全局唯一等特點。

目前主流的分布式ID生成方式，大致都是基于數(shù)據(jù)庫號段模式和雪花算法（snowflake），而美團（Leaf）剛好同時兼具了這兩種方式，可以根據(jù)不同業(yè)務(wù)場景靈活切換。

接下來結(jié)合實戰(zhàn)，詳細的介紹一下Leaf的Leaf-segment號段模式和Leaf-snowflake模式

一、 Leaf-segment號段模式

Leaf-segment號段模式是對直接用數(shù)據(jù)庫自增ID充當(dāng)分布式ID的一種優(yōu)化，減少對數(shù)據(jù)庫的頻率操作。相當(dāng)于從數(shù)據(jù)庫批量的獲取自增ID，每次從數(shù)據(jù)庫取出一個號段范圍，例如 (1,1000] 代表1000個ID，業(yè)務(wù)服務(wù)將號段在本地生成1~1000的自增ID并加載到內(nèi)存.。

大致的流程入下圖所示：

號段耗盡之后再去數(shù)據(jù)庫獲取新的號段，可以大大的減輕數(shù)據(jù)庫的壓力。對max_id字段做一次update操作，update max_id= max_id + step，update成功則說明新號段獲取成功，新的號段范圍是(max_id ,max_id +step]。

由于依賴數(shù)據(jù)庫，我們先設(shè)計一下表結(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?'初始步長，也是動態(tài)調(diào)整的最小步長',
??`description`?varchar(256)?DEFAULT?NULL?COMMENT?'業(yè)務(wù)key的描述',
??`update_time`?timestamp?NOT?NULL?DEFAULT?CURRENT_TIMESTAMP?ON?UPDATE?CURRENT_TIMESTAMP?COMMENT?'數(shù)據(jù)庫維護的更新時間',
??PRIMARY?KEY?(`biz_tag`)
)?ENGINE=InnoDB?DEFAULT?CHARSET=utf8;

預(yù)先插入一條測試的業(yè)務(wù)數(shù)據(jù)

INSERT?INTO?`leaf_alloc`?(`biz_tag`,?`max_id`,?`step`,?`description`,?`update_time`)?VALUES?('leaf-segment-test',?'0',?'10',?'測試',?'2020-02-28?10:41:03');

biz_tag：針對不同業(yè)務(wù)需求，用biz_tag字段來隔離，如果以后需要擴容時，只需對biz_tag分庫分表即可
max_id：當(dāng)前業(yè)務(wù)號段的最大值，用于計算下一個號段
step：步長，也就是每次獲取ID的數(shù)量
description：對于業(yè)務(wù)的描述，沒啥好說的

將Leaf項目下載到本地：https://github.com/Meituan-Dianping/Leaf

修改一下項目中的leaf.properties文件，添加數(shù)據(jù)庫配置

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?是無法同時開啟的，否則項目將無法啟動。

配置相當(dāng)?shù)暮唵?，直接啟?/span>LeafServerApplication后就OK了，接下來測試一下，leaf是基于Http請求的發(fā)號服務(wù)，?LeafController?中只有兩個方法，一個號段接口，一個snowflake接口，key就是數(shù)據(jù)庫中預(yù)先插入的業(yè)務(wù)biz_tag。

@RestController
public?class?LeafController?{
????private?Logger?logger?=?LoggerFactory.getLogger(LeafController.class);

????@Autowired
????private?SegmentService?segmentService;
????@Autowired
????private?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，結(jié)果正常返回，感覺沒毛病，但當(dāng)查了一下數(shù)據(jù)庫表中數(shù)據(jù)時發(fā)現(xiàn)了一個問題。

通常在用號段模式的時候，取號段的時機是在前一個號段消耗完的時候進行的，可剛剛才取了一個ID，數(shù)據(jù)庫中卻已經(jīng)更新了max_id，也就是說leaf已經(jīng)多獲取了一個號段，這是什么鬼操作？

Leaf為啥要這么設(shè)計呢？

Leaf?希望能在DB中取號段的過程中做到無阻塞！

當(dāng)號段耗盡時再去DB中取下一個號段，如果此時網(wǎng)絡(luò)發(fā)生抖動，或者DB發(fā)生慢查詢，業(yè)務(wù)系統(tǒng)拿不到號段，就會導(dǎo)致整個系統(tǒng)的響應(yīng)時間變慢，對流量巨大的業(yè)務(wù)，這是不可容忍的。

所以Leaf在當(dāng)前號段消費到某個點時，就異步的把下一個號段加載到內(nèi)存中。而不需要等到號段用盡的時候才去更新號段。這樣做很大程度上的降低了系統(tǒng)的風(fēng)險。

那么某個點到底是什么時候呢？

這里做了一個實驗，號段設(shè)置長度為step=10，max_id=1

當(dāng)我拿第一個ID時，看到號段增加了，1/10?

當(dāng)我拿第三個Id時，看到號段又增加了，3/10

Leaf采用雙buffer的方式，它的服務(wù)內(nèi)部有兩個號段緩存區(qū)segment。當(dāng)前號段已消耗10%時，還沒能拿到下一個號段，則會另啟一個更新線程去更新下一個號段。

簡而言之就是Leaf保證了總是會多緩存兩個號段，即便哪一時刻數(shù)據(jù)庫掛了，也會保證發(fā)號服務(wù)可以正常工作一段時間。

通常推薦號段（segment）長度設(shè)置為服務(wù)高峰期發(fā)號QPS的600倍（10分鐘），這樣即使DB宕機，Leaf仍能持續(xù)發(fā)號10-20分鐘不受影響。

優(yōu)點：

Leaf服務(wù)可以很方便的線性擴展，性能完全能夠支撐大多數(shù)業(yè)務(wù)場景。
容災(zāi)性高：Leaf服務(wù)內(nèi)部有號段緩存，即使DB宕機，短時間內(nèi)Leaf仍能正常對外提供服務(wù)。

缺點：

ID號碼不夠隨機，能夠泄露發(fā)號數(shù)量的信息，不太安全。
DB宕機會造成整個系統(tǒng)不可用（用到數(shù)據(jù)庫的都有可能）。

二、Leaf-snowflake

Leaf-snowflake基本上就是沿用了snowflake的設(shè)計，ID組成結(jié)構(gòu)：正數(shù)位（占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來生成的，每個應(yīng)用在使用Leaf-snowflake時，啟動時都會都在Zookeeper中生成一個順序Id，相當(dāng)于一臺機器對應(yīng)一個順序節(jié)點，也就是一個workId。

Leaf-snowflake啟動服務(wù)的過程大致如下：

啟動Leaf-snowflake服務(wù)，連接Zookeeper，在leaf_forever父節(jié)點下檢查自己是否已經(jīng)注冊過（是否有該順序子節(jié)點）。
如果有注冊過直接取回自己的workerID（zk順序節(jié)點生成的int類型ID號），啟動服務(wù)。
如果沒有注冊過，就在該父節(jié)點下面創(chuàng)建一個持久順序節(jié)點，創(chuàng)建成功后取回順序號當(dāng)做自己的workerID號，啟動服務(wù)。

但Leaf-snowflake對Zookeeper是一種弱依賴關(guān)系，除了每次會去ZK拿數(shù)據(jù)以外，也會在本機文件系統(tǒng)上緩存一個workerID文件。一旦ZooKeeper出現(xiàn)問題，恰好機器出現(xiàn)故障需重啟時，依然能夠保證服務(wù)正常啟動。

啟動Leaf-snowflake模式也比較簡單，起動本地ZooKeeper，修改一下項目中的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));
????}