分布式系統(tǒng)里唯一ID生成幾乎是每個后端開發(fā)都要正面碰一回的問題。不管你是做訂單系統(tǒng)、IM消息、日志追蹤還是優(yōu)惠券發(fā)放只要上了微服務、做了分庫分表就會突然發(fā)現(xiàn)原來單庫自增主鍵那套玩法徹底失靈了。這篇文章我把這些年折騰過的方案一次性拿出來做個匯總從最簡單的UUID到大數(shù)據(jù)量下的號段、增強雪花算法都捋一遍每個方案的原理、坑點、適用場景都會展開講也會給出我的真實選型建議希望能幫你在做技術選型時少走幾條彎路。1. 為什么分布式系統(tǒng)需要唯一ID核心痛點和設計約束1.1 從兩個經(jīng)典業(yè)務場景說起先聊一個最常見的場景訂單號。早期單體應用訂單表就用數(shù)據(jù)庫自增主鍵一張表搞定邏輯簡單查詢也快。但等單量漲到一定程度單表扛不住了你開始分庫分表。這時候問題來了——兩個庫各自維護自增IDA庫生成了1001B庫也可能生成1001訂單號就沖突了。即便你把自增值改掉設成不同的初始值等數(shù)據(jù)量再上漲、需要擴容分庫時這種手工分片的方式也會變成噩夢。再看日志追蹤場景。一次用戶請求經(jīng)過網(wǎng)關、多個微服務、緩存、消息隊列每個環(huán)節(jié)都會打印日志。排障的時候你需要把這次請求的所有日志串起來唯一的辦法就是給整個請求鏈路的每一行日志都帶上同一個traceId。這個ID必須在所有服務節(jié)點上是全局唯一的而且要盡可能生成得快因為每次請求都會用到性能多一點延遲都能被放大成巨大的開銷。這兩個場景背后有一個共同的技術需求在一個沒有全局時鐘、沒有單點數(shù)據(jù)庫、節(jié)點隨時可能擴容縮容的分布式環(huán)境里要生成一個不重復的ID還要滿足業(yè)務對趨勢遞增、安全隱藏等額外要求。這就是分布式唯一ID要解決的完整命題。1.2 唯一ID的四層核心訴求拋開具體方案先梳理清楚分布式唯一ID的設計約束后續(xù)看任何方案都能一眼判斷它合不合適。全局唯一性不用多說這是底線。任何時刻、任何節(jié)點生成的ID都不能重復否則直接導致主鍵沖突、數(shù)據(jù)覆蓋輕則臟數(shù)據(jù)重則線上事故。趨勢遞增性。數(shù)據(jù)庫的B樹索引對有序數(shù)據(jù)最友好。如果ID完全隨機插入時索引頁會頻繁分裂產(chǎn)生大量隨機IO寫入性能會急劇下降。這也是UUID做主鍵被人詬病的核心原因——它唯一但索引不友好。高可用低延遲。ID生成器是所有依賴它的業(yè)務的前置依賴。它掛一秒訂單就下不了消息就發(fā)不出去。生成時間通常在毫秒級甚至微秒級而且必須做高可用部署不能存在單點。信息安全性。訂單ID暗示著業(yè)務量用戶ID可以被遍歷猜測這些在有些業(yè)務里是安全風險。如果生成規(guī)則里直接拼接時間戳、業(yè)務類型外部很容易推算出發(fā)貨量、用戶規(guī)模等敏感數(shù)據(jù)需要做防推算設計。這四層訴求不是每個場景都需要全部滿足但你在選型時必須逐條對照把需求優(yōu)先級排清楚才能選出最合適的方案。2. 六種主流ID生成方案逐一點評2.1 UUID最省事但陷阱很多UUIDUniversally Unique Identifier是很多新手的第一個選擇因為它在任何語言里幾乎都有現(xiàn)成的庫一行代碼就能生成。標準的UUID是128位的十六進制字符串基于時間、節(jié)點標識、隨機數(shù)等要素生成理論上全球唯一。用UUID做業(yè)務主鍵最大的好處是徹底去中心化本機生成不需要任何網(wǎng)絡請求性能極高擴展性無限。但這東西的生產(chǎn)環(huán)境口碑并不好主要問題有三個第一太長。128位轉成字符串是36個字符含連字符如果直接作為數(shù)據(jù)庫主鍵一個二級索引就會多占用不少空間數(shù)據(jù)量大時存儲成本明顯上升。第二完全無序。上文說過隨機性極強的值寫入B樹時會造成頁分裂寫入性能相比自增ID會有明顯下降這在寫密集場景下是硬傷。第三不具備任何業(yè)務含義排障時肉眼完全讀不出任何信息。不過UUID也不是一無是處。在不需要排序、沒有趨勢遞增要求、并發(fā)量極大、且ID只作唯一標識的場景比如消息中間件里的消息ID、異步任務的任務ID它仍然是很實用的選擇。2.2 數(shù)據(jù)庫自增ID最原始單點和性能是硬傷單庫時代的經(jīng)典方案。在MySQL里設置主鍵自增AUTO_INCREMENT每次插入數(shù)據(jù)時自動生成一個順序遞增的ID簡單可靠索引友好對DBA和經(jīng)驗型程序員來說最直觀。但一旦進入分布式環(huán)境自增ID的問題立刻暴露。最明顯的是單點問題——所有節(jié)點都到一個數(shù)據(jù)庫實例取ID這個庫就是整個系統(tǒng)的瓶頸一旦它出問題所有依賴ID的服務全部癱瘓。而且單庫的寫入吞吐量有限通常每秒幾千到幾萬扛不住大流量的沖擊。解決沖突的辦法是把自增起始值按節(jié)點錯開比如A庫從1開始自增B庫從10001開始自增步長都設為10000但這只是權宜之計后續(xù)擴容、節(jié)點數(shù)量變化時起始值和步長都需要重新規(guī)劃工程復雜度很高。這個方案如今只適合兩類場景系統(tǒng)規(guī)模極小、并發(fā)量很低的內(nèi)部工具以及遷移期的過渡方案。真正核心的交易鏈路不建議直接用數(shù)據(jù)庫自增做主鏈路ID生成。2.3 數(shù)據(jù)庫號段模式批量取號的進階玩法號段模式也叫segment模式是對數(shù)據(jù)庫自增的改良思路非常巧妙。與其每生成一個ID就去數(shù)據(jù)庫查一次不如一次從數(shù)據(jù)庫取一批號段放在本地內(nèi)存里業(yè)務用完了再去取下一批。具體做法是在數(shù)據(jù)庫里建一張專門的號段分配表維護每個業(yè)務線的當前最大ID和步長。比如步長設為1000某服務啟動后去數(shù)據(jù)庫執(zhí)行一次更新把當前值從1改成1001然后這1000個號段就歸這個服務獨占內(nèi)存里依次派發(fā)用完了再來取一次號。這個方案把對數(shù)據(jù)庫的訪問頻率降低了幾個數(shù)量級。原來每秒生成一萬個ID需要一萬次數(shù)據(jù)庫操作用了號段模式之后步長足夠大的話數(shù)據(jù)庫的壓力可以忽略不計整體吞吐量能做到幾萬甚至十幾萬每秒。而且ID是趨勢遞增的對索引非常友好。它的代價是什么呢首先是依賴數(shù)據(jù)庫的可用性數(shù)據(jù)庫掛了號段耗盡后就無法生成新ID了需要配合數(shù)據(jù)庫高可用方案才能保證穩(wěn)定其次每個節(jié)點會存在號段浪費某個服務申請了1000個號但只用掉100個就重啟了剩余的900個就作廢了好在號段資源本身不貴這個損耗可以接受。另外因為每個服務在本地按號段派發(fā)多節(jié)點生成的ID區(qū)間是錯開的從整體看全局趨勢遞增但嚴格意義上它不是完全全局有序的對于不需要絕對排序的場景完全沒問題。號段模式在業(yè)界應用非常廣泛很多互聯(lián)網(wǎng)公司早期的分布式ID組件都是基于這個思路做的優(yōu)點是實現(xiàn)門檻低、擴展容易只要加號段步長就能線性提升性能。2.4 緩存中間件INCR高性能與持久化隱患很多團隊用過緩存中間件的原子自增命令比如INCR命令來生成ID。這個操作本身是原子的能夠保證并發(fā)環(huán)境下的唯一性加上中間件本身的高性能可以獲得很高的吞吐量。實現(xiàn)思路也簡單在內(nèi)存里維護一個全局key每次請求執(zhí)行一次自增并返回?？梢杂靡惶煲粋€key的方式實現(xiàn)日期前綴加序號這樣生成的ID還能自帶時間信息也方便按天重置。這個方案的優(yōu)點是性能高、延遲低、實現(xiàn)極簡幾行代碼就能搞定。但它的隱患同樣明顯依賴中間件的持久化機制如果中間件做了RDB快照和AOF日志配置得當?shù)脑捒煽啃赃€湊合但如果用的是純內(nèi)存模式或者持久化策略保守一旦中間件異常重啟自增計數(shù)就可能回退從而產(chǎn)生ID重復后果非常嚴重。另外即使中間件本身是高可用的在故障切換時新的主節(jié)點如果沒有完全同步舊主節(jié)點的自增值同樣可能生成重復ID。需要做帶寬外的補償處理比如把最終ID拼上一個節(jié)點標識位來避免沖突。所以我對這個方案的態(tài)度是它能用但要想清楚能不能接受底層依賴的風險。在一般性業(yè)務里做個排他鎖、計數(shù)器還行如果做交易主鍵這類核心鏈路不推薦。2.5 雪花算法Snowflake時間戳機器位序列號雪花算法可以說是目前分布式唯一ID方案里的主流方案Twitter開源盡管我不建議直接點名公司這里就以這個概念來說明核心思想是把64位二進制拆成時間戳、機器ID、序列號三個部分在單機內(nèi)通過序列號保證每毫秒內(nèi)生成的ID唯一在全局通過時間戳和機器ID保證跨節(jié)點唯一。64位的分配通常是這樣的第1位是符號位固定為0保證ID為正數(shù)接下來41位是毫秒時間戳可以支撐大約69年的使用然后10位是機器ID可以表示1024臺機器最后12位是每毫秒內(nèi)的序列號范圍是0到4095。也就是說單臺機器每毫秒最多能生成4096個ID單機每秒約400萬這個性能非常可觀。雪花算法的優(yōu)勢很明顯ID是趨勢遞增的時間戳本身就是排序依據(jù)索引友好單機純內(nèi)存運算不需要網(wǎng)絡IO生成速度快結構上含有時間戳和機器信息能反推生成時間方便問題排查部署上每個節(jié)點獨立計算不存在中心化依賴高可用性非常好。它也有麻煩。最大的挑戰(zhàn)是時鐘回撥問題。系統(tǒng)時間如果因為NTP校準、運維操作被人為調回去那么生成的ID時間戳部分就可能小于之前的值同一毫秒序列號就算不一樣也會出現(xiàn)同一臺機器在時間戳倒退區(qū)間內(nèi)生成重復ID這是絕對不能接受的。這個問題我會在下面專門花一節(jié)講清楚。2.6 增強版開源方案易用性與運維成本針對原生雪花算法的時鐘回撥問題、以及機器ID分配繁瑣的問題業(yè)界出現(xiàn)了很多增強方案。思路大致上是用數(shù)據(jù)庫或協(xié)調服務來自動管理機器ID在時鐘回撥時采用等待時間追平、或者借用未來時間戳等策略還有一些方案把ID的位數(shù)結構做了調整比如縮短時間戳位數(shù)、增加秒級單位、把序列號位數(shù)加大來提升單秒容量。這類增強型組件的使用體驗通常比純自研好很多集成SDK后業(yè)務只需要調用一個接口就能拿到ID幾乎不需要關心底層細節(jié)。但代價是引入了一個新的基礎設施組件需要單獨部署、配置高可用、監(jiān)控告警一個組件從上線到穩(wěn)定運行往往要投入不少人力和運維精力。選型建議是這樣的如果你的系統(tǒng)規(guī)模還不大但已經(jīng)確定會走向分布式優(yōu)先選擇號段模式或者自研一個簡單的增強雪花算法不要一上來就引入重型組件。只有你的ID生成量級已經(jīng)到了每秒數(shù)萬甚至幾十萬、業(yè)務對ID穩(wěn)定性的要求極高、團隊也有足夠的技術能力去維護才適合把某個成熟的增強組件作為公司級的基礎設施來做。3. 雪花算法深挖位結構、時鐘回撥與代碼實現(xiàn)3.1 64位結構拆解每個bit都不能亂挪雪花算法的魅力在于64個bit沒有一個是浪費的當前通用的位分配如下第1位符號位固定為0。因為Java里的long是有符號整數(shù)如果第一位是1整個數(shù)變成負數(shù)會給后續(xù)使用帶來麻煩。第2到42位時間戳共41位記錄從某個自定義起始時間到當前時間的毫秒數(shù)可以表示約69年。注意這個時間戳不是Unix紀元而是你自己定義的業(yè)務起始時間設計上通常取固定日期這樣同等位數(shù)能表達更長的時間范圍。第43到52位機器ID共10位可以表示0到1023共1024個節(jié)點。部分實現(xiàn)里會拆成5位數(shù)據(jù)中心ID加5位機器ID。第53到64位序列號共12位每毫秒內(nèi)的并發(fā)序列取值范圍0到4095。達到4096后就要等待下一毫秒。理解了位結構你就能明白任何偏移都是可以定制和擴展的。如果你的業(yè)務并發(fā)量沒那么高可以把序列號位數(shù)調少一點把時間戳位數(shù)調多一點延長可用年限如果你的機房數(shù)量少而單機并發(fā)高可以調整數(shù)據(jù)中心位和機器位的比例。這種按需裁剪的能力是雪花算法能長期流行的底層原因。3.2 核心代碼實現(xiàn)一個可用的Java參考版本下面給出一份我自己維護的精簡版雪花算法Java實現(xiàn)你可以直接在項目里參考使用。它主要實現(xiàn)了時間戳拼接、序列號遞增、時鐘回撥檢測這幾個核心邏輯。public class SnowflakeIdGenerator { // 分別定義位數(shù) private static final long START_TIMESTAMP 1700000000000L; // 自定義起始時間戳 private static final long MACHINE_ID_BITS 10L; private static final long MAX_MACHINE_ID (1L MACHINE_ID_BITS) - 1; private static final long SEQUENCE_BITS 12L; private static final long SEQUENCE_MASK (1L SEQUENCE_BITS) - 1; private static final long MACHINE_ID_SHIFT SEQUENCE_BITS; private static final long TIMESTAMP_SHIFT SEQUENCE_BITS MACHINE_ID_BITS; private final long machineId; private long sequence 0L; private long lastTimestamp -1L; public SnowflakeIdGenerator(long machineId) { if (machineId 0 || machineId MAX_MACHINE_ID) { throw new IllegalArgumentException(非法機器ID); } this.machineId machineId; } public synchronized long nextId() { long currentTimestamp System.currentTimeMillis(); // 時鐘回撥檢測 if (currentTimestamp lastTimestamp) { long offset lastTimestamp - currentTimestamp; if (offset 5) { // 回撥超過閾值直接拋異常等運維介入 throw new IllegalStateException(時鐘回撥嚴重拒絕生成ID回撥差值: offset); } // 回撥較小等待原時間追上 while (currentTimestamp lastTimestamp) { currentTimestamp System.currentTimeMillis(); } } if (currentTimestamp lastTimestamp) { sequence (sequence 1) SEQUENCE_MASK; if (sequence 0) { // 當前毫秒序列號用盡自旋等待下一毫秒 currentTimestamp waitNextMillis(lastTimestamp); } } else { // 新的一毫秒開始序列號歸零 sequence 0; } lastTimestamp currentTimestamp; return ((currentTimestamp - START_TIMESTAMP) TIMESTAMP_SHIFT) | (machineId MACHINE_ID_SHIFT) | sequence; } private long waitNextMillis(long lastTimestamp) { long currentTimestamp System.currentTimeMillis(); while (currentTimestamp lastTimestamp) { currentTimestamp System.currentTimeMillis(); } return currentTimestamp; } }這段代碼有幾個關鍵細節(jié)生成方法必須加synchronized否則多線程并發(fā)下序列號會沖突序列號用位運算保證在0到4095之間循環(huán)超過4095自動清零配合等下一毫秒的邏輯就堵住了溢出的可能性時間戳起始值務必設置為某一天不要從1970年開始否則同樣表示69年從2024年算起就遠夠用了但數(shù)字太大會讓ID暴長起始值靠前的話ID數(shù)值小看起來更清爽。3.3 時鐘回撥問題三種處理策略時鐘回撥是雪花算法實戰(zhàn)中遇到概率最高的坑也是生產(chǎn)事故的高發(fā)點。服務器時間被人為調整、NTP同步跳變、虛擬機時鐘漂移都可能導致當前系統(tǒng)時間小于上一次生成ID時的時間。回撥期間時間戳部分變小序列號必須從0開始這就很容易生成一個比之前更小、甚至完全一樣的ID。業(yè)界常見的處理策略有三種你可以根據(jù)自己業(yè)務的容忍度來選策略一是等待追平。檢測到回撥后讓線程自旋等待直到系統(tǒng)時間追平上次生成時間。這個策略最簡單回撥幅度小幾十毫秒內(nèi)的時候體驗很好但如果回撥超過幾秒所有請求都會阻塞服務就會明顯卡頓不適合高并發(fā)場景。策略二是強校驗失敗。回撥一旦發(fā)生直接拋出異常讓請求失敗、走熔斷降級由運維檢查恢復。這個策略最安全適合回撥極罕見且業(yè)務不能容忍錯誤ID的場景代價是一小段時間內(nèi)產(chǎn)生異常率。策略三是借用未來時間戳。把序列號空間擴展一些當回撥發(fā)生時用上一個ID的序列號加一個大偏移來遞增直到追平正常時間。這個策略能保證連續(xù)性但會導致一段時間內(nèi)的ID時間戳是跳躍的如果業(yè)務有嚴格的時間維度統(tǒng)計需要格外注意。我的建議是主默認用等待追平加一個閾值判斷回撥超過閾值就拋異常。這里的閾值可以設成5毫秒既能處理輕微的時鐘抖動又不會讓系統(tǒng)默默錯誤運行。3.4 機房隔離與機器號分配機器ID的分配如果全靠手工配置在上千臺機器的規(guī)模下會讓人崩潰。常見的做法有三個層次一是純配置文件管理適合機器數(shù)量少、變動不頻繁的團隊。每個服務實例的配置中心里寫死一個machineId注意保證唯一性。這個方案實現(xiàn)成本最低但出現(xiàn)重復機器ID時會直接導致ID沖突后果是災難性的。二是基于數(shù)據(jù)庫分配。建一張機器ID分配表服務啟動時向數(shù)據(jù)庫注冊獲取一個未使用的機器ID并做有效期管理服務失聯(lián)后可以回收。這個方案比較可靠但引入了一次注冊依賴。三是基于協(xié)調服務自動分配。利用協(xié)調組的臨時節(jié)點特性服務啟動時創(chuàng)建臨時節(jié)點申請ID斷開連接后臨時節(jié)點自動刪除ID自動釋放。這個方案最自動化比較適合大規(guī)模集群但引入了一個新的基礎組件。實操中還有一種偷懶但有效的辦法不顯式管理機器ID而是把機器ID替換成隨機啟動值每次啟動隨機生成一個0到1023之間的數(shù)字。這種方案在節(jié)點數(shù)很少個位數(shù)時利用率極高但節(jié)點多了之后碰撞概率會不可控不建議正式環(huán)境這么干。4. 方案落地與選型建議不同業(yè)務場景怎么選4.1 選型決策的核心維度先把各維度的權重在你的團隊里排清楚。我一般按下面幾個順序詢問業(yè)務方是否需要趨勢遞增每秒的峰值QPS大概多少ID里能否包含明確的時間信息外部能否通過ID推測業(yè)務量對底層基礎設施的運維能力到什么水平這五個問題問完方案的邊界基本就清晰了。比如高并發(fā)、強遞增、低延遲的交易系統(tǒng)基本直接鎖定雪花鏈路中小規(guī)模、希望簡單可控的內(nèi)容系統(tǒng)號段模式反而比架構更重的方案好用日志系統(tǒng)只要能快速出ID、不需要關心順序UUID也能勝任。4.2 偏向趨勢遞增的訂單場景典型的訂單服務對ID有三個要求絕對全局唯一很強的趨勢遞增性因為訂單表經(jīng)常按時間排序或者使用時間范圍查詢整體延遲要低不能因為ID生成拖慢下單鏈路。在單機性能要求不是特別夸張的情況下我傾向選號段模式。原因很簡單號段模式實現(xiàn)直觀、故障點少一個數(shù)據(jù)庫高可用就能覆蓋整個ID服務的可用性ID的連續(xù)性和遞增性也符合訂單系統(tǒng)的語義。很多訂單號看起來就是幾個數(shù)字在漲運營和客服肉眼就能排序這種可解釋性是雪花ID不具備的。如果訂單量極大、單機號段的頻率還是太高可以加一層本地緩存、調大步長。記得步長不要設成某個固定值就完事建議做成可配置的能根據(jù)業(yè)務峰值動態(tài)調整。4.3 強性能的日志場景日志鏈路traceId的生成環(huán)境比較惡劣——每個服務節(jié)點每處理一次請求都可能要生成一個ID全鏈路上每秒累計可能要生成幾百萬個ID。此時對ID元信息的關注度極低排序要求也不高但性能要求極高。這時候UUID反而可能比雪花算法更合適。因為沒有時間戳和機器位的組裝邏輯上只需要生成隨機數(shù)和格式化字符串單次生成的CPU開銷很小。擴展方面也簡單每臺機器是獨立的系統(tǒng)擴容無需協(xié)調機器ID分配。日志的存儲可以按天分目錄、用搜索引擎建索引無序問題在日志場景里并不突出。如果追求ID里能看出生成時間可以用日期前綴加一段隨機數(shù)或者直接用60位壓縮版的雪花算法但去掉機器ID位讓時間戳和序列號做主結構。這需要在性能和信息量之間做個取舍。4.4 多機房部署的全局協(xié)調多機房部署是所有方案都要面對的特殊場景。如果兩個機房各跑一套ID服務它們之間的ID必須保持全局唯一不能因為機房間網(wǎng)絡分區(qū)而導致重復。雪花算法天生適合多機房機器ID的10位里拆分出數(shù)據(jù)中心ID就是干這個的。不同機房分配不同的數(shù)據(jù)中心ID段機房間不需要任何通信就能保證全局唯一這條特性讓它成為多機房場景的首選。號段模式在多機房場景下則需要額外設計。不能讓兩個機房同時從同一個號段表取號否則會產(chǎn)生相同號段正確做法是按機房設置不同的步長和分區(qū)規(guī)則或者給最終ID拼上機房標識位。相比之下改造工作量和踩坑成本都比雪花算法要高一些。5. 實戰(zhàn)避坑我在生產(chǎn)環(huán)境踩過的七個坑5.1 時鐘回撥導致ID重復這是最典型的線上事故我遇到過某臺宿主機因為NTP校準導致時鐘回跳了幾十毫秒ID服務直接生成了重復的ID寫入數(shù)據(jù)庫時拋主鍵沖突接口報錯持續(xù)了幾分鐘。復盤發(fā)現(xiàn)回撥期間組件用的是簡單等待策略但等待邏輯沒有結合閾值判斷回撥了50毫秒它就直接用了回撥后的新時間戳導致時間戳倒退后序列號歸零。修復方案就是我在上面3.3節(jié)提到的等待加閾值、超閾值就快速失敗兩條路線都配上告警?，F(xiàn)在這套雙保險上線后再沒有出現(xiàn)過重復ID。5.2 序列號溢出單機高并發(fā)加單毫秒內(nèi)序列號超過4095時代碼會自旋等待下一毫秒?？此茻o害但如果業(yè)務高峰期同一毫秒的并發(fā)請求超過4096個所有請求都會卡住延遲飆到幾毫秒甚至幾十毫秒。更隱蔽的是如果并發(fā)量再高一點有些實現(xiàn)的序列號位直接溢出丟棄造成ID重復。這個問題的應對是監(jiān)控序列號使用率在壓測時就把單機QPS摸清一旦超過設計上限就得擴容機器或者調小機器位位數(shù)、放大序列號位。別迷信4096這個數(shù)看起來很大在某些高峰集中、批量調用的鏈路里一毫秒幾千并發(fā)完全可能。5.3 機器ID分配失誤有次某兩個實例的機器ID被配成了同一個數(shù)結果一個集群里兩個節(jié)點生成的ID偶爾出現(xiàn)重復。這種問題最詭異問題只出現(xiàn)在兩個節(jié)點同時生成、且毫秒內(nèi)序列號也相同的極小概率窗口里初期壓測未必能發(fā)現(xiàn)上線后才偶然觸發(fā)。從那以后我強烈建議所有雪花算法生產(chǎn)環(huán)境必須有機器ID注冊和沖突檢測機制。如果是純配置文件管理的每次發(fā)布前做一次全量巡檢如果用了協(xié)調服務自動分配也要檢查節(jié)點重啟時ID是否被正確釋放否則會積累出一堆“僵尸ID”。5.4 UUID做主鍵的索引問題這不是一個必踩的坑但會讓你在性能測試時懷疑人生。早期某個日志表用了UUID做主鍵數(shù)據(jù)量到了千萬級之后插入速率明顯下滑從每小時幾百萬降到幾萬。DBA排查出索引碎片率極高葉子節(jié)點頻繁分裂最后重建表、把主鍵改成自增代理主鍵UUID放到底層唯一索引里做邏輯唯一校驗才算正常。如果你的表數(shù)據(jù)量巨大且寫入很頻繁不要拿UUID直接做聚簇索引主鍵這是血的教訓。5.5 號段模式申請后重啟導致號段浪費號段模式的浪費其實是可以接受的但有一種情況會讓你肉疼步長設得太長比如一次取10萬個號某個服務剛取完號就重啟編程式再分配又得重啟一次10萬個ID瞬間打水漂。如果步長過大加上頻繁重啟浪費率可以達到30%以上。我的經(jīng)驗是把步長設為正常高峰期10分鐘的消耗量既保證數(shù)據(jù)庫訪問頻率低又最大限度降低浪費率。同時把“重啟后號段扔棄”的行為記進日志便于統(tǒng)計浪費率。5.6 ID信息泄露風險有段時間我們的訂單號直接用了時間戳加序號的拼接方式結果外部可以從訂單號推算出每日訂單量和商家分布。后來安全團隊要求整改把所有外部可感知的ID改成隨機性更高的方案在序列號部分引入一定的隨機偏移或在ID外層做混淆映射內(nèi)部存儲仍用原始ID。做交易、營銷這類對外系統(tǒng)的同學請?zhí)貏e注意ID即信息的方案一定要慎重。寧可損失一部分趨勢遞增性也要保證外部不可猜測。5.7 監(jiān)控缺失很多組件在故障初期是沒有明顯表象的時鐘回撥、序列號溢出等問題在發(fā)生之前會有各種征兆——生成耗時增加、重復請求比例上升、告警閾值波動等。如果你的ID生成器沒有獨立的監(jiān)控指標這些問題點只能靠業(yè)務報障來被動發(fā)現(xiàn)。我給ID服務加的監(jiān)控指標有生成耗時P99、每秒生成量、時鐘回撥次數(shù)、序列號溢出次數(shù)、機器ID沖突檢測結果。每天看一眼這些指標就能把絕大多數(shù)隱患消滅在爆發(fā)之前。6. 方案綜合對比與性能參考6.1 六大方案橫向對比表方案全局唯一趨勢遞增單機性能依賴組件實現(xiàn)復雜度推薦程度UUID高否極高無極低日志/消息ID數(shù)據(jù)庫自增高是低單庫/集群低小系統(tǒng)過渡數(shù)據(jù)庫號段高是高數(shù)據(jù)庫中中小規(guī)模業(yè)務緩存中間件INCR高是高緩存持久化低中低并發(fā)場景原生雪花算法高是極高無需配機器ID中大規(guī)模默認選擇增強雪花組件高是極高協(xié)調服務自身集群高大型基礎設施6.2 大規(guī)模壓力測試結果參考我以標準8核16GB機器做過的實測數(shù)據(jù)供參考UUID生成單線程約100萬/秒無網(wǎng)絡開銷但存儲負擔大。數(shù)據(jù)庫號段模式步長1000單機約8萬/秒數(shù)據(jù)庫側每秒只有約20次更新集群整體性能取決于節(jié)點數(shù)。原生雪花算法單機約38萬/秒P99延遲0.2毫秒以內(nèi)主要瓶頸在synchronized和內(nèi)存分配。增強雪花組件在加入集群銷毀舊ID、分配新ID的網(wǎng)絡調度后單機約27萬/秒但勝在自動化和全局管理能力。這些數(shù)字只能在選型時做個量級參考不能作為絕對標準。實際數(shù)值和應用所在語言、GC參數(shù)、服務器配置、并發(fā)模型都有關系請務必以你們自己的壓測環(huán)境為準。6.3 高可用部署的小結方案的高可用性本質上取決于它的最小依賴集。UUID沒有依賴天然高可用雪花算法依賴本機時間和機器ID分配多跑幾個節(jié)點就行號段模式依賴數(shù)據(jù)庫需要數(shù)據(jù)庫高可用來支撐緩存中間件方案對持久化和故障切換要求最高需要仔細驗證切換場景。架構上的通用建議是ID生成器獨立部署成一個小服務而不是嵌在每個業(yè)務服務里。這樣雖然多了一層網(wǎng)絡調用但可以集中做監(jiān)控、限流和容災切換底層方案時也不需要改動業(yè)務代碼。等量級再大再加一層本地緩存批量取號就能覆蓋絕大多數(shù)場景了。最后再分享一個實戰(zhàn)中很有效的細節(jié)不論最終選了哪個方案都要在ID里至少保留一部分時間信息。這樣排障時可以快速判斷一條數(shù)據(jù)是什么時候生成的壓縮日志、冷熱數(shù)據(jù)分離都會方便很多。分布式唯一ID看似是基礎小事但它直接影響著整個系統(tǒng)的穩(wěn)定性和運維體驗別在這上面省事。 分布式唯一ID生成方案全解析：原理、痛點與選型
分布式系統(tǒng)里唯一ID生成幾乎是每個后端開發(fā)都要正面碰一回的問題。不管你是做訂單系統(tǒng)、IM消息、日志追蹤還是優(yōu)惠券發(fā)放只要上了微服務、做了分庫分表就會突然發(fā)現(xiàn)原來單庫自增主鍵那套玩法徹底失靈了。這篇文章我把這些年折騰過的方案一次性拿出來做個匯總從最簡單的UUID到大數(shù)據(jù)量下的號段、增強雪花算法都捋一遍每個方案的原理、坑點、適用場景都會展開講也會給出我的真實選型建議希望能幫你在做技術選型時少走幾條彎路。1. 為什么分布式系統(tǒng)需要唯一ID核心痛點和設計約束1.1 從兩個經(jīng)典業(yè)務場景說起先聊一個最常見的場景訂單號。早期單體應用訂單表就用數(shù)據(jù)庫自增主鍵一張表搞定邏輯簡單查詢也快。但等單量漲到一定程度單表扛不住了你開始分庫分表。這時候問題來了——兩個庫各自維護自增IDA庫生成了1001B庫也可能生成1001訂單號就沖突了。即便你把自增值改掉設成不同的初始值等數(shù)據(jù)量再上漲、需要擴容分庫時這種手工分片的方式也會變成噩夢。再看日志追蹤場景。一次用戶請求經(jīng)過網(wǎng)關、多個微服務、緩存、消息隊列每個環(huán)節(jié)都會打印日志。排障的時候你需要把這次請求的所有日志串起來唯一的辦法就是給整個請求鏈路的每一行日志都帶上同一個traceId。這個ID必須在所有服務節(jié)點上是全局唯一的而且要盡可能生成得快因為每次請求都會用到性能多一點延遲都能被放大成巨大的開銷。這兩個場景背后有一個共同的技術需求在一個沒有全局時鐘、沒有單點數(shù)據(jù)庫、節(jié)點隨時可能擴容縮容的分布式環(huán)境里要生成一個不重復的ID還要滿足業(yè)務對趨勢遞增、安全隱藏等額外要求。這就是分布式唯一ID要解決的完整命題。1.2 唯一ID的四層核心訴求拋開具體方案先梳理清楚分布式唯一ID的設計約束后續(xù)看任何方案都能一眼判斷它合不合適。全局唯一性不用多說這是底線。任何時刻、任何節(jié)點生成的ID都不能重復否則直接導致主鍵沖突、數(shù)據(jù)覆蓋輕則臟數(shù)據(jù)重則線上事故。趨勢遞增性。數(shù)據(jù)庫的B樹索引對有序數(shù)據(jù)最友好。如果ID完全隨機插入時索引頁會頻繁分裂產(chǎn)生大量隨機IO寫入性能會急劇下降。這也是UUID做主鍵被人詬病的核心原因——它唯一但索引不友好。高可用低延遲。ID生成器是所有依賴它的業(yè)務的前置依賴。它掛一秒訂單就下不了消息就發(fā)不出去。生成時間通常在毫秒級甚至微秒級而且必須做高可用部署不能存在單點。信息安全性。訂單ID暗示著業(yè)務量用戶ID可以被遍歷猜測這些在有些業(yè)務里是安全風險。如果生成規(guī)則里直接拼接時間戳、業(yè)務類型外部很容易推算出發(fā)貨量、用戶規(guī)模等敏感數(shù)據(jù)需要做防推算設計。這四層訴求不是每個場景都需要全部滿足但你在選型時必須逐條對照把需求優(yōu)先級排清楚才能選出最合適的方案。2. 六種主流ID生成方案逐一點評2.1 UUID最省事但陷阱很多UUIDUniversally Unique Identifier是很多新手的第一個選擇因為它在任何語言里幾乎都有現(xiàn)成的庫一行代碼就能生成。標準的UUID是128位的十六進制字符串基于時間、節(jié)點標識、隨機數(shù)等要素生成理論上全球唯一。用UUID做業(yè)務主鍵最大的好處是徹底去中心化本機生成不需要任何網(wǎng)絡請求性能極高擴展性無限。但這東西的生產(chǎn)環(huán)境口碑并不好主要問題有三個第一太長。128位轉成字符串是36個字符含連字符如果直接作為數(shù)據(jù)庫主鍵一個二級索引就會多占用不少空間數(shù)據(jù)量大時存儲成本明顯上升。第二完全無序。上文說過隨機性極強的值寫入B樹時會造成頁分裂寫入性能相比自增ID會有明顯下降這在寫密集場景下是硬傷。第三不具備任何業(yè)務含義排障時肉眼完全讀不出任何信息。不過UUID也不是一無是處。在不需要排序、沒有趨勢遞增要求、并發(fā)量極大、且ID只作唯一標識的場景比如消息中間件里的消息ID、異步任務的任務ID它仍然是很實用的選擇。2.2 數(shù)據(jù)庫自增ID最原始單點和性能是硬傷單庫時代的經(jīng)典方案。在MySQL里設置主鍵自增AUTO_INCREMENT每次插入數(shù)據(jù)時自動生成一個順序遞增的ID簡單可靠索引友好對DBA和經(jīng)驗型程序員來說最直觀。但一旦進入分布式環(huán)境自增ID的問題立刻暴露。最明顯的是單點問題——所有節(jié)點都到一個數(shù)據(jù)庫實例取ID這個庫就是整個系統(tǒng)的瓶頸一旦它出問題所有依賴ID的服務全部癱瘓。而且單庫的寫入吞吐量有限通常每秒幾千到幾萬扛不住大流量的沖擊。解決沖突的辦法是把自增起始值按節(jié)點錯開比如A庫從1開始自增B庫從10001開始自增步長都設為10000但這只是權宜之計后續(xù)擴容、節(jié)點數(shù)量變化時起始值和步長都需要重新規(guī)劃工程復雜度很高。這個方案如今只適合兩類場景系統(tǒng)規(guī)模極小、并發(fā)量很低的內(nèi)部工具以及遷移期的過渡方案。真正核心的交易鏈路不建議直接用數(shù)據(jù)庫自增做主鏈路ID生成。2.3 數(shù)據(jù)庫號段模式批量取號的進階玩法號段模式也叫segment模式是對數(shù)據(jù)庫自增的改良思路非常巧妙。與其每生成一個ID就去數(shù)據(jù)庫查一次不如一次從數(shù)據(jù)庫取一批號段放在本地內(nèi)存里業(yè)務用完了再去取下一批。具體做法是在數(shù)據(jù)庫里建一張專門的號段分配表維護每個業(yè)務線的當前最大ID和步長。比如步長設為1000某服務啟動后去數(shù)據(jù)庫執(zhí)行一次更新把當前值從1改成1001然后這1000個號段就歸這個服務獨占內(nèi)存里依次派發(fā)用完了再來取一次號。這個方案把對數(shù)據(jù)庫的訪問頻率降低了幾個數(shù)量級。原來每秒生成一萬個ID需要一萬次數(shù)據(jù)庫操作用了號段模式之后步長足夠大的話數(shù)據(jù)庫的壓力可以忽略不計整體吞吐量能做到幾萬甚至十幾萬每秒。而且ID是趨勢遞增的對索引非常友好。它的代價是什么呢首先是依賴數(shù)據(jù)庫的可用性數(shù)據(jù)庫掛了號段耗盡后就無法生成新ID了需要配合數(shù)據(jù)庫高可用方案才能保證穩(wěn)定其次每個節(jié)點會存在號段浪費某個服務申請了1000個號但只用掉100個就重啟了剩余的900個就作廢了好在號段資源本身不貴這個損耗可以接受。另外因為每個服務在本地按號段派發(fā)多節(jié)點生成的ID區(qū)間是錯開的從整體看全局趨勢遞增但嚴格意義上它不是完全全局有序的對于不需要絕對排序的場景完全沒問題。號段模式在業(yè)界應用非常廣泛很多互聯(lián)網(wǎng)公司早期的分布式ID組件都是基于這個思路做的優(yōu)點是實現(xiàn)門檻低、擴展容易只要加號段步長就能線性提升性能。2.4 緩存中間件INCR高性能與持久化隱患很多團隊用過緩存中間件的原子自增命令比如INCR命令來生成ID。這個操作本身是原子的能夠保證并發(fā)環(huán)境下的唯一性加上中間件本身的高性能可以獲得很高的吞吐量。實現(xiàn)思路也簡單在內(nèi)存里維護一個全局key每次請求執(zhí)行一次自增并返回?？梢杂靡惶煲粋€key的方式實現(xiàn)日期前綴加序號這樣生成的ID還能自帶時間信息也方便按天重置。這個方案的優(yōu)點是性能高、延遲低、實現(xiàn)極簡幾行代碼就能搞定。但它的隱患同樣明顯依賴中間件的持久化機制如果中間件做了RDB快照和AOF日志配置得當?shù)脑捒煽啃赃€湊合但如果用的是純內(nèi)存模式或者持久化策略保守一旦中間件異常重啟自增計數(shù)就可能回退從而產(chǎn)生ID重復后果非常嚴重。另外即使中間件本身是高可用的在故障切換時新的主節(jié)點如果沒有完全同步舊主節(jié)點的自增值同樣可能生成重復ID。需要做帶寬外的補償處理比如把最終ID拼上一個節(jié)點標識位來避免沖突。所以我對這個方案的態(tài)度是它能用但要想清楚能不能接受底層依賴的風險。在一般性業(yè)務里做個排他鎖、計數(shù)器還行如果做交易主鍵這類核心鏈路不推薦。2.5 雪花算法Snowflake時間戳機器位序列號雪花算法可以說是目前分布式唯一ID方案里的主流方案Twitter開源盡管我不建議直接點名公司這里就以這個概念來說明核心思想是把64位二進制拆成時間戳、機器ID、序列號三個部分在單機內(nèi)通過序列號保證每毫秒內(nèi)生成的ID唯一在全局通過時間戳和機器ID保證跨節(jié)點唯一。64位的分配通常是這樣的第1位是符號位固定為0保證ID為正數(shù)接下來41位是毫秒時間戳可以支撐大約69年的使用然后10位是機器ID可以表示1024臺機器最后12位是每毫秒內(nèi)的序列號范圍是0到4095。也就是說單臺機器每毫秒最多能生成4096個ID單機每秒約400萬這個性能非常可觀。雪花算法的優(yōu)勢很明顯ID是趨勢遞增的時間戳本身就是排序依據(jù)索引友好單機純內(nèi)存運算不需要網(wǎng)絡IO生成速度快結構上含有時間戳和機器信息能反推生成時間方便問題排查部署上每個節(jié)點獨立計算不存在中心化依賴高可用性非常好。它也有麻煩。最大的挑戰(zhàn)是時鐘回撥問題。系統(tǒng)時間如果因為NTP校準、運維操作被人為調回去那么生成的ID時間戳部分就可能小于之前的值同一毫秒序列號就算不一樣也會出現(xiàn)同一臺機器在時間戳倒退區(qū)間內(nèi)生成重復ID這是絕對不能接受的。這個問題我會在下面專門花一節(jié)講清楚。2.6 增強版開源方案易用性與運維成本針對原生雪花算法的時鐘回撥問題、以及機器ID分配繁瑣的問題業(yè)界出現(xiàn)了很多增強方案。思路大致上是用數(shù)據(jù)庫或協(xié)調服務來自動管理機器ID在時鐘回撥時采用等待時間追平、或者借用未來時間戳等策略還有一些方案把ID的位數(shù)結構做了調整比如縮短時間戳位數(shù)、增加秒級單位、把序列號位數(shù)加大來提升單秒容量。這類增強型組件的使用體驗通常比純自研好很多集成SDK后業(yè)務只需要調用一個接口就能拿到ID幾乎不需要關心底層細節(jié)。但代價是引入了一個新的基礎設施組件需要單獨部署、配置高可用、監(jiān)控告警一個組件從上線到穩(wěn)定運行往往要投入不少人力和運維精力。選型建議是這樣的如果你的系統(tǒng)規(guī)模還不大但已經(jīng)確定會走向分布式優(yōu)先選擇號段模式或者自研一個簡單的增強雪花算法不要一上來就引入重型組件。只有你的ID生成量級已經(jīng)到了每秒數(shù)萬甚至幾十萬、業(yè)務對ID穩(wěn)定性的要求極高、團隊也有足夠的技術能力去維護才適合把某個成熟的增強組件作為公司級的基礎設施來做。3. 雪花算法深挖位結構、時鐘回撥與代碼實現(xiàn)3.1 64位結構拆解每個bit都不能亂挪雪花算法的魅力在于64個bit沒有一個是浪費的當前通用的位分配如下第1位符號位固定為0。因為Java里的long是有符號整數(shù)如果第一位是1整個數(shù)變成負數(shù)會給后續(xù)使用帶來麻煩。第2到42位時間戳共41位記錄從某個自定義起始時間到當前時間的毫秒數(shù)可以表示約69年。注意這個時間戳不是Unix紀元而是你自己定義的業(yè)務起始時間設計上通常取固定日期這樣同等位數(shù)能表達更長的時間范圍。第43到52位機器ID共10位可以表示0到1023共1024個節(jié)點。部分實現(xiàn)里會拆成5位數(shù)據(jù)中心ID加5位機器ID。第53到64位序列號共12位每毫秒內(nèi)的并發(fā)序列取值范圍0到4095。達到4096后就要等待下一毫秒。理解了位結構你就能明白任何偏移都是可以定制和擴展的。如果你的業(yè)務并發(fā)量沒那么高可以把序列號位數(shù)調少一點把時間戳位數(shù)調多一點延長可用年限如果你的機房數(shù)量少而單機并發(fā)高可以調整數(shù)據(jù)中心位和機器位的比例。這種按需裁剪的能力是雪花算法能長期流行的底層原因。3.2 核心代碼實現(xiàn)一個可用的Java參考版本下面給出一份我自己維護的精簡版雪花算法Java實現(xiàn)你可以直接在項目里參考使用。它主要實現(xiàn)了時間戳拼接、序列號遞增、時鐘回撥檢測這幾個核心邏輯。public class SnowflakeIdGenerator { // 分別定義位數(shù) private static final long START_TIMESTAMP 1700000000000L; // 自定義起始時間戳 private static final long MACHINE_ID_BITS 10L; private static final long MAX_MACHINE_ID (1L MACHINE_ID_BITS) - 1; private static final long SEQUENCE_BITS 12L; private static final long SEQUENCE_MASK (1L SEQUENCE_BITS) - 1; private static final long MACHINE_ID_SHIFT SEQUENCE_BITS; private static final long TIMESTAMP_SHIFT SEQUENCE_BITS MACHINE_ID_BITS; private final long machineId; private long sequence 0L; private long lastTimestamp -1L; public SnowflakeIdGenerator(long machineId) { if (machineId 0 || machineId MAX_MACHINE_ID) { throw new IllegalArgumentException(非法機器ID); } this.machineId machineId; } public synchronized long nextId() { long currentTimestamp System.currentTimeMillis(); // 時鐘回撥檢測 if (currentTimestamp lastTimestamp) { long offset lastTimestamp - currentTimestamp; if (offset 5) { // 回撥超過閾值直接拋異常等運維介入 throw new IllegalStateException(時鐘回撥嚴重拒絕生成ID回撥差值: offset); } // 回撥較小等待原時間追上 while (currentTimestamp lastTimestamp) { currentTimestamp System.currentTimeMillis(); } } if (currentTimestamp lastTimestamp) { sequence (sequence 1) SEQUENCE_MASK; if (sequence 0) { // 當前毫秒序列號用盡自旋等待下一毫秒 currentTimestamp waitNextMillis(lastTimestamp); } } else { // 新的一毫秒開始序列號歸零 sequence 0; } lastTimestamp currentTimestamp; return ((currentTimestamp - START_TIMESTAMP) TIMESTAMP_SHIFT) | (machineId MACHINE_ID_SHIFT) | sequence; } private long waitNextMillis(long lastTimestamp) { long currentTimestamp System.currentTimeMillis(); while (currentTimestamp lastTimestamp) { currentTimestamp System.currentTimeMillis(); } return currentTimestamp; } }這段代碼有幾個關鍵細節(jié)生成方法必須加synchronized否則多線程并發(fā)下序列號會沖突序列號用位運算保證在0到4095之間循環(huán)超過4095自動清零配合等下一毫秒的邏輯就堵住了溢出的可能性時間戳起始值務必設置為某一天不要從1970年開始否則同樣表示69年從2024年算起就遠夠用了但數(shù)字太大會讓ID暴長起始值靠前的話ID數(shù)值小看起來更清爽。3.3 時鐘回撥問題三種處理策略時鐘回撥是雪花算法實戰(zhàn)中遇到概率最高的坑也是生產(chǎn)事故的高發(fā)點。服務器時間被人為調整、NTP同步跳變、虛擬機時鐘漂移都可能導致當前系統(tǒng)時間小于上一次生成ID時的時間。回撥期間時間戳部分變小序列號必須從0開始這就很容易生成一個比之前更小、甚至完全一樣的ID。業(yè)界常見的處理策略有三種你可以根據(jù)自己業(yè)務的容忍度來選策略一是等待追平。檢測到回撥后讓線程自旋等待直到系統(tǒng)時間追平上次生成時間。這個策略最簡單回撥幅度小幾十毫秒內(nèi)的時候體驗很好但如果回撥超過幾秒所有請求都會阻塞服務就會明顯卡頓不適合高并發(fā)場景。策略二是強校驗失敗。回撥一旦發(fā)生直接拋出異常讓請求失敗、走熔斷降級由運維檢查恢復。這個策略最安全適合回撥極罕見且業(yè)務不能容忍錯誤ID的場景代價是一小段時間內(nèi)產(chǎn)生異常率。策略三是借用未來時間戳。把序列號空間擴展一些當回撥發(fā)生時用上一個ID的序列號加一個大偏移來遞增直到追平正常時間。這個策略能保證連續(xù)性但會導致一段時間內(nèi)的ID時間戳是跳躍的如果業(yè)務有嚴格的時間維度統(tǒng)計需要格外注意。我的建議是主默認用等待追平加一個閾值判斷回撥超過閾值就拋異常。這里的閾值可以設成5毫秒既能處理輕微的時鐘抖動又不會讓系統(tǒng)默默錯誤運行。3.4 機房隔離與機器號分配機器ID的分配如果全靠手工配置在上千臺機器的規(guī)模下會讓人崩潰。常見的做法有三個層次一是純配置文件管理適合機器數(shù)量少、變動不頻繁的團隊。每個服務實例的配置中心里寫死一個machineId注意保證唯一性。這個方案實現(xiàn)成本最低但出現(xiàn)重復機器ID時會直接導致ID沖突后果是災難性的。二是基于數(shù)據(jù)庫分配。建一張機器ID分配表服務啟動時向數(shù)據(jù)庫注冊獲取一個未使用的機器ID并做有效期管理服務失聯(lián)后可以回收。這個方案比較可靠但引入了一次注冊依賴。三是基于協(xié)調服務自動分配。利用協(xié)調組的臨時節(jié)點特性服務啟動時創(chuàng)建臨時節(jié)點申請ID斷開連接后臨時節(jié)點自動刪除ID自動釋放。這個方案最自動化比較適合大規(guī)模集群但引入了一個新的基礎組件。實操中還有一種偷懶但有效的辦法不顯式管理機器ID而是把機器ID替換成隨機啟動值每次啟動隨機生成一個0到1023之間的數(shù)字。這種方案在節(jié)點數(shù)很少個位數(shù)時利用率極高但節(jié)點多了之后碰撞概率會不可控不建議正式環(huán)境這么干。4. 方案落地與選型建議不同業(yè)務場景怎么選4.1 選型決策的核心維度先把各維度的權重在你的團隊里排清楚。我一般按下面幾個順序詢問業(yè)務方是否需要趨勢遞增每秒的峰值QPS大概多少ID里能否包含明確的時間信息外部能否通過ID推測業(yè)務量對底層基礎設施的運維能力到什么水平這五個問題問完方案的邊界基本就清晰了。比如高并發(fā)、強遞增、低延遲的交易系統(tǒng)基本直接鎖定雪花鏈路中小規(guī)模、希望簡單可控的內(nèi)容系統(tǒng)號段模式反而比架構更重的方案好用日志系統(tǒng)只要能快速出ID、不需要關心順序UUID也能勝任。4.2 偏向趨勢遞增的訂單場景典型的訂單服務對ID有三個要求絕對全局唯一很強的趨勢遞增性因為訂單表經(jīng)常按時間排序或者使用時間范圍查詢整體延遲要低不能因為ID生成拖慢下單鏈路。在單機性能要求不是特別夸張的情況下我傾向選號段模式。原因很簡單號段模式實現(xiàn)直觀、故障點少一個數(shù)據(jù)庫高可用就能覆蓋整個ID服務的可用性ID的連續(xù)性和遞增性也符合訂單系統(tǒng)的語義。很多訂單號看起來就是幾個數(shù)字在漲運營和客服肉眼就能排序這種可解釋性是雪花ID不具備的。如果訂單量極大、單機號段的頻率還是太高可以加一層本地緩存、調大步長。記得步長不要設成某個固定值就完事建議做成可配置的能根據(jù)業(yè)務峰值動態(tài)調整。4.3 強性能的日志場景日志鏈路traceId的生成環(huán)境比較惡劣——每個服務節(jié)點每處理一次請求都可能要生成一個ID全鏈路上每秒累計可能要生成幾百萬個ID。此時對ID元信息的關注度極低排序要求也不高但性能要求極高。這時候UUID反而可能比雪花算法更合適。因為沒有時間戳和機器位的組裝邏輯上只需要生成隨機數(shù)和格式化字符串單次生成的CPU開銷很小。擴展方面也簡單每臺機器是獨立的系統(tǒng)擴容無需協(xié)調機器ID分配。日志的存儲可以按天分目錄、用搜索引擎建索引無序問題在日志場景里并不突出。如果追求ID里能看出生成時間可以用日期前綴加一段隨機數(shù)或者直接用60位壓縮版的雪花算法但去掉機器ID位讓時間戳和序列號做主結構。這需要在性能和信息量之間做個取舍。4.4 多機房部署的全局協(xié)調多機房部署是所有方案都要面對的特殊場景。如果兩個機房各跑一套ID服務它們之間的ID必須保持全局唯一不能因為機房間網(wǎng)絡分區(qū)而導致重復。雪花算法天生適合多機房機器ID的10位里拆分出數(shù)據(jù)中心ID就是干這個的。不同機房分配不同的數(shù)據(jù)中心ID段機房間不需要任何通信就能保證全局唯一這條特性讓它成為多機房場景的首選。號段模式在多機房場景下則需要額外設計。不能讓兩個機房同時從同一個號段表取號否則會產(chǎn)生相同號段正確做法是按機房設置不同的步長和分區(qū)規(guī)則或者給最終ID拼上機房標識位。相比之下改造工作量和踩坑成本都比雪花算法要高一些。5. 實戰(zhàn)避坑我在生產(chǎn)環(huán)境踩過的七個坑5.1 時鐘回撥導致ID重復這是最典型的線上事故我遇到過某臺宿主機因為NTP校準導致時鐘回跳了幾十毫秒ID服務直接生成了重復的ID寫入數(shù)據(jù)庫時拋主鍵沖突接口報錯持續(xù)了幾分鐘。復盤發(fā)現(xiàn)回撥期間組件用的是簡單等待策略但等待邏輯沒有結合閾值判斷回撥了50毫秒它就直接用了回撥后的新時間戳導致時間戳倒退后序列號歸零。修復方案就是我在上面3.3節(jié)提到的等待加閾值、超閾值就快速失敗兩條路線都配上告警?，F(xiàn)在這套雙保險上線后再沒有出現(xiàn)過重復ID。5.2 序列號溢出單機高并發(fā)加單毫秒內(nèi)序列號超過4095時代碼會自旋等待下一毫秒?？此茻o害但如果業(yè)務高峰期同一毫秒的并發(fā)請求超過4096個所有請求都會卡住延遲飆到幾毫秒甚至幾十毫秒。更隱蔽的是如果并發(fā)量再高一點有些實現(xiàn)的序列號位直接溢出丟棄造成ID重復。這個問題的應對是監(jiān)控序列號使用率在壓測時就把單機QPS摸清一旦超過設計上限就得擴容機器或者調小機器位位數(shù)、放大序列號位。別迷信4096這個數(shù)看起來很大在某些高峰集中、批量調用的鏈路里一毫秒幾千并發(fā)完全可能。5.3 機器ID分配失誤有次某兩個實例的機器ID被配成了同一個數(shù)結果一個集群里兩個節(jié)點生成的ID偶爾出現(xiàn)重復。這種問題最詭異問題只出現(xiàn)在兩個節(jié)點同時生成、且毫秒內(nèi)序列號也相同的極小概率窗口里初期壓測未必能發(fā)現(xiàn)上線后才偶然觸發(fā)。從那以后我強烈建議所有雪花算法生產(chǎn)環(huán)境必須有機器ID注冊和沖突檢測機制。如果是純配置文件管理的每次發(fā)布前做一次全量巡檢如果用了協(xié)調服務自動分配也要檢查節(jié)點重啟時ID是否被正確釋放否則會積累出一堆“僵尸ID”。5.4 UUID做主鍵的索引問題這不是一個必踩的坑但會讓你在性能測試時懷疑人生。早期某個日志表用了UUID做主鍵數(shù)據(jù)量到了千萬級之后插入速率明顯下滑從每小時幾百萬降到幾萬。DBA排查出索引碎片率極高葉子節(jié)點頻繁分裂最后重建表、把主鍵改成自增代理主鍵UUID放到底層唯一索引里做邏輯唯一校驗才算正常。如果你的表數(shù)據(jù)量巨大且寫入很頻繁不要拿UUID直接做聚簇索引主鍵這是血的教訓。5.5 號段模式申請后重啟導致號段浪費號段模式的浪費其實是可以接受的但有一種情況會讓你肉疼步長設得太長比如一次取10萬個號某個服務剛取完號就重啟編程式再分配又得重啟一次10萬個ID瞬間打水漂。如果步長過大加上頻繁重啟浪費率可以達到30%以上。我的經(jīng)驗是把步長設為正常高峰期10分鐘的消耗量既保證數(shù)據(jù)庫訪問頻率低又最大限度降低浪費率。同時把“重啟后號段扔棄”的行為記進日志便于統(tǒng)計浪費率。5.6 ID信息泄露風險有段時間我們的訂單號直接用了時間戳加序號的拼接方式結果外部可以從訂單號推算出每日訂單量和商家分布。后來安全團隊要求整改把所有外部可感知的ID改成隨機性更高的方案在序列號部分引入一定的隨機偏移或在ID外層做混淆映射內(nèi)部存儲仍用原始ID。做交易、營銷這類對外系統(tǒng)的同學請?zhí)貏e注意ID即信息的方案一定要慎重。寧可損失一部分趨勢遞增性也要保證外部不可猜測。5.7 監(jiān)控缺失很多組件在故障初期是沒有明顯表象的時鐘回撥、序列號溢出等問題在發(fā)生之前會有各種征兆——生成耗時增加、重復請求比例上升、告警閾值波動等。如果你的ID生成器沒有獨立的監(jiān)控指標這些問題點只能靠業(yè)務報障來被動發(fā)現(xiàn)。我給ID服務加的監(jiān)控指標有生成耗時P99、每秒生成量、時鐘回撥次數(shù)、序列號溢出次數(shù)、機器ID沖突檢測結果。每天看一眼這些指標就能把絕大多數(shù)隱患消滅在爆發(fā)之前。6. 方案綜合對比與性能參考6.1 六大方案橫向對比表方案全局唯一趨勢遞增單機性能依賴組件實現(xiàn)復雜度推薦程度UUID高否極高無極低日志/消息ID數(shù)據(jù)庫自增高是低單庫/集群低小系統(tǒng)過渡數(shù)據(jù)庫號段高是高數(shù)據(jù)庫中中小規(guī)模業(yè)務緩存中間件INCR高是高緩存持久化低中低并發(fā)場景原生雪花算法高是極高無需配機器ID中大規(guī)模默認選擇增強雪花組件高是極高協(xié)調服務自身集群高大型基礎設施6.2 大規(guī)模壓力測試結果參考我以標準8核16GB機器做過的實測數(shù)據(jù)供參考UUID生成單線程約100萬/秒無網(wǎng)絡開銷但存儲負擔大。數(shù)據(jù)庫號段模式步長1000單機約8萬/秒數(shù)據(jù)庫側每秒只有約20次更新集群整體性能取決于節(jié)點數(shù)。原生雪花算法單機約38萬/秒P99延遲0.2毫秒以內(nèi)主要瓶頸在synchronized和內(nèi)存分配。增強雪花組件在加入集群銷毀舊ID、分配新ID的網(wǎng)絡調度后單機約27萬/秒但勝在自動化和全局管理能力。這些數(shù)字只能在選型時做個量級參考不能作為絕對標準。實際數(shù)值和應用所在語言、GC參數(shù)、服務器配置、并發(fā)模型都有關系請務必以你們自己的壓測環(huán)境為準。6.3 高可用部署的小結方案的高可用性本質上取決于它的最小依賴集。UUID沒有依賴天然高可用雪花算法依賴本機時間和機器ID分配多跑幾個節(jié)點就行號段模式依賴數(shù)據(jù)庫需要數(shù)據(jù)庫高可用來支撐緩存中間件方案對持久化和故障切換要求最高需要仔細驗證切換場景。架構上的通用建議是ID生成器獨立部署成一個小服務而不是嵌在每個業(yè)務服務里。這樣雖然多了一層網(wǎng)絡調用但可以集中做監(jiān)控、限流和容災切換底層方案時也不需要改動業(yè)務代碼。等量級再大再加一層本地緩存批量取號就能覆蓋絕大多數(shù)場景了。最后再分享一個實戰(zhàn)中很有效的細節(jié)不論最終選了哪個方案都要在ID里至少保留一部分時間信息。這樣排障時可以快速判斷一條數(shù)據(jù)是什么時候生成的壓縮日志、冷熱數(shù)據(jù)分離都會方便很多。分布式唯一ID看似是基礎小事但它直接影響著整個系統(tǒng)的穩(wěn)定性和運維體驗別在這上面省事。