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