：41位時間戳的三個坑（時鐘回撥、workerId、位運算）)
老炮踩坑錄 · D08 · 技術(shù)深挖系列· 基于「企業(yè)融合平臺」真實源碼· 逐行拆解手寫 Snowflake ID 生成器· 關(guān)鍵詞3大坑 · 位運算 · 時鐘回撥 · 序列溢出 · workerId撞車 · CPU假死引子面試必問雪花算法這個項目里居然有人手寫了2026 年Java 21 LTS 成了生產(chǎn)標配Java 26 都發(fā)布了。分布式 ID 這個老話題依然是面試高頻考點——分庫分表后全局 ID 怎么生成十有八九會引出雪花算法然后面試官追一句“時鐘回撥怎么處理”很多人背過 Twitter Snowflake 的 64 位結(jié)構(gòu)面試時能默寫1 41 5 5 12 64但真讓你打開源碼逐行看位運算是怎么拼裝的、時鐘回撥是怎么檢測的、序列溢出是怎么處理的——大部分人都停在 “看懂結(jié)構(gòu)圖” 這一步?jīng)]真正讀過一行實現(xiàn)。巧了我翻的這個 2022 年的老項目里有人手寫了完整的雪花算法從位結(jié)構(gòu)設(shè)計到 Spring 集成一個都不落(la)。今天這篇我就拿著項目里真實的SnowflakeIdGenerator.java逐行拆給你看64 位 long 是怎么一段一段拼出來的synchronized為什么必須加時鐘回撥 3 毫秒就能讓線上報 500錯誤先看全貌雪花算法長什么樣子打開SnowflakeIdGenerator.java類注釋直接畫了一張結(jié)構(gòu)圖/** * Twitter_Snowflake * SnowFlake的結(jié)構(gòu)如下(每部分用-分開): * 0 - 0000000000 0000000000 0000000000 0000000000 0 - 00000 - 00000 - 000000000000 * 1位標識由于long基本類型在Java中是帶符號的最高位是符號位正數(shù)是0負數(shù)是1 * 41位時間截(毫秒級)注意41位時間截不是存儲當前時間的時間截而是存儲時間截的差值 * 41位的時間截可以使用69年 * 10位的數(shù)據(jù)機器位可以部署在1024個節(jié)點 * 12位序列毫秒內(nèi)的計數(shù)支持每個節(jié)點每毫秒產(chǎn)生4096個ID序號 * 加起來剛好64位為一個Long型。 */publicclassSnowflakeIdGenerator{// ...}注釋寫得規(guī)規(guī)矩矩一看就是從 Twitter 原版翻譯過來的。但光看注釋不夠我們得一段一段拆開看。64 位 long 的位結(jié)構(gòu)設(shè)計每一比特都不浪費五段劃分圖示如下段位數(shù)作用容量符號位1保證 ID 為正Java long 帶符號固定 0時間戳41毫秒級時間差值約 69 年數(shù)據(jù)中心 ID5區(qū)分機房0~31機器 ID5區(qū)分同機房節(jié)點0~31序列號12同毫秒內(nèi)遞增0~4095起始時間戳為什么是 2015 年privatefinallongtwepoch1420041600000L;// 2015-01-01 00:00:00 UTC注意41 位存的不是System.currentTimeMillis()而是當前時間 - twepoch的差值。為什么因為 41 位最多表示2^41 - 1 2,199,023,255,551毫秒換算成年2,199,023,255,551 / 1000 / 60 / 60 / 24 / 365 ≈ 69.7 年如果從 1970 年算起到 2039 年就溢出了。但從 2015 年算起能撐到2084 年。這就是為什么twepoch很重要——它決定了 ID 生成器的壽命。你完全可以把它設(shè)成項目上線的那天最大化利用這 41 位。位移量低位段位數(shù)之和 高位段移位量privatefinallongsequenceBits12L;privatefinallongworkerIdShiftsequenceBits;// 12privatefinallongdatacenterIdShiftsequenceBitsworkerIdBits;// 17privatefinallongtimestampLeftShiftsequenceBitsworkerIdBitsdatacenterIdBits;// 22發(fā)現(xiàn)規(guī)律了嗎每一段的左移量等于它右邊所有段的位數(shù)之和。序列號不移位最右邊 機器ID左移 12 位右邊有 12 位序列號 數(shù)據(jù)中心左移 17 位右邊有 12 5 17 位 時間戳左移 22 位右邊有 12 5 5 22 位這樣設(shè)計的好處是每段在 64 位 long 中各占各的位置互不干擾最后用按位或|拼裝即可。就像五條鐵軌每列火車走自己的道永遠不會撞車。掩碼的妙用用位運算代替 if 判斷最大值計算privatefinallongmaxWorkerId-1L^(-1LworkerIdBits);// 31privatefinallongmaxDatacenterId-1L^(-1LdatacenterIdBits);// 31privatefinallongsequenceMask-1L^(-1LsequenceBits);// 4095第一次看這段代碼的人大概率會懵-1L ^ (-1L 5)是什么鬼別急拆成二進制看就清楚了-1L 的二進制 11111111 11111111 ... 1111111164 個 1 -1L 5 11111111 11111111 ... 11100000低 5 位變 0 異或^ 00000000 00000000 ... 00011111只有低 5 位是 1 31所以-1L ^ (-1L n)的效果就是生成一個低 n 位全為 1 的掩碼。5 位掩碼 0b11111 31workerId / datacenterId 的最大值12 位掩碼 0b111111111111 4095序列號的最大值序列號溢出檢測這是整段代碼里最精妙的一行sequence(sequence1)sequenceMask;當sequence 4095時(4095 1) 4095 4096 4095 0b1000000000000 0b111111111111 0加 1 后與掩碼做按位與超過 4095 自動歸零。不需要if (sequence 4095) sequence 0一條位運算搞定。這就是位運算的魅力把 “判斷 賦值” 兩步操作壓縮成了一步這在高頻調(diào)用的場景下性能差異是實打?qū)嵉母摺：诵乃惴?nextId()逐行拆解終于到了分析最核心的邏輯方法了。核心源碼我把完整源碼貼出來并逐行加上注釋publicsynchronizedlongnextId(){// ① 獲取當前時間戳毫秒longtimestamptimeGen();// ② 時鐘回退檢測當前時間 上次生成 ID 的時間 → 拋異常if(timestamplastTimestamp){thrownewRuntimeException(String.format(Clock moved backwards. Refusing to generate id for %d milliseconds,lastTimestamp-timestamp));}// ③ 同一毫秒內(nèi)的序列處理if(lastTimestamptimestamp){// 同一毫秒 → 序列號 1掩碼保證不超過 4095sequence(sequence1)sequenceMask;// 序列溢出回到 0→ 自旋等到下一毫秒if(sequence0){timestamptilNextMillis(lastTimestamp);}}// ④ 新的毫秒 → 序列重置為 0else{sequence0L;}// ⑤ 記錄本次時間戳lastTimestamptimestamp;// ⑥ 位運算拼裝 64 位 IDreturn((timestamp-twepoch)timestampLeftShift)// 時間戳差值左移 22 位|(datacenterIddatacenterIdShift)// 數(shù)據(jù)中心 ID 左移 17 位|(workerIdworkerIdShift)// 機器 ID 左移 12 位|sequence;// 序列號不移位}六個步驟nextId()方法的六大步驟流程圖舉個計算例子假設(shè)timestamp - twepoch 1000, datacenterId 20, workerId 10, sequence 5時間戳部分1000 22 4,194,304,000 數(shù)據(jù)中心 20 17 2,621,440 機器 ID 10 12 40,960 序列號 5 5 ──────────────────────────────────────── 按位或拼裝 4,196,966,405每段井水不犯河水按位或 拼裝。因為每段的二進制位互不重疊所以|運算等價于加法但語義更清晰——我是在組裝不是在相加。自旋等待tilNextMillis()protectedlongtilNextMillis(longlastTimestamp){longtimestamptimeGen();while(timestamplastTimestamp){timestamptimeGen();// CPU 空轉(zhuǎn)浪費時間片}returntimestamp;}序列號用完了怎么辦死循環(huán)等等到下一毫秒再來。這個while循環(huán)叫busy-wait忙等待——CPU 在空轉(zhuǎn)什么都不干就反復(fù)問到下一毫秒了沒。在正常情況下一毫秒很快就過去了循環(huán)個幾十到幾百次就拿到新時間戳。但在高并發(fā)場景下如果每毫秒都在溢出這個忙等待會吃掉 CPU 時間片是個性能隱患。如何解決呢 可以參考美團 Leaf 在生產(chǎn)環(huán)境驗證過的方案。你有其它更好的方案嗎歡迎在評論區(qū)討論。Spring 集成四層配置鏈光有算法不夠還得接入 Spring。這個項目的做法是標準的三層架構(gòu)。完整調(diào)用鏈路和架構(gòu)圖第一層yml 配置# application.ymlpubframe:id:workId:10# 當前機器的工作 IDcenterId:20# 當前數(shù)據(jù)中心 ID第二層配置屬性類ConfigurationProperties(prefixpubframe.id)publicclassIdGenProperties{privatelongworkId0;// 工作機器ID (0~31)privatelongcenterId0;// 數(shù)據(jù)中心ID (0~31)// getter/setter/toString...}ConfigurationProperties把 yml 里的值自動綁到 Java 對象上。注意默認值都是 0——如果 yml 沒配兩臺機器都會拿到workId0, centerId0。第三層自動注冊 BeanSlf4jConfigurationEnableConfigurationProperties(IdGenProperties.class)publicclassAutoConfiguration{BeanConditionalOnMissingBean(IdGenProperties.class)publicSnowflakeIdGeneratorsnowflakeIdWorker(IdGenPropertiesproperties){SnowflakeIdGeneratorgeneratornewSnowflakeIdGenerator(properties.getWorkId(),// workId 10properties.getCenterId()// centerId 20);log.info(bean [{}] properties [{}],generator,properties);returngenerator;}}Bean把SnowflakeIdGenerator注冊為 Spring 容器里的 BeanConditionalOnMissingBean保證如果你沒自定義就用默認的?？雌饋砗苊缹Π膳渲?、綁定、注冊三層各司其職開箱即用?？吹竭@里你可能覺得這個實現(xiàn)挺規(guī)范的。別急坑在后面我們一個一個的分析并解決。三個坑一個比一個狠?? 坑 1時鐘回撥直接拋異常3 毫秒就 500if(timestamplastTimestamp){thrownewRuntimeException(String.format(Clock moved backwards. Refusing to generate id for %d milliseconds,lastTimestamp-timestamp));}時鐘一回撥直接throw RuntimeException。你知道這意味著什么嗎生產(chǎn)環(huán)境的 NTP 服務(wù)每隔一段時間會校準時間回撥幾毫秒是家常便飯。只要回撥發(fā)生任何調(diào)用nextId()的業(yè)務(wù)代碼就會收到一個RuntimeException如果沒有 catch就是 500 錯誤。正確的做法是什么分級處理if(timestamplastTimestamp){longoffsetlastTimestamp-timestamp;if(offset5){// 5ms 以內(nèi)的微小回撥等它追上來Thread.sleep(offset1);// 等兩倍時間留余量timestamptimeGen();if(timestamplastTimestamp){thrownewRuntimeException(Clock still moving backwards);}}elseif(offset100){// 100ms 以內(nèi)的中等回撥用上次的時間戳繼續(xù)生成序列號遞增timestamplastTimestamp;}else{// 超過 100ms 的大回撥真的出問題了拋異常thrownewRuntimeException(Clock moved backwards too much: offsetms);}}總結(jié)小回撥等一等中回撥借用上次時間戳硬撐大回撥才拋異常。這才是生產(chǎn)級的處理方式。?? 坑 2workerId 寫在 yml 里兩臺機器配了一樣的 IDpubframe:id:workId:10#運維拷配置的時候忘記改了centerId:20workId和centerId直接寫死在配置文件里。想象一下這個場景運維要部署兩臺機器拷了一份配置文件改改數(shù)據(jù)庫地址就上了。結(jié)果workId忘了改——兩臺機器都是workId10, centerId20。后果是什么兩臺機器在同一毫秒內(nèi)用相同的序列號生成完全一樣的 ID。雪花算法的 “全局唯一” 保證是建立在 “每臺機器的 workerId 不同” 這個前提上。workerId 撞了唯一性就崩了。正確的做法是什么讓 workerId 自動分配而不是靠人記著改配置方案一從 ZooKeeper / Redis 自動獲取啟動時注冊臨時節(jié)點拿到全局唯一的 workerIdBeanpublicSnowflakeIdGeneratorsnowflakeIdWorker(IdGenPropertiesproperties,ZookeeperClientzkClient){// 啟動時從 ZK 占一個臨時節(jié)點longworkerIdzkClient.createEphemeralSequential(/snowflake/worker-);longdatacenterIdproperties.getCenterId();// 機房級別還是配returnnewSnowflakeIdGenerator(workerId,datacenterId);}方案二基于 IP 地址末兩段計算int workerId (ip[2] 0x1F); // 取 IP 第三段低 5 位 int centerId (ip[3] 0x1F); // 取 IP 第四段低 5 位總之凡是靠人記著改的配置遲早會有人忘記修改。?? 坑 3synchronized 全局鎖高并發(fā)下排隊publicsynchronizedlongnextId(){注意這個synchronized——它鎖的是整個SnowflakeIdGenerator實例對象。也就是說不管有多少個線程同時調(diào)用nextId()都得排隊一個一個來。在單機低并發(fā)場景下這沒什么問題。但如果你的服務(wù)每秒要生成幾萬個 ID所有線程都在這一把鎖上排隊這里就成了整個系統(tǒng)的吞吐量瓶頸。有沒有更好的方案有——用 CASCompare-And-Swap無鎖實現(xiàn)思路用 AtomicLong 代替 synchronized。把 lastTimestamp 和 sequence 打包成一個 long 用 CAS 操作原子更新失敗就重試。publiclongnextId(){longcurrent;longnext;do{currentlastTimestamp.get();// ... 計算 next}while(!lastTimestamp.compareAndSet(current,next));returnnext;}但 CAS 方案實現(xiàn)復(fù)雜度高很多需要壓測驗證是否值得做。對于這個項目的并發(fā)量synchronized其實就夠用——但是你要知道它的天花板在哪里。雪花算法面試怎么答面試官問說說雪花算法你可以這樣答第一層結(jié)構(gòu)Snowflake 把 64 位 long 分成五段——1 位符號位、41 位時間戳差值、5 位數(shù)據(jù)中心、5 位機器 ID、12 位序列號。時間戳保證趨勢遞增機器 ID 保證分布式不撞車序列號保證同毫秒內(nèi)不重復(fù)。第二層核心操作每段左移量等于右邊所有段的位數(shù)之和最后按位或拼裝。序列號溢出用掩碼(seq1) mask檢測歸零后自旋等下一毫秒。第三層生產(chǎn)問題最大風(fēng)險是時鐘回撥。生產(chǎn)環(huán)境 NTP 校時可能導(dǎo)致幾毫秒的回撥直接拋異常會導(dǎo)致 500錯誤。正確做法是分級處理——小回撥等待、中回撥借用時間戳、大回撥降級到號段模式。另外 workerId 不能寫在配置文件要靠注冊中心自動分配。生產(chǎn)環(huán)境 Checklist檢查項常見坑正確做法時鐘回撥直接拋異常 → 500分級處理等待 / 借用 / 降級workerId 分配yml 寫死 → 撞 IDZK/Redis 自動分配起始時間戳用 1970 年 → 2039 溢出設(shè)為項目上線日期線程安全無鎖 → ID 重復(fù)synchronized 或 CAS啟動校驗不檢查 → 大回撥流入線上持久化 lastTimestamp啟動時比對監(jiān)控告警無感知 → 出問題才知道回撥次數(shù)/幅度接入 Prometheus要不要自己寫我的建議是不要自己寫。美團 Leaf號段模式 Snowflake 雙模式生產(chǎn)驗證ShardingSphere 內(nèi)置配合分庫分表直接用MyBatis-PlusIdType.ASSIGN_ID默認就是雪花算法Spring 生態(tài)spring-context-support里有現(xiàn)成實現(xiàn)自己寫適合學(xué)習(xí)和面試生產(chǎn)環(huán)境還是用成熟的開源方案——它們幫你處理了你沒想到的邊界情況。老炮點評這篇文章我們從一個真實項目的手寫雪花算法出發(fā)我們看到了位結(jié)構(gòu)設(shè)計的精妙41 位時間戳 10 位機器標識 12 位序列號64 位 long 剛好用完每一比特都不浪費。位運算的性能之美掩碼檢測溢出、移位拼裝 ID用代替if用|代替一條指令搞定。時鐘回撥的殘酷現(xiàn)實算法假設(shè)時間是單調(diào)向前的但物理世界的時鐘會被 NTP 校準、被閏秒打亂、被運維手動改。3 毫秒的回撥就能讓線報 500錯誤。配置化 workerId 的隱患靠人記著改的配置遲早有人忘記改。synchronized 的天花板簡單有效但高并發(fā)下是瓶頸。最后送一句話分布式系統(tǒng)里沒有銀彈雪花算法也不例外。它用對時間的依賴換來了簡單和高效但時間本身是不可靠的——這就是工程世界的永恒矛盾。在·下一篇預(yù)告《workerId 配錯兩臺機器生成了一樣的 ID》這篇文章里我說了workerId 寫在 yml 里遲早有人忘記改——這不是假設(shè)是真實發(fā)生過的生產(chǎn)事故。下一篇我把這個坑的前因后果完整講一遍怎么發(fā)現(xiàn)的、怎么排查的、怎么修的。我是老炮18 年 Java 老兵仍在一線。關(guān)注「老炮踩坑錄」真實案例幫你少踩坑。 Java雪花算法Snowflake實戰(zhàn)：41位時間戳的三個坑（時鐘回撥、workerId、位運算）
老炮踩坑錄 · D08 · 技術(shù)深挖系列· 基于「企業(yè)融合平臺」真實源碼· 逐行拆解手寫 Snowflake ID 生成器· 關(guān)鍵詞3大坑 · 位運算 · 時鐘回撥 · 序列溢出 · workerId撞車 · CPU假死引子面試必問雪花算法這個項目里居然有人手寫了2026 年Java 21 LTS 成了生產(chǎn)標配Java 26 都發(fā)布了。分布式 ID 這個老話題依然是面試高頻考點——分庫分表后全局 ID 怎么生成十有八九會引出雪花算法然后面試官追一句“時鐘回撥怎么處理”很多人背過 Twitter Snowflake 的 64 位結(jié)構(gòu)面試時能默寫1 41 5 5 12 64但真讓你打開源碼逐行看位運算是怎么拼裝的、時鐘回撥是怎么檢測的、序列溢出是怎么處理的——大部分人都停在 “看懂結(jié)構(gòu)圖” 這一步?jīng)]真正讀過一行實現(xiàn)。巧了我翻的這個 2022 年的老項目里有人手寫了完整的雪花算法從位結(jié)構(gòu)設(shè)計到 Spring 集成一個都不落(la)。今天這篇我就拿著項目里真實的SnowflakeIdGenerator.java逐行拆給你看64 位 long 是怎么一段一段拼出來的synchronized為什么必須加時鐘回撥 3 毫秒就能讓線上報 500錯誤先看全貌雪花算法長什么樣子打開SnowflakeIdGenerator.java類注釋直接畫了一張結(jié)構(gòu)圖/** * Twitter_Snowflake * SnowFlake的結(jié)構(gòu)如下(每部分用-分開): * 0 - 0000000000 0000000000 0000000000 0000000000 0 - 00000 - 00000 - 000000000000 * 1位標識由于long基本類型在Java中是帶符號的最高位是符號位正數(shù)是0負數(shù)是1 * 41位時間截(毫秒級)注意41位時間截不是存儲當前時間的時間截而是存儲時間截的差值 * 41位的時間截可以使用69年 * 10位的數(shù)據(jù)機器位可以部署在1024個節(jié)點 * 12位序列毫秒內(nèi)的計數(shù)支持每個節(jié)點每毫秒產(chǎn)生4096個ID序號 * 加起來剛好64位為一個Long型。 */publicclassSnowflakeIdGenerator{// ...}注釋寫得規(guī)規(guī)矩矩一看就是從 Twitter 原版翻譯過來的。但光看注釋不夠我們得一段一段拆開看。64 位 long 的位結(jié)構(gòu)設(shè)計每一比特都不浪費五段劃分圖示如下段位數(shù)作用容量符號位1保證 ID 為正Java long 帶符號固定 0時間戳41毫秒級時間差值約 69 年數(shù)據(jù)中心 ID5區(qū)分機房0~31機器 ID5區(qū)分同機房節(jié)點0~31序列號12同毫秒內(nèi)遞增0~4095起始時間戳為什么是 2015 年privatefinallongtwepoch1420041600000L;// 2015-01-01 00:00:00 UTC注意41 位存的不是System.currentTimeMillis()而是當前時間 - twepoch的差值。為什么因為 41 位最多表示2^41 - 1 2,199,023,255,551毫秒換算成年2,199,023,255,551 / 1000 / 60 / 60 / 24 / 365 ≈ 69.7 年如果從 1970 年算起到 2039 年就溢出了。但從 2015 年算起能撐到2084 年。這就是為什么twepoch很重要——它決定了 ID 生成器的壽命。你完全可以把它設(shè)成項目上線的那天最大化利用這 41 位。位移量低位段位數(shù)之和 高位段移位量privatefinallongsequenceBits12L;privatefinallongworkerIdShiftsequenceBits;// 12privatefinallongdatacenterIdShiftsequenceBitsworkerIdBits;// 17privatefinallongtimestampLeftShiftsequenceBitsworkerIdBitsdatacenterIdBits;// 22發(fā)現(xiàn)規(guī)律了嗎每一段的左移量等于它右邊所有段的位數(shù)之和。序列號不移位最右邊 機器ID左移 12 位右邊有 12 位序列號 數(shù)據(jù)中心左移 17 位右邊有 12 5 17 位 時間戳左移 22 位右邊有 12 5 5 22 位這樣設(shè)計的好處是每段在 64 位 long 中各占各的位置互不干擾最后用按位或|拼裝即可。就像五條鐵軌每列火車走自己的道永遠不會撞車。掩碼的妙用用位運算代替 if 判斷最大值計算privatefinallongmaxWorkerId-1L^(-1LworkerIdBits);// 31privatefinallongmaxDatacenterId-1L^(-1LdatacenterIdBits);// 31privatefinallongsequenceMask-1L^(-1LsequenceBits);// 4095第一次看這段代碼的人大概率會懵-1L ^ (-1L 5)是什么鬼別急拆成二進制看就清楚了-1L 的二進制 11111111 11111111 ... 1111111164 個 1 -1L 5 11111111 11111111 ... 11100000低 5 位變 0 異或^ 00000000 00000000 ... 00011111只有低 5 位是 1 31所以-1L ^ (-1L n)的效果就是生成一個低 n 位全為 1 的掩碼。5 位掩碼 0b11111 31workerId / datacenterId 的最大值12 位掩碼 0b111111111111 4095序列號的最大值序列號溢出檢測這是整段代碼里最精妙的一行sequence(sequence1)sequenceMask;當sequence 4095時(4095 1) 4095 4096 4095 0b1000000000000 0b111111111111 0加 1 后與掩碼做按位與超過 4095 自動歸零。不需要if (sequence 4095) sequence 0一條位運算搞定。這就是位運算的魅力把 “判斷 賦值” 兩步操作壓縮成了一步這在高頻調(diào)用的場景下性能差異是實打?qū)嵉母摺：诵乃惴?nextId()逐行拆解終于到了分析最核心的邏輯方法了。核心源碼我把完整源碼貼出來并逐行加上注釋publicsynchronizedlongnextId(){// ① 獲取當前時間戳毫秒longtimestamptimeGen();// ② 時鐘回退檢測當前時間 上次生成 ID 的時間 → 拋異常if(timestamplastTimestamp){thrownewRuntimeException(String.format(Clock moved backwards. Refusing to generate id for %d milliseconds,lastTimestamp-timestamp));}// ③ 同一毫秒內(nèi)的序列處理if(lastTimestamptimestamp){// 同一毫秒 → 序列號 1掩碼保證不超過 4095sequence(sequence1)sequenceMask;// 序列溢出回到 0→ 自旋等到下一毫秒if(sequence0){timestamptilNextMillis(lastTimestamp);}}// ④ 新的毫秒 → 序列重置為 0else{sequence0L;}// ⑤ 記錄本次時間戳lastTimestamptimestamp;// ⑥ 位運算拼裝 64 位 IDreturn((timestamp-twepoch)timestampLeftShift)// 時間戳差值左移 22 位|(datacenterIddatacenterIdShift)// 數(shù)據(jù)中心 ID 左移 17 位|(workerIdworkerIdShift)// 機器 ID 左移 12 位|sequence;// 序列號不移位}六個步驟nextId()方法的六大步驟流程圖舉個計算例子假設(shè)timestamp - twepoch 1000, datacenterId 20, workerId 10, sequence 5時間戳部分1000 22 4,194,304,000 數(shù)據(jù)中心 20 17 2,621,440 機器 ID 10 12 40,960 序列號 5 5 ──────────────────────────────────────── 按位或拼裝 4,196,966,405每段井水不犯河水按位或 拼裝。因為每段的二進制位互不重疊所以|運算等價于加法但語義更清晰——我是在組裝不是在相加。自旋等待tilNextMillis()protectedlongtilNextMillis(longlastTimestamp){longtimestamptimeGen();while(timestamplastTimestamp){timestamptimeGen();// CPU 空轉(zhuǎn)浪費時間片}returntimestamp;}序列號用完了怎么辦死循環(huán)等等到下一毫秒再來。這個while循環(huán)叫busy-wait忙等待——CPU 在空轉(zhuǎn)什么都不干就反復(fù)問到下一毫秒了沒。在正常情況下一毫秒很快就過去了循環(huán)個幾十到幾百次就拿到新時間戳。但在高并發(fā)場景下如果每毫秒都在溢出這個忙等待會吃掉 CPU 時間片是個性能隱患。如何解決呢 可以參考美團 Leaf 在生產(chǎn)環(huán)境驗證過的方案。你有其它更好的方案嗎歡迎在評論區(qū)討論。Spring 集成四層配置鏈光有算法不夠還得接入 Spring。這個項目的做法是標準的三層架構(gòu)。完整調(diào)用鏈路和架構(gòu)圖第一層yml 配置# application.ymlpubframe:id:workId:10# 當前機器的工作 IDcenterId:20# 當前數(shù)據(jù)中心 ID第二層配置屬性類ConfigurationProperties(prefixpubframe.id)publicclassIdGenProperties{privatelongworkId0;// 工作機器ID (0~31)privatelongcenterId0;// 數(shù)據(jù)中心ID (0~31)// getter/setter/toString...}ConfigurationProperties把 yml 里的值自動綁到 Java 對象上。注意默認值都是 0——如果 yml 沒配兩臺機器都會拿到workId0, centerId0。第三層自動注冊 BeanSlf4jConfigurationEnableConfigurationProperties(IdGenProperties.class)publicclassAutoConfiguration{BeanConditionalOnMissingBean(IdGenProperties.class)publicSnowflakeIdGeneratorsnowflakeIdWorker(IdGenPropertiesproperties){SnowflakeIdGeneratorgeneratornewSnowflakeIdGenerator(properties.getWorkId(),// workId 10properties.getCenterId()// centerId 20);log.info(bean [{}] properties [{}],generator,properties);returngenerator;}}Bean把SnowflakeIdGenerator注冊為 Spring 容器里的 BeanConditionalOnMissingBean保證如果你沒自定義就用默認的?？雌饋砗苊缹Π膳渲?、綁定、注冊三層各司其職開箱即用?？吹竭@里你可能覺得這個實現(xiàn)挺規(guī)范的。別急坑在后面我們一個一個的分析并解決。三個坑一個比一個狠?? 坑 1時鐘回撥直接拋異常3 毫秒就 500if(timestamplastTimestamp){thrownewRuntimeException(String.format(Clock moved backwards. Refusing to generate id for %d milliseconds,lastTimestamp-timestamp));}時鐘一回撥直接throw RuntimeException。你知道這意味著什么嗎生產(chǎn)環(huán)境的 NTP 服務(wù)每隔一段時間會校準時間回撥幾毫秒是家常便飯。只要回撥發(fā)生任何調(diào)用nextId()的業(yè)務(wù)代碼就會收到一個RuntimeException如果沒有 catch就是 500 錯誤。正確的做法是什么分級處理if(timestamplastTimestamp){longoffsetlastTimestamp-timestamp;if(offset5){// 5ms 以內(nèi)的微小回撥等它追上來Thread.sleep(offset1);// 等兩倍時間留余量timestamptimeGen();if(timestamplastTimestamp){thrownewRuntimeException(Clock still moving backwards);}}elseif(offset100){// 100ms 以內(nèi)的中等回撥用上次的時間戳繼續(xù)生成序列號遞增timestamplastTimestamp;}else{// 超過 100ms 的大回撥真的出問題了拋異常thrownewRuntimeException(Clock moved backwards too much: offsetms);}}總結(jié)小回撥等一等中回撥借用上次時間戳硬撐大回撥才拋異常。這才是生產(chǎn)級的處理方式。?? 坑 2workerId 寫在 yml 里兩臺機器配了一樣的 IDpubframe:id:workId:10#運維拷配置的時候忘記改了centerId:20workId和centerId直接寫死在配置文件里。想象一下這個場景運維要部署兩臺機器拷了一份配置文件改改數(shù)據(jù)庫地址就上了。結(jié)果workId忘了改——兩臺機器都是workId10, centerId20。后果是什么兩臺機器在同一毫秒內(nèi)用相同的序列號生成完全一樣的 ID。雪花算法的 “全局唯一” 保證是建立在 “每臺機器的 workerId 不同” 這個前提上。workerId 撞了唯一性就崩了。正確的做法是什么讓 workerId 自動分配而不是靠人記著改配置方案一從 ZooKeeper / Redis 自動獲取啟動時注冊臨時節(jié)點拿到全局唯一的 workerIdBeanpublicSnowflakeIdGeneratorsnowflakeIdWorker(IdGenPropertiesproperties,ZookeeperClientzkClient){// 啟動時從 ZK 占一個臨時節(jié)點longworkerIdzkClient.createEphemeralSequential(/snowflake/worker-);longdatacenterIdproperties.getCenterId();// 機房級別還是配returnnewSnowflakeIdGenerator(workerId,datacenterId);}方案二基于 IP 地址末兩段計算int workerId (ip[2] 0x1F); // 取 IP 第三段低 5 位 int centerId (ip[3] 0x1F); // 取 IP 第四段低 5 位總之凡是靠人記著改的配置遲早會有人忘記修改。?? 坑 3synchronized 全局鎖高并發(fā)下排隊publicsynchronizedlongnextId(){注意這個synchronized——它鎖的是整個SnowflakeIdGenerator實例對象。也就是說不管有多少個線程同時調(diào)用nextId()都得排隊一個一個來。在單機低并發(fā)場景下這沒什么問題。但如果你的服務(wù)每秒要生成幾萬個 ID所有線程都在這一把鎖上排隊這里就成了整個系統(tǒng)的吞吐量瓶頸。有沒有更好的方案有——用 CASCompare-And-Swap無鎖實現(xiàn)思路用 AtomicLong 代替 synchronized。把 lastTimestamp 和 sequence 打包成一個 long 用 CAS 操作原子更新失敗就重試。publiclongnextId(){longcurrent;longnext;do{currentlastTimestamp.get();// ... 計算 next}while(!lastTimestamp.compareAndSet(current,next));returnnext;}但 CAS 方案實現(xiàn)復(fù)雜度高很多需要壓測驗證是否值得做。對于這個項目的并發(fā)量synchronized其實就夠用——但是你要知道它的天花板在哪里。雪花算法面試怎么答面試官問說說雪花算法你可以這樣答第一層結(jié)構(gòu)Snowflake 把 64 位 long 分成五段——1 位符號位、41 位時間戳差值、5 位數(shù)據(jù)中心、5 位機器 ID、12 位序列號。時間戳保證趨勢遞增機器 ID 保證分布式不撞車序列號保證同毫秒內(nèi)不重復(fù)。第二層核心操作每段左移量等于右邊所有段的位數(shù)之和最后按位或拼裝。序列號溢出用掩碼(seq1) mask檢測歸零后自旋等下一毫秒。第三層生產(chǎn)問題最大風(fēng)險是時鐘回撥。生產(chǎn)環(huán)境 NTP 校時可能導(dǎo)致幾毫秒的回撥直接拋異常會導(dǎo)致 500錯誤。正確做法是分級處理——小回撥等待、中回撥借用時間戳、大回撥降級到號段模式。另外 workerId 不能寫在配置文件要靠注冊中心自動分配。生產(chǎn)環(huán)境 Checklist檢查項常見坑正確做法時鐘回撥直接拋異常 → 500分級處理等待 / 借用 / 降級workerId 分配yml 寫死 → 撞 IDZK/Redis 自動分配起始時間戳用 1970 年 → 2039 溢出設(shè)為項目上線日期線程安全無鎖 → ID 重復(fù)synchronized 或 CAS啟動校驗不檢查 → 大回撥流入線上持久化 lastTimestamp啟動時比對監(jiān)控告警無感知 → 出問題才知道回撥次數(shù)/幅度接入 Prometheus要不要自己寫我的建議是不要自己寫。美團 Leaf號段模式 Snowflake 雙模式生產(chǎn)驗證ShardingSphere 內(nèi)置配合分庫分表直接用MyBatis-PlusIdType.ASSIGN_ID默認就是雪花算法Spring 生態(tài)spring-context-support里有現(xiàn)成實現(xiàn)自己寫適合學(xué)習(xí)和面試生產(chǎn)環(huán)境還是用成熟的開源方案——它們幫你處理了你沒想到的邊界情況。老炮點評這篇文章我們從一個真實項目的手寫雪花算法出發(fā)我們看到了位結(jié)構(gòu)設(shè)計的精妙41 位時間戳 10 位機器標識 12 位序列號64 位 long 剛好用完每一比特都不浪費。位運算的性能之美掩碼檢測溢出、移位拼裝 ID用代替if用|代替一條指令搞定。時鐘回撥的殘酷現(xiàn)實算法假設(shè)時間是單調(diào)向前的但物理世界的時鐘會被 NTP 校準、被閏秒打亂、被運維手動改。3 毫秒的回撥就能讓線報 500錯誤。配置化 workerId 的隱患靠人記著改的配置遲早有人忘記改。synchronized 的天花板簡單有效但高并發(fā)下是瓶頸。最后送一句話分布式系統(tǒng)里沒有銀彈雪花算法也不例外。它用對時間的依賴換來了簡單和高效但時間本身是不可靠的——這就是工程世界的永恒矛盾。在·下一篇預(yù)告《workerId 配錯兩臺機器生成了一樣的 ID》這篇文章里我說了workerId 寫在 yml 里遲早有人忘記改——這不是假設(shè)是真實發(fā)生過的生產(chǎn)事故。下一篇我把這個坑的前因后果完整講一遍怎么發(fā)現(xiàn)的、怎么排查的、怎么修的。我是老炮18 年 Java 老兵仍在一線。關(guān)注「老炮踩坑錄」真實案例幫你少踩坑。