[[187741]]

在《分布式服務化系統一致性的“最佳實干”》一文中提出了保證系統最終一致性的定期校對模式，在定期校對模式中最常使用的方法是在每個系統間傳遞和保存一個統一的唯一流水號(或稱為traceid)，通過系統間兩兩核對或者第三方統一核對唯一流水號來保證各個系統之間步伐一致、沒有掉隊的行為，也就是系統間狀態一致，在互聯網的世界里，產生唯一流水號的服務系統俗稱發號器。Twitter的Snowflake是一個流行的開源的發號器的實現。Slowfake是由Scala語言實現的，并且文檔簡單、發布模式單一、缺少支持和維護，很難在現實的項目中直接使用。

為了能讓Java領域的小伙伴們在不同的環境下快速使用發號器服務，本文向大家推薦一款自主研發的多場景分布式發號器Vesta，這是由Java語言編寫的，可以通過Jar包的形式嵌入到任何Java開發的項目中，也可以通過服務化或者REST服務發布，發布樣式靈活多樣，使用簡單、方便、高效。

Vesta是一款通用的唯一流水號產生器，它具有全局唯一、粗略有序、可反解和可制造等特性，它支持三種發布模式：嵌入發布模式、中心服務器發布模式、REST發布模式，根據業務的性能需求，它可以產生最大峰值型和最小粒度型兩種類型的ID，它的實現架構使其具有高性能，高可用和可伸縮等互聯網產品需要的質量屬性，是一款通用的高性能的發號器產品。

本文聚焦在筆者原創的多場景分布式發號器Vesta的設計、實現、性能評估等方面，同時介紹Vesta的發布模式以及使用方式，并在最后給讀者介紹如何在你的項目中使用Vesta。

1 如何思考和設計

1.1 當前遇到的問題

當前業務系統的ID使用數據庫的自增字段，自增字段完全依賴于數據庫，這在數據庫移植，擴容，洗數據，分庫分表等操作時帶來了很多麻煩。

在數據庫分庫分表時，有一種辦法是通過調整自增字段或者數據庫sequence的步長來達到跨數據庫的ID的唯一性，但仍然是一種強依賴數據庫的解決方案，有諸多的限制，并且強依賴數據庫類型，我們并不推薦這種方法。

1.2 為什么不用UUID

UUID雖然能夠保證ID的唯一性，但是，它無法滿足業務系統需要的很多其他特性，例如：時間粗略有序性，可反解和可制造型。另外，UUID產生的時候使用完全的時間數據，性能比較差，并且UUID比較長，占用空間大，間接導致數據庫性能下降，更重要的是，UUID并不具有有序性，這導致B+樹索引在寫的時候會有過多的隨機寫操作(連續的ID會產生部分順序寫)，另外寫的時候由于不能產生順序的append操作，需要進行insert操作，這會讀取整個B+樹節點到內存，然后插入這條記錄后寫整個節點回磁盤，這種操作在記錄占用空間比較大的情況下，性能下降比較大，具體壓測報告請參考：Mysql性能壓測實踐報告

1.3 需求分析和整理

既然數據庫自增ID和UUID有諸多的限制，我們需要整理一下發號器的需求。

1. 全局唯一

有些業務系統可以使用相對小范圍的唯一性，例如，如果用戶是唯一的，那么同一用戶的訂單采用自增序列在用戶范圍內也是唯一的，但是如果這樣設計，訂單系統就會在邏輯上依賴用戶系統，因此，不如我們保證ID在系統范圍內的全局唯一性更實用。

分布式系統保證全局唯一的一個悲觀策略是使用鎖或者分布式鎖，但是，只要使用了鎖，就會大大的降低性能。

因此，我們決定利用時間的有序性，并且在時間的某個單元下采用自增序列，達到全局的唯一性。

2. 粗略有序

上面討論了UUID的最大問題就是無序的，任何業務都希望生成的ID是有序的，但是，分布式系統中要做到完全有序，就涉及到數據的匯聚，當然要用到鎖或者布式鎖，考慮到效率，只能采用折中的方案，粗略有序，到底有多粗略，目前有兩種主流的方案，一種是秒級有序，一種是毫秒級有序，這里又有一個權衡和取舍，我們決定支持兩種方式，通過配置來決定服務使用其中的一種方式。

3. 可反解

一個 ID 生成之后，ID本身帶有很多信息量，線上排查的時候，我們通常首先看到的是ID，如果根據ID就能知道什么時候產生的，從哪里來的，這樣一個可反解的 ID 可以幫上很多忙。

如果ID 里有了時間而且能反解，在存儲層面就會省下很多傳統的timestamp 一類的字段所占用的空間了，這也是一舉兩得的設計。

4. 可制造

一個系統即使再高可用也不會保證永遠不出問題，出了問題怎么辦，手工處理，數據被污染怎么辦，洗數據，可是手工處理或者洗數據的時候，假如使用數據庫自增字段，ID已經被后來的業務覆蓋了，怎么恢復到系統出問題的時間窗口呢?

所以，我們使用的發號器一定要可復制，可恢復 ，可制造。

5. 高性能

不管哪個業務，訂單也好，商品也好，如果有新記錄插入，那一定是業務的核心功能，對性能的要求非常高，ID生成取決于網絡IO和CPU的性能，CPU一般不是瓶頸，根據經驗，單臺機器TPS應該達到10000/s。

6. 高可用

首先，發號器必須是一個對等的集群，一臺機器掛掉，請求必須能夠轉發到其他機器，另外，重試機制也是必不可少的。最后，如果遠程服務宕機，我們需要有本地的容錯方案，本地庫的依賴方式可以作為高可用的最后一道屏障。

7. 可伸縮

作為一個分布式系統，永遠都不能忽略的就是業務在不斷地增長，業務的絕對容量不是衡量一個系統的唯一標準，要知道業務是永遠增長的，所以，系統設計不但要考慮能承受的絕對容量，還必須考慮業務增長的速度，系統的水平伸縮是否能滿足業務的增長速度是衡量一個系統的另一個重要標準。

1.4 設計與實現

1. 發布模式

根據最終的客戶使用方式，可分為嵌入發布模式，中心服務器發布模式和REST發布模式。

1. 嵌入發布模式：只適用于Java客戶端，提供一個本地的Jar包，Jar包是嵌入式的原生服務，需要提前配置本地機器ID(或者服務啟動時候Zookeeper動態分配唯一的ID,在第二版中實現)，但是不依賴于中心服務器。
2. 中心服務器發布模式：只適用于Java客戶端，提供一個服務的客戶端Jar包，Java程序像調用本地API一樣來調用，但是依賴于中心的ID產生服務器。
3. REST發布模式：中心服務器通過Restful API導出服務，供非Java語言客戶端使用。

發布模式最后會記錄在生成的ID中。也參考下面數據結構段的發布模式相關細節。

2. ID類型

根據時間的位數和序列號的位數，可分為最大峰值型和最小粒度型。

1). 最大峰值型：采用秒級有序，秒級時間占用30位，序列號占用20位

2). 最小粒度型：采用毫秒級有序，毫秒級時間占用40位，序列號占用10位

最大峰值型能夠承受更大的峰值壓力，但是粗略有序的粒度有點大，最小粒度型有較細致的粒度，但是每個毫秒能承受的理論峰值有限，為1k，同一個毫秒如果有更多的請求產生，必須等到下一個毫秒再響應。

ID類型在配置時指定，需要重啟服務才能互相切換。

3. 數據結構

1). 機器ID

10位， 2^10=1024, 也就是最多支持1000+個服務器。中心發布模式和REST發布模式一般不會有太多數量的機器，按照設計每臺機器TPS 1萬/s，10臺服務器就可以有10萬/s的TPS，基本可以滿足大部分的業務需求。

但是考慮到我們在業務服務可以使用內嵌發布方式，對機器ID的需求量變得更大，這里最多支持1024個服務器。

2). 序列號

最大峰值型

20位，理論上每秒內平均可產生2^20= 1048576個ID，百萬級別，如果系統的網絡IO和CPU足夠強大，可承受的峰值達到每毫秒百萬級別。

最小粒度型

10位，每毫秒內序列號總計2^10=1024個, 也就是每個毫秒最多產生1000+個ID，理論上承受的峰值完全不如我們最大峰值方案。

3). 秒級時間/毫秒級時間

最大峰值型

30位，表示秒級時間，2^30/60/60/24/365=34，也就是可使用30+年。

最小粒度型

40位，表示毫秒級時間，2^40/1000/60/60/24/365=34，同樣可以使用30+年。

4). 生成方式

2位，用來區分三種發布模式：嵌入發布模式，中心服務器發布模式，REST發布模式。

• 00：嵌入發布模式
• 01：中心服務器發布模式
• 02：REST發布模式
• 03：保留未用

5). ID類型

1位，用來區分兩種ID類型：最大峰值型和最小粒度型。

• 0：最大峰值型
• 1：最小粒度型

6). 版本

1位，用來做擴展位或者擴容時候的臨時方案。

• 0：默認值，以免轉化為整型再轉化回字符串被截斷
• 1：表示擴展或者擴容中

作為30年后擴展使用，或者在30年后ID將近用光之時，擴展為秒級時間或者毫秒級時間來掙得系統的移植時間窗口，其實只要擴展一位，完全可以再使用30年。

4. 并發

對于中心服務器和REST發布方式，ID生成的過程涉及到網絡IO和CPU操作，ID的生成基本都是內存到高速緩存的操作，沒有IO操作，網絡IO是系統的瓶頸。

相對于CPU計算速度來說網絡IO是瓶頸，因此，ID產生的服務使用多線程的方式，對于ID生成過程中的競爭點time和sequence，我們使用concurrent包的ReentrantLock進行互斥。

5. 機器ID的分配

我們將機器ID分為兩個區段，一個區段服務于中心服務器發布模式和REST發布模式，另外一個區段服務于嵌入發布模式。

0-923：嵌入發布模式，預先配置，(或者由Zookeeper產生，第二版中實現)，最多支持924臺內嵌服務器

924 – 1023：中心服務器發布模式和REST發布模式，最多支持300臺，最大支持300*1萬=300萬/s的TPS

如果嵌入式發布模式和中心服務器發布模式以及REST發布模式的使用量不符合這個比例，我們可以動態調整兩個區間的值來適應。

另外，各個垂直業務之間具有天生的隔離性，每個業務都可以使用最多1024臺服務器。

6. 與Zookeeper集成

對于嵌入發布模式，服務啟動需要連接Zookeeper集群，Zookeeper分配一個0-923區間的一個ID，如果0-923區間的ID被用光，Zookeeper會分配一個大于923的ID，這種情況，拒絕啟動服務。

如果不想使用Zookeeper產生的唯一的機器ID，我們提供缺省的預配的機器ID解決方案，每個使用統一發號器的服務需要預先配置一個默認的機器ID。

注：此功能在第二版中實現。

7. 時間同步

使用Linux的定時任務crontab，定時通過授時服務器虛擬集群(全球有3000多臺服務器)來核準服務器的時間。

ntpdate -u pool.ntp.orgpool.ntp.org 

時間相關的影響以及思考：

1.調整時間是否會影響ID產生功能?

1). 未重啟機器調慢時間，Vesta拋出異常，拒絕產生ID。重啟機器調快時間，調整后正常產生ID，調整時段內沒有ID產生。

2). 重啟機器調慢時間，Vesta將可能產生重復的時間，系統管理員需要保證不會發生這種情況。重啟機器調快時間，調整后正常產生ID，調整時段內沒有ID產生。

每4年一次同步潤秒會不會影響ID產生功能?

1). 原子時鐘和電子時鐘每四年誤差為1秒，也就是說電子時鐘每4年會比原子時鐘慢1秒，所以，每隔四年，網絡時鐘都會同步一次時間，但是本地機器Windows,Linux等不會自動同步時間，需要手工同步，或者使用ntpupdate向網絡時鐘同步。

2). 由于時鐘是調快1秒，調整后不影響ID產生，調整的1s內沒有ID產生。

8. 設計驗證

1. 我們根據不同的信息分段構建一個ID，使ID具有全局唯一，可反解和可制造。
2. 我們使用秒級別時間或者毫秒級別時間以及時間單元內部序列遞增的方法保證ID粗略有序。
3. 對于中心服務器發布模式和REST發布模式，我們使用多線程處理，為了減少多線程間競爭，我們對競爭點time和sequence使用ReentrantLock來進行互斥，由于ReentrantLock內部使用CAS，這比JVM的Synchronized關鍵字性能更好，在千兆網卡的前提下，至少可達到1萬/s以上的TPS。
4. 由于我們支持中心服務器發布模式，嵌入式發布模式和REST發布模式，如果某種模式不可用，可以回退到其他發布模式，如果Zookeeper不可用，可以會退到使用本地預配的機器ID。從而達到服務的最大可用。
5. 由于ID的設計，我們最大支持1024臺服務器，我們將服務器機器號分為兩個區段，一個從0開始向上，一個從128開始向下，并且能夠動態調整分界線，滿足了可伸縮性。

2 如何保證性能需求

一款軟件的發布必須保證滿足性能需求，這通常需要在項目初期提出性能需求，在項目進行中做性能測試來驗證，請參考本文末尾的源碼連接下載源代碼，查看性能測試用例，本章節只討論性能需求和測試結果，以及改進點。

2.1 性能需求

最終的性能驗證要保證每臺服務器的TPS達到1萬/s以上。

2.2 測試環境

筆記本，客戶端服務器跑在同一臺機器

雙核2.4G I3 CPU， 4G內存

2.3 嵌入發布模式壓測結果

設置：

并發數：100

2.4 中心服務器發布模式壓測結果

設置：

并發數：100

2.5 REST發布模式(Netty實現)壓測結果

設置：

并發數：100

Boss線程數：1

Workder線程數：4

測試結果：

2.6 REST發布模式(Spring Boot + Tomcat)壓測結果

設置：

并發數：100

Boss線程數：1

Workder線程數：2

Exececutor線程數：最小25最大200

測試結果：

2.7 性能測試總結

1. 根據測試，Netty服務可到達11000的QPS，而Tomcat只能答道5000左右的QPS。
2. 嵌入發布模式，也就是JVM內部調用最快，沒秒可答道40萬以上。可見線上服務的瓶頸在網絡IO以及網絡IO的處理上。
3. 使用Dubbo導入導出的中心服務器發布模式的QPS只有不到2000, 這比Tomcat提供的HTTP服務的QPS還要小，這個不符合常理，一方面需要查看是否Dubbo RPC需要優化，包括線程池策略，序列化協議，通信協議等，另外一方面REST使用apache ab測試，嵌入式發布模式使用自己寫的客戶端測試，是否測試工具存在一定的差異。
4. 測試過程中發現loopback虛擬網卡達到30+M的流量，沒有到達千兆網卡的極限，雙核心CPU占用率已經接近200%，也就是CPU已經到達瓶頸。

參考上面總結第三條，中心服務器的性能問題需要在后期版本跟進和優化。

3 如何快速使用

Vesta多場景分布式發號器支持嵌入發布模式、中心服務器發布模式、REST發布模式，每種發布 模式的API文檔以及使用向導可參項目主頁的文檔連接。

3.1 安裝與啟動

1. 下載最新版本的REST發布模式的發布包

點擊下載：

vesta-rest-netty-0.0.1-bin.tar.gz

如果你通過源代碼方式安裝Vesta的發布包到你的Maven私服，你可以直接從你的Maven私服下載此安裝包：

wget http://ip:port/nexus/content/groups/public/com/robert/vesta/vesta-rest-netty/0.0.1/vesta-rest-netty-0.0.1-bin.tar.gz

2. 解壓發布包到任意目錄

解壓：

tar xzvf vesta-rest-netty-0.0.1-bin.tar.gz

3. 解壓后更改屬性文件

屬性文件：

vesta-rest-netty-0.0.1/conf/vesta-rest-netty.properties

文件內容：

vesta.machine=1022

vesta.genMethod=2

vesta.type=0

注意：

機器ID為1022, 如果你有多臺機器，遞減機器ID，同一服務中機器ID不能重復。

genMethod為2表示使用嵌入發布模式

type為0, 表示最大峰值型，如果想要使用最小粒度型，則設置為1

4. REST發布模式的默認端口為8088,你可以通過更改啟動文件來更改端口號,這里以10010為例

啟動文件：

vesta-rest-netty/target/vesta-rest-netty-0.0.1/bin/server.sh

文件內容：

port=10010

5. 修改啟動腳本，并且賦予執行權限

進入目錄：

cd vesta-rest-netty-0.0.1/bin 

執行命令：

chmod 755 * 

6. 啟動服務

進入目錄：

cd vesta-rest-netty-0.0.1/bin 

執行命令：

./start.sh 

7. 如果看到如下消息，服務啟動成功

輸出：

apppath: /home/robert/vesta/vesta-rest-netty-0.0.1  
Vesta Rest Netty Server is started. 

3.2 測試Rest服務

1. 通過URL訪問產生一個ID

命令：

curl  

結果：

1138729511026688

2. 把產生的ID進行反解

命令：

curl  

結果：

{"genMethod":0,"machine":1,"seq":0,"time":12235264,"type":0,"version":0} 

JSON字符串顯示的是反解的ID的各個組成部分的數值。

3. 對產生的日期進行反解

命令：

curl  

結果：

Fri May 22 14:41:04 CST 2015 

4. 使用反解的數據偽造ID

命令：

curl  

結果：

1138729511026688

4 總結思考

發號器作為分布式服務化系統不可或缺的基礎設施之一，它在保證系統正確運行和高可用上發揮著不可替代的作用。而本文介紹了一款原創開源的多場景分布式發號器Vesta，并介紹了Vesta的設計、實現、以及使用方式，讀者在現實項目中可以直接使用它的任何發布模式，既裝既用，讀者也可以借鑒其中的設計思路和思想，開發自己的分布式發號器，除了發號器本身，本文按照一款開源項目的生命周期構思文章結果，從設計、實現、驗證到使用向導，以及論述遺留的問題等，并提供了參考的開源實現，幫助讀者學習如何創建一款平臺類軟件的過程的思路，幫助讀者在技術的道路上發展越來越好。

在《分布式服務化系統一致性的“最佳實干”》一文中提到全局的唯一流水ID可以把一個請求在分布式系統中流轉的路徑聚合，而調用鏈中的spanid可以把聚合的請求路徑通過樹形結構進行展示，讓技術支持人員輕松的發現系統出現的問題，能夠快速定位出現問題的服務節點，提高應急效率。

點擊《如何設計一款多場景分布式發號器(Vesta)》閱讀原文。

【本文為51CTO專欄作者“李艷鵬”的原創稿件，轉載可通過作者簡書號(李艷鵬)或51CTO專欄獲取聯系】

戳這里，看該作者更多好文