分布式 id 生成策略選型

我們一般對(duì)分布式id會(huì)有什么訴求,一個(gè)好的分布式id生成策略君纫,應(yīng)該具備哪些要素?其實(shí)還是由業(yè)務(wù)決定的(廢話芹彬,啥不是由業(yè)務(wù)決定- -P钏琛),但一些通用的訴求大致可以總結(jié)為以下幾點(diǎn)吧:

  1. 全局唯一性:這是最基本的要求舒帮。
  2. 信息安全:說到id,我們總會(huì)不自覺地想到mysql自增id 会喝,這其實(shí)很不安全,一看id就能大致猜測(cè)出來我們系統(tǒng)每天的業(yè)務(wù)量玩郊,也容易被暴力窮舉肢执。
  3. 高 QPS : 如果因?yàn)?id 生成而成為業(yè)務(wù)的瓶頸,是不是有點(diǎn)尷尬译红?
  4. 趨勢(shì)遞增:在 MySQL InnoDB 引擎中使用的是聚集索引预茄,用 B-tree 的數(shù)據(jù)結(jié)構(gòu)來存儲(chǔ)索引數(shù)據(jù),在主鍵的選擇上面我們應(yīng)該盡量使用有序的主鍵保證寫入性能侦厚。
  5. 高可用 : 如今這年代耻陕,高可用是一個(gè)永遠(yuǎn)逃不開的命題,我們應(yīng)該能在任何時(shí)候刨沦,都能保證id能被生成出來诗宣,局部掛了,不能影響整體服務(wù)想诅。
  6. id 生成要盡量少的依賴其他組件:依賴的組件越多召庞,理論上越?jīng)]法保證高可用(如果依賴組建掛了),也可能意味著你的業(yè)務(wù)方接入代價(jià)會(huì)比較高来破,出錯(cuò)了篮灼,排錯(cuò)代價(jià)也會(huì)比較高

目前市場(chǎng)上流行的方案

UUID

  • 優(yōu)點(diǎn):本地生成,沒有高可用風(fēng)險(xiǎn)徘禁,性能好
  • 缺點(diǎn):長(zhǎng)度過長(zhǎng)诅诱,存儲(chǔ)冗余,且無序不可讀晌坤,查詢效率低

使用MySQL 的 auto_increment

  • 優(yōu)點(diǎn):數(shù)據(jù)庫(kù)生成的 ID 絕對(duì)有序逢艘,高可用實(shí)現(xiàn)方式簡(jiǎn)單(使用兩臺(tái)數(shù)據(jù)庫(kù)分別設(shè)置不同步長(zhǎng),生成不重復(fù) ID 的策略來實(shí)現(xiàn)高可用)
  • 缺點(diǎn):需要獨(dú)立部署數(shù)據(jù)庫(kù)實(shí)例骤菠,成本高它改,有性能瓶頸,上面也說過商乎,絕對(duì)有序會(huì)造成信息安全問題央拖,我們的業(yè)務(wù)量可猜測(cè),窮舉

利用數(shù)據(jù)庫(kù)分段批量生成 ID

在上一個(gè)方案的基礎(chǔ)上鹉戚,改為利用 proxy server 批量獲取鲜戒,每次獲取一個(gè) segment(step 決定大小) 號(hào)段的值。用完之后再去數(shù)據(jù)庫(kù)獲取新的號(hào)段抹凳,可以大大的減輕數(shù)據(jù)庫(kù)的壓力

  • 優(yōu)點(diǎn):基本同上一個(gè)方案遏餐,在上一個(gè)方案基礎(chǔ)上有巨大的性能提升
  • 缺點(diǎn):也基本上同上一個(gè)方案,DB 宕機(jī)仍然會(huì)造成整個(gè)系統(tǒng)不可用赢底。

Redis 生成 ID

Redis 的所有命令操作都是單線程的失都,本身提供像 incr 和 increby 這樣的自增原子命令,所以能保證生成的 ID 肯定是唯一有序的幸冻。

  • 優(yōu)點(diǎn):數(shù)字 ID 天然排序粹庞,redis性能也比較好。
  • 缺點(diǎn):ID 號(hào)碼不夠隨機(jī)洽损,仍然有安全問題庞溜,類似DB方案,仍然強(qiáng)依賴了三方組件 碑定,如果redis不可用流码,會(huì)影響服務(wù)

Twitter 的雪花算法(snowflake)【推薦】

如果大家百度下雪花算法,介紹一大堆延刘。這里仍然作下簡(jiǎn)要介紹旅掂。雪花算法大致來說是一種以劃分命名空間來生成 ID 的一種算法,這種方案把 64-bit 分別劃分成多段访娶,分開來標(biāo)示機(jī)器商虐、時(shí)間等。snowflake 中的 64-bit 分別表示如下圖所示:


image.png

41-bit 的時(shí)間可以表示(1L<<41)/(1000L360024*365)=69 年的時(shí)間崖疤,10-bit 機(jī)器可以分別表示 1024 臺(tái)機(jī)器秘车。如果我們對(duì) IDC 劃分有需求,還可以將 10-bit 分 5-bit 給 IDC劫哼,分 5-bit 給工作機(jī)器叮趴。這樣就可以表示 32 個(gè) IDC,每個(gè) IDC 下可以有 32 臺(tái)機(jī)器权烧,可以根據(jù)自身需求定義眯亦。12 個(gè)自增序列號(hào)可以表示 2^12 = 4096 個(gè) ID伤溉,理論上 snowflake 方案的 QPS 約為 409.6w/s,這種分配方式可以保證在任何一個(gè) IDC 的任何一臺(tái)機(jī)器在任意毫秒內(nèi)生成的 ID 都是不同的妻率。

  • 優(yōu)點(diǎn):基本符合了我們上面提出的各個(gè)要求
  1. 毫秒數(shù)在高位乱顾,自增序列在低位,整個(gè) ID 都是趨勢(shì)遞增的宫静。
  2. 不依賴數(shù)據(jù)庫(kù)等第三方系統(tǒng)走净,生成 ID 的性能也是非常高的。
  3. 可以根據(jù)自身業(yè)務(wù)特性分配 bit 位孤里,非常靈活伏伯。
  • 缺點(diǎn):
  1. 強(qiáng)依賴機(jī)器時(shí)鐘,如果機(jī)器上時(shí)鐘回?fù)埽瑫?huì)導(dǎo)致發(fā)號(hào)重復(fù)或者服務(wù)會(huì)處于不可用狀態(tài)。
  2. 分布式情況下伍绳,我們需要確定機(jī)器的編號(hào),機(jī)器量小的情況下蜓堕,完全可以手工編號(hào),但是有新機(jī)器加入博其,就需要新編號(hào)套才,帶來額外工作量,機(jī)器多的情況下慕淡,手工和配置都是不小的維護(hù)量

總結(jié)

再回顧開頭對(duì)分布式id的需求分析背伴,雪花算法綜合來說是一個(gè)比較優(yōu)的方案。代碼實(shí)現(xiàn)也是百度一下一大把峰髓,這里貼一個(gè)美團(tuán)點(diǎn)評(píng)的實(shí)現(xiàn)傻寂。核心實(shí)現(xiàn)類https://github.com/Meituan-Dianping/Leaf/blob/master/leaf-core/src/main/java/com/sankuai/inf/leaf/snowflake/SnowflakeIDGenImpl.java
對(duì)于上面雪花算法的缺點(diǎn),比如時(shí)鐘回?fù)苄瑱C(jī)器編號(hào)等疾掰,一些三方優(yōu)化過的實(shí)現(xiàn)版本,都有相應(yīng)優(yōu)化徐紧,美團(tuán)也是静檬。比如

  1. 通過弱依賴 zookeeper 解決機(jī)器編號(hào)問題(啟動(dòng)依賴,得到自己的機(jī)器編號(hào)后并级,會(huì)緩存拂檩。后續(xù) zookeeper 可掛,不影響)
  2. 時(shí)鐘回?fù)埽和ㄟ^RPC請(qǐng)求獲得集群中各節(jié)點(diǎn)的機(jī)器時(shí)間嘲碧,取平均值稻励,來判斷本節(jié)點(diǎn)時(shí)鐘是否正常,從而做時(shí)鐘回?fù)艿难a(bǔ)償方案愈涩。仔細(xì)閱讀美團(tuán) github 開源的代碼望抽,貌似并沒有發(fā)現(xiàn)類似實(shí)現(xiàn)加矛,開源的有閹割?應(yīng)該是吧煤篙。下圖大致描述了服務(wù)啟動(dòng)流程圖


    image.png
最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
  • 序言:七十年代末斟览,一起剝皮案震驚了整個(gè)濱河市,隨后出現(xiàn)的幾起案子舰蟆,更是在濱河造成了極大的恐慌,老刑警劉巖狸棍,帶你破解...
    沈念sama閱讀 223,002評(píng)論 6 519
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件身害,死亡現(xiàn)場(chǎng)離奇詭異,居然都是意外死亡草戈,警方通過查閱死者的電腦和手機(jī)塌鸯,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 95,357評(píng)論 3 400
  • 文/潘曉璐 我一進(jìn)店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來唐片,“玉大人丙猬,你說我怎么就攤上這事》丫拢” “怎么了茧球?”我有些...
    開封第一講書人閱讀 169,787評(píng)論 0 365
  • 文/不壞的土叔 我叫張陵,是天一觀的道長(zhǎng)星持。 經(jīng)常有香客問我抢埋,道長(zhǎng),這世上最難降的妖魔是什么督暂? 我笑而不...
    開封第一講書人閱讀 60,237評(píng)論 1 300
  • 正文 為了忘掉前任揪垄,我火速辦了婚禮,結(jié)果婚禮上逻翁,老公的妹妹穿的比我還像新娘饥努。我一直安慰自己,他們只是感情好八回,可當(dāng)我...
    茶點(diǎn)故事閱讀 69,237評(píng)論 6 398
  • 文/花漫 我一把揭開白布酷愧。 她就那樣靜靜地躺著,像睡著了一般缠诅。 火紅的嫁衣襯著肌膚如雪伟墙。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 52,821評(píng)論 1 314
  • 那天滴铅,我揣著相機(jī)與錄音戳葵,去河邊找鬼。 笑死汉匙,一個(gè)胖子當(dāng)著我的面吹牛拱烁,可吹牛的內(nèi)容都是我干的生蚁。 我是一名探鬼主播,決...
    沈念sama閱讀 41,236評(píng)論 3 424
  • 文/蒼蘭香墨 我猛地睜開眼戏自,長(zhǎng)吁一口氣:“原來是場(chǎng)噩夢(mèng)啊……” “哼邦投!你這毒婦竟也來了?” 一聲冷哼從身側(cè)響起擅笔,我...
    開封第一講書人閱讀 40,196評(píng)論 0 277
  • 序言:老撾萬榮一對(duì)情侶失蹤志衣,失蹤者是張志新(化名)和其女友劉穎,沒想到半個(gè)月后猛们,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體念脯,經(jīng)...
    沈念sama閱讀 46,716評(píng)論 1 320
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡,尸身上長(zhǎng)有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 38,794評(píng)論 3 343
  • 正文 我和宋清朗相戀三年弯淘,在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了绿店。 大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點(diǎn)故事閱讀 40,928評(píng)論 1 353
  • 序言:一個(gè)原本活蹦亂跳的男人離奇死亡庐橙,死狀恐怖假勿,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情态鳖,我是刑警寧澤转培,帶...
    沈念sama閱讀 36,583評(píng)論 5 351
  • 正文 年R本政府宣布,位于F島的核電站浆竭,受9級(jí)特大地震影響堡距,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜兆蕉,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 42,264評(píng)論 3 336
  • 文/蒙蒙 一羽戒、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧虎韵,春花似錦易稠、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 32,755評(píng)論 0 25
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至测萎,卻和暖如春亡电,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背硅瞧。 一陣腳步聲響...
    開封第一講書人閱讀 33,869評(píng)論 1 274
  • 我被黑心中介騙來泰國(guó)打工份乒, 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個(gè)月前我還...
    沈念sama閱讀 49,378評(píng)論 3 379
  • 正文 我出身青樓或辖,卻偏偏與公主長(zhǎng)得像瘾英,于是被迫代替她去往敵國(guó)和親。 傳聞我的和親對(duì)象是個(gè)殘疾皇子颂暇,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 45,937評(píng)論 2 361

推薦閱讀更多精彩內(nèi)容