Leaf：美團分佈式ID生成服務開源

Leaf是美團基礎研發平臺推出的一個分佈式ID生成服務，名字取自德國哲學家、數學家萊布尼茨的一句話：「There are no two identical leaves in the world.」Leaf具有高可靠、低延遲、全局惟一等特色。目前已經普遍應用於美團金融、美團外賣、美團酒旅等多個部門。具體的技術細節，可參考此前美團技術博客的一篇文章：《Leaf美團分佈式ID生成服務》。近日，Leaf項目已經在Github上開源：https://github.com/Meituan-Dianping/Leaf，但願能和更多的技術同行一塊兒交流、共建。

Leaf特性

Leaf在設計之初就秉承着幾點要求：

1. 全局惟一，絕對不會出現重複的ID，且ID總體趨勢遞增。
2. 高可用，服務徹底基於分佈式架構，即便MySQL宕機，也能容忍一段時間的數據庫不可用。
3. 高併發低延時，在CentOS 4C8G的虛擬機上，遠程調用QPS可達5W+，TP99在1ms內。
4. 接入簡單，直接經過公司RPC服務或者HTTP調用便可接入。

Leaf誕生

Leaf第一個版本採用了預分發的方式生成ID，便可以在DB之上掛N個Server，每一個Server啓動時，都會去DB拿固定長度的ID List。這樣就作到了徹底基於分佈式的架構，同時由於ID是由內存分發，因此也能夠作到很高效。接下來是數據持久化問題，Leaf每次去DB拿固定長度的ID List，而後把最大的ID持久化下來，也就是並不是每一個ID都作持久化，僅僅持久化一批ID中最大的那一個。這個方式有點像遊戲裏的按期存檔功能，只不過存檔的是將來某個時間下發給用戶的ID，這樣極大地減輕了DB持久化的壓力。

整個服務的具體處理過程以下：

• Leaf Server 1：從DB加載號段[1，1000]。
• Leaf Server 2：從DB加載號段[1001，2000]。
• Leaf Server 3：從DB加載號段[2001，3000]。

用戶經過Round-robin的方式調用Leaf Server的各個服務，因此某一個Client獲取到的ID序列多是：1，1001，2001，2，1002，2002……也多是：1，2，1001，2001，2002，2003，3，4……當某個Leaf Server號段用完以後，下一次請求就會從DB中加載新的號段，這樣保證了每次加載的號段是遞增的。

Leaf數據庫中的號段表格式以下：

+-------------+--------------+------+-----+-------------------+-----------------------------+ | 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 | +-------------+--------------+------+-----+-------------------+-----------------------------+ 

Leaf Server加載號段的SQL語句以下：

Begin UPDATE table SET max_id=max_id+step WHERE biz_tag=xxx SELECT tag, max_id, step FROM table WHERE biz_tag=xxx Commit 

總體上，V1版本實現比較簡單，主要是爲了儘快解決業務層DB壓力的問題，而快速迭代出的一個版本。於是在生產環境中，也發現了些問題。好比：

1. 在更新DB的時候會出現耗時尖刺，系統最大耗時取決於更新DB號段的時間。
2. 當更新DB號段的時候，若是DB宕機或者發生主從切換，會致使一段時間的服務不可用。

Leaf雙Buffer優化

爲了解決這兩個問題，Leaf採用了異步更新的策略，同時經過雙Buffer的方式，保證不管什麼時候DB出現問題，都能有一個Buffer的號段能夠正常對外提供服務，只要DB在一個Buffer的下發的週期內恢復，就不會影響整個Leaf的可用性。

這個版本代碼在線上穩定運行了半年左右，Leaf又遇到了新的問題：

1. 號段長度始終是固定的，假如Leaf原本能在DB不可用的狀況下，維持10分鐘正常工做，那麼若是流量增長10倍就只能維持1分鐘正常工做了。
2. 號段長度設置的過長，致使緩存中的號段遲遲消耗不完，進而致使更新DB的新號段與前一次下發的號段ID跨度過大。

Leaf動態調整Step

假設服務QPS爲Q，號段長度爲L，號段更新週期爲T，那麼Q * T = L。最開始L長度是固定的，致使隨着Q的增加，T會愈來愈小。可是Leaf本質的需求是但願T是固定的。那麼若是L能夠和Q正相關的話，T就能夠趨近一個定值了。因此Leaf每次更新號段的時候，根據上一次更新號段的週期T和號段長度step，來決定下一次的號段長度nextStep：

• T < 15min，nextStep = step * 2
• 15min < T < 30min，nextStep = step
• T > 30min，nextStep = step / 2

至此，知足了號段消耗穩定趨於某個時間區間的需求。固然，面對瞬時流量幾10、幾百倍的暴增，該種方案仍不能知足能夠容忍數據庫在一段時間不可用、系統仍能穩定運行的需求。由於本質上來說，Leaf雖然在DB層作了些容錯方案，可是號段方式的ID下發，最終仍是須要強依賴DB。

MySQL高可用

在MySQL這一層，Leaf目前採起了半同步的方式同步數據，經過公司DB中間件Zebra加MHA作的主從切換。將來追求徹底的強一致，會考慮切換到MySQL Group Replication。

現階段因爲公司數據庫強一致的特性還在演進中，Leaf採用了一個臨時方案來保證機房斷網場景下的數據一致性：

• 多機房部署數據庫，每一個機房一個實例，保證都是跨機房同步數據。
• 半同步超時時間設置到無限大，防止半同步方式退化爲異步複製。

Leaf監控

針對服務自身的監控，Leaf提供了Web層的內存數據映射界面，能夠實時看到全部號段的下發狀態。好比每一個號段雙buffer的使用狀況，當前ID下發到了哪一個位置等信息均可以在Web界面上查看。

Leaf Snowflake

Snowflake，Twitter開源的一種分佈式ID生成算法。基於64位數實現，下圖爲Snowflake算法的ID構成圖。

• 第1位置爲0。
• 第2-42位是相對時間戳，經過當前時間戳減去一個固定的歷史時間戳生成。
• 第43-52位是機器號workerID，每一個Server的機器ID不一樣。
• 第53-64位是自增ID。

這樣經過時間+機器號+自增ID的組合來實現了徹底分佈式的ID下發。

在這裏，Leaf提供了Java版本的實現，同時對Zookeeper生成機器號作了弱依賴處理，即便Zookeeper有問題，也不會影響服務。Leaf在第一次從Zookeeper拿取workerID後，會在本機文件系統上緩存一個workerID文件。即便ZooKeeper出現問題，同時剛好機器也在重啓，也能保證服務的正常運行。這樣作到了對第三方組件的弱依賴，必定程度上提升了SLA。

將來規劃

• 號段加載優化：Leaf目前重啓後的第一次請求仍是會同步加載MySQL，之因此這麼作而非服務初始化加載號段的緣由，主要是MySQL中的Leaf Key並不是必定都被這個Leaf服務節點所加載，若是每一個Leaf節點都在初始化加載全部的Leaf Key會致使號段的大量浪費。所以，將來會在Leaf服務Shutdown時，備份這個服務節點近一天使用過的Leaf Key列表，這樣重啓後會預先從MySQL加載Key List中的號段。
• 單調遞增：簡易的方式，是隻要保證同一時間、同一個Leaf Key都從一個Leaf服務節點獲取ID，便可保證遞增。須要注意的問題是Leaf服務節點切換時，舊Leaf 服務用過的號段須要廢棄。路由邏輯，可採用主備的模型或者每一個Leaf Key 配置路由表的方式來實現。

關於開源

分佈式ID生成的方案有不少種，Leaf開源版本提供了兩種ID的生成方式：

• 號段模式：低位趨勢增加，較少的ID號段浪費，可以容忍MySQL的短期不可用。
• Snowflake模式：徹底分佈式，ID有語義。

讀者能夠按需選擇適合自身業務場景的ID下發方式。但願美團的方案能給予你們一些幫助，同時也但願各位可以一塊兒交流、共建。

Leaf項目Github地址：https://github.com/Meituan-Dianping/Leaf 。

若有任何疑問和問題，歡迎提交至Github issues。