Leaf-分散式ID生成系統

darren__chan 發表於 2019-08-09

本文摘錄於 https://tech.meituan.com/2017/04/21/mt-leaf.html

  作者: 照東   文章連結

業務系統對生成全域性唯一ID的要求有哪些呢?

全域性唯一性:不能出現重複的ID號,這是最基本的要求。

趨勢遞增:主鍵的選擇應該儘量使用有序的主鍵保證寫入效能。

單調遞增:保證下一個ID一定大於上一個ID,例如事務版本號、IM增量訊息、排序等特殊需求。

資訊保安:如果ID是連續的,容易被惡意使用者扒取,所以在一些應用場景下,會需要ID無規則、不規則。



ID生成系統應該做到如下幾點:

平均延遲和TP999延遲都要儘可能低;

可用性5個9;

高QPS。



幾種ID總結:

一.UUID

UUID(Universally Unique Identifier)的標準型式包含32個16進位制數字,以連字號分為五段,形式為8-4-4-4-12的36個字元。

優點:

效能非常高:本地生成,沒有網路消耗。

缺點:

不易於儲存:UUID太長,16位元組128位,通常以36長度的字串表示,很多場景不適用。

資訊不安全:基於MAC地址生成UUID的演算法可能會造成MAC地址洩露,這個漏洞曾被用於尋找梅麗莎病毒的製作者位置。

ID作為主鍵時在特定的環境會存在一些問題,比如做DB主鍵的場景下,UUID就非常不適用:

① MySQL官方有明確的建議主鍵要儘量越短越好[4],36個字元長度的UUID不符合要求。

② 對MySQL索引不利:如果作為資料庫主鍵,在InnoDB引擎下,UUID的無序性可能會引起資料位置頻繁變動,嚴重影響效能。



二.類snowflake方案

這種方案大致來說是一種以劃分名稱空間(UUID也算,由於比較常見,所以單獨分析)來生成ID的一種演算法,這種方案把64-bit分別劃分成多段,分開來標示機器、時間等


這種方式的優缺點是:

優點:

毫秒數在高位,自增序列在低位,整個ID都是趨勢遞增的。

不依賴資料庫等第三方系統,以服務的方式部署,穩定性更高,生成ID的效能也是非常高的。

可以根據自身業務特性分配bit位,非常靈活。

缺點:

強依賴機器時鐘,如果機器上時鐘回撥,會導致發號重複或者服務會處於不可用狀態。



三。資料庫生成

以MySQL舉例,利用給欄位設定auto_increment_increment和auto_increment_offset來保證ID自增,每次業務使用下列SQL讀寫MySQL得到ID號。

begin;

REPLACE INTO Tickets64 (stub) VALUES ('a');

SELECT LAST_INSERT_ID();

commit;


這種方案的優缺點如下:


優點:

非常簡單,利用現有資料庫系統的功能實現,成本小,有DBA專業維護。

ID號單調自增,可以實現一些對ID有特殊要求的業務。

缺點:

強依賴DB,當DB異常時整個系統不可用,屬於致命問題。配置主從複製可以儘可能的增加可用性,但是資料一致性在特殊情況下難以保證。主從切換時的不一致可能會導致重複發號。

ID發號效能瓶頸限制在單臺MySQL的讀寫效能。

對於MySQL效能問題,可用如下方案解決:在分散式系統中我們可以多部署幾臺機器,每臺機器設定不同的初始值,且步長和機器數相等。

比如有兩臺機器。設定步長step為2,TicketServer1的初始值為1(1,3,5,7,9,11…)、TicketServer2的初始值為2(2,4,6,8,10…)。

這是Flickr團隊在2010年撰文介紹的一種主鍵生成策略(Ticket Servers: Distributed Unique Primary Keys on the Cheap )。

如下所示,為了實現上述方案分別設定兩臺機器對應的引數,TicketServer1從1開始發號,TicketServer2從2開始發號,兩臺機器每次發號之後都遞增2。

image

image

這種架構貌似能夠滿足效能的需求,但有以下幾個缺點:

  • 系統水平擴充套件比較困難,比如定義好了步長和機器臺數之後,如果要新增機器該怎麼做?假設現在只有一臺機器發號是1,2,3,4,5(步長是1),這個時候需要擴容機器一臺。可以這樣做:把第二臺機器的初始值設定得比第一臺超過很多,比如14(假設在擴容時間之內第一臺不可能發到14),同時設定步長為2,那麼這臺機器下發的號碼都是14以後的偶數。然後摘掉第一臺,把ID值保留為奇數,比如7,然後修改第一臺的步長為2。讓它符合我們定義的號段標準,對於這個例子來說就是讓第一臺以後只能產生奇數。擴容方案看起來複雜嗎?貌似還好,現在想象一下如果我們線上有100臺機器,這個時候要擴容該怎麼做?簡直是噩夢。所以系統水平擴充套件方案複雜難以實現。
  • ID沒有了單調遞增的特性,只能趨勢遞增,這個缺點對於一般業務需求不是很重要,可以容忍。
  • 資料庫壓力還是很大,每次獲取ID都得讀寫一次資料庫,只能靠堆機器來提高效能。



Leaf這個名字是來自德國哲學家、數學家萊布尼茨的一句話: >There are no two identical leaves in the world > “世界上沒有兩片相同的樹葉”

綜合對比上述幾種方案,每種方案都不完全符合我們的要求。所以Leaf分別在上述第二種和第三種方案上做了相應的優化,實現了Leaf-segment和Leaf-snowflake方案。

Leaf-segment資料庫方案

第一種Leaf-segment方案,在使用資料庫的方案上,做了如下改變: - 原方案每次獲取ID都得讀寫一次資料庫,造成資料庫壓力大。改為利用proxy server批量獲取,每次獲取一個segment(step決定大小)號段的值。用完之後再去資料庫獲取新的號段,可以大大的減輕資料庫的壓力。 - 各個業務不同的發號需求用biz_tag欄位來區分,每個biz-tag的ID獲取相互隔離,互不影響。如果以後有效能需求需要對資料庫擴容,不需要上述描述的複雜的擴容操作,只需要對biz_tag分庫分表就行。

資料庫表設計如下:

+-------------+--------------+------+-----+-------------------+-----------------------------+| Field       | Type         | Null | Key | Default           | Extra                       |
+-------------+--------------+------+-----+-------------------+-----------------------------+| biz_tag     | varchar(128) | NO   | PRI |                   |                             |
| max_id      | bigint(20)   | NO   |     | 1                 |                             |
| step        | int(11)      | NO   |     | NULL              |                             |
| desc        | varchar(256) | YES  |     | NULL              |                             |
| update_time | timestamp    | NO   |     | CURRENT_TIMESTAMP | on update CURRENT_TIMESTAMP |
+-------------+--------------+------+-----+-------------------+-----------------------------+

重要欄位說明:biz_tag用來區分業務,max_id表示該biz_tag目前所被分配的ID號段的最大值,step表示每次分配的號段長度。原來獲取ID每次都需要寫資料庫,現在只需要把step設定得足夠大,比如1000。那麼只有當1000個號被消耗完了之後才會去重新讀寫一次資料庫。讀寫資料庫的頻率從1減小到了1/step,大致架構如下圖所示:

image

image

test_tag在第一臺Leaf機器上是1~1000的號段,當這個號段用完時,會去載入另一個長度為step=1000的號段,假設另外兩臺號段都沒有更新,這個時候第一臺機器新載入的號段就應該是3001~4000。同時資料庫對應的biz_tag這條資料的max_id會從3000被更新成4000,更新號段的SQL語句如下:

BeginUPDATE table SET max_id=max_id+step WHERE biz_tag=xxxSELECT tag, max_id, step FROM table WHERE biz_tag=xxxCommit

這種模式有以下優缺點:

優點:

  • Leaf服務可以很方便的線性擴充套件,效能完全能夠支撐大多數業務場景。
  • ID號碼是趨勢遞增的8byte的64位數字,滿足上述資料庫儲存的主鍵要求。
  • 容災性高:Leaf服務內部有號段快取,即使DB當機,短時間內Leaf仍能正常對外提供服務。
  • 可以自定義max_id的大小,非常方便業務從原有的ID方式上遷移過來。

缺點:

  • ID號碼不夠隨機,能夠洩露發號數量的資訊,不太安全。
  • TP999資料波動大,當號段使用完之後還是會hang在更新資料庫的I/O上,tg999資料會出現偶爾的尖刺。
  • DB當機會造成整個系統不可用。

雙buffer優化

對於第二個缺點,Leaf-segment做了一些優化,簡單的說就是:

Leaf 取號段的時機是在號段消耗完的時候進行的,也就意味著號段臨界點的ID下發時間取決於下一次從DB取回號段的時間,並且在這期間進來的請求也會因為DB號段沒有取回來,導致執行緒阻塞。如果請求DB的網路和DB的效能穩定,這種情況對系統的影響是不大的,但是假如取DB的時候網路發生抖動,或者DB發生慢查詢就會導致整個系統的響應時間變慢。

為此,我們希望DB取號段的過程能夠做到無阻塞,不需要在DB取號段的時候阻塞請求執行緒,即當號段消費到某個點時就非同步的把下一個號段載入到記憶體中。而不需要等到號段用盡的時候才去更新號段。這樣做就可以很大程度上的降低系統的TP999指標。詳細實現如下圖所示:

image

image

採用雙buffer的方式,Leaf服務內部有兩個號段快取區segment。當前號段已下發10%時,如果下一個號段未更新,則另啟一個更新執行緒去更新下一個號段。當前號段全部下發完後,如果下個號段準備好了則切換到下個號段為當前segment接著下發,迴圈往復。

  • 每個biz-tag都有消費速度監控,通常推薦segment長度設定為服務高峰期發號QPS的600倍(10分鐘),這樣即使DB當機,Leaf仍能持續發號10-20分鐘不受影響。

  • 每次請求來臨時都會判斷下個號段的狀態,從而更新此號段,所以偶爾的網路抖動不會影響下個號段的更新。

Leaf高可用容災

對於第三點“DB可用性”問題,我們目前採用一主兩從的方式,同時分機房部署,Master和Slave之間採用 半同步方式[5] 同步資料。同時使用公司Atlas資料庫中介軟體(已開源,改名為 DBProxy )做主從切換。當然這種方案在一些情況會退化成非同步模式,甚至在 非常極端 情況下仍然會造成資料不一致的情況,但是出現的概率非常小。如果你的系統要保證100%的資料強一致,可以選擇使用“類Paxos演算法”實現的強一致MySQL方案,如MySQL 5.7前段時間剛剛GA的 MySQL Group Replication 。但是運維成本和精力都會相應的增加,根據實際情況選型即可。

image

image

同時Leaf服務分IDC部署,內部的服務化框架是“MTthrift RPC”。服務呼叫的時候,根據負載均衡演算法會優先呼叫同機房的Leaf服務。在該IDC內Leaf服務不可用的時候才會選擇其他機房的Leaf服務。同時服務治理平臺OCTO還提供了針對服務的過載保護、一鍵截流、動態流量分配等對服務的保護措施。

Leaf-segment方案可以生成趨勢遞增的ID,同時ID號是可計算的,不適用於訂單ID生成場景,比如競對在兩天中午12點分別下單,通過訂單id號相減就能大致計算出公司一天的訂單量,這個是不能忍受的。面對這一問題,我們提供了 Leaf-snowflake方案。

image

image

Leaf-snowflake方案完全沿用snowflake方案的bit位設計,即是“1+41+10+12”的方式組裝ID號。對於workerID的分配,當服務叢集數量較小的情況下,完全可以手動配置。Leaf服務規模較大,動手配置成本太高。所以使用Zookeeper持久順序節點的特性自動對snowflake節點配置wokerID。Leaf-snowflake是按照下面幾個步驟啟動的:

  1. 啟動Leaf-snowflake服務,連線Zookeeper,在leaf_forever父節點下檢查自己是否已經註冊過(是否有該順序子節點)。
  2. 如果有註冊過直接取回自己的workerID(zk順序節點生成的int型別ID號),啟動服務。
  3. 如果沒有註冊過,就在該父節點下面建立一個持久順序節點,建立成功後取回順序號當做自己的workerID號,啟動服務。

image

image

弱依賴ZooKeeper

除了每次會去ZK拿資料以外,也會在本機檔案系統上快取一個workerID檔案。當ZooKeeper出現問題,恰好機器出現問題需要重啟時,能保證服務能夠正常啟動。這樣做到了對三方元件的弱依賴。一定程度上提高了SLA

解決時鐘問題

因為這種方案依賴時間,如果機器的時鐘發生了回撥,那麼就會有可能生成重複的ID號,需要解決時鐘回退的問題。

image

image

參見上圖整個啟動流程圖,服務啟動時首先檢查自己是否寫過ZooKeeper leaf_forever節點:

  1. 若寫過,則用自身系統時間與leaf_forever/${self}節點記錄時間做比較,若小於leaf_forever/${self}時間則認為機器時間發生了大步長回撥,服務啟動失敗並報警。
  2. 若未寫過,證明是新服務節點,直接建立持久節點leaf_forever/${self}並寫入自身系統時間,接下來綜合對比其餘Leaf節點的系統時間來判斷自身系統時間是否準確,具體做法是取leaf_temporary下的所有臨時節點(所有執行中的Leaf-snowflake節點)的服務IP:Port,然後通過RPC請求得到所有節點的系統時間,計算sum(time)/nodeSize。
  3. 若abs( 系統時間-sum(time)/nodeSize ) < 閾值,認為當前系統時間準確,正常啟動服務,同時寫臨時節點leaf_temporary/${self} 維持租約。
  4. 否則認為本機系統時間發生大步長偏移,啟動失敗並報警。
  5. 每隔一段時間(3s)上報自身系統時間寫入leaf_forever/${self}。

由於強依賴時鐘,對時間的要求比較敏感,在機器工作時NTP同步也會造成秒級別的回退,建議可以直接關閉NTP同步。要麼在時鐘回撥的時候直接不提供服務直接返回ERROR_CODE,等時鐘追上即可。 或者做一層重試,然後上報報警系統,更或者是發現有時鐘回撥之後自動摘除本身節點並報警 ,如下:

 //發生了回撥,此刻時間小於上次發號時間
 if (timestamp < lastTimestamp) {  			  
            long offset = lastTimestamp - timestamp;            if (offset <= 5) {                try {                	//時間偏差大小小於5ms,則等待兩倍時間
                    wait(offset << 1);//wait
                    timestamp = timeGen();                    if (timestamp < lastTimestamp) {                       //還是小於,拋異常並上報
                        throwClockBackwardsEx(timestamp);
                      }    
                } catch (InterruptedException e) {  
                   throw  e;
                }
            } else {                //throw
                throwClockBackwardsEx(timestamp);
            }
        } //分配ID

從上線情況來看,在2017年閏秒出現那一次出現過部分機器回撥,由於Leaf-snowflake的策略保證,成功避免了對業務造成的影響。

Leaf在美團點評公司內部服務包含金融、支付交易、餐飲、外賣、酒店旅遊、貓眼電影等眾多業務線。目前Leaf的效能在4C8G的機器上QPS能壓測到近5w/s,TP999 1ms,已經能夠滿足大部分的業務的需求。每天提供億數量級的呼叫量,作為公司內部公共的基礎技術設施,必須保證高SLA和高效能的服務,我們目前還僅僅達到了及格線,還有很多提高的空間。


  1. 施瓦茨. 高效能MySQL[M]. 電子工業出版社, 2010:162-171.
  2. 維基百科:UUID .
  3. snowflake .
  4. MySQL: Clustered and Secondary Indexes .
  5. 半同步複製 Semisynchronous Replication .



來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/29863023/viewspace-2653215/,如需轉載,請註明出處,否則將追究法律責任。