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