做分布式數(shù)據(jù)庫(kù)這幾年踩過(guò)的分片坑比吃過(guò)的鹽還多。早期做電商訂單庫(kù)拆分用最簡(jiǎn)單的取模算法懟到 6 個(gè)分片上線三個(gè)月數(shù)據(jù)就歪了——大客戶一個(gè)訂單表壓垮整個(gè)分片。后來(lái)把常用分片算法挨個(gè)啃了一遍才發(fā)現(xiàn)每個(gè)算法背后都有一筆明賬均勻性怎么算、熱點(diǎn)怎么擋、擴(kuò)容要搬多少數(shù)據(jù)這些參數(shù)不提前想清楚早晚要還技術(shù)債。這篇就把我在實(shí)際項(xiàng)目中用過(guò)的數(shù)據(jù)庫(kù)分片算法完整梳理一遍從原理到取舍從計(jì)算公式到避坑經(jīng)驗(yàn)一次性講透。1. 為什么要做數(shù)據(jù)分片先搞懂分片在解決什么問(wèn)題分片Sharding本質(zhì)上就是把一份大邏輯庫(kù)拆成多份物理庫(kù)每一份存一部分?jǐn)?shù)據(jù)合起來(lái)對(duì)外仍是一個(gè)完整的邏輯庫(kù)。這個(gè)概念聽(tīng)起來(lái)簡(jiǎn)單但觸發(fā)它的一定是業(yè)務(wù)側(cè)繞不過(guò)去的瓶頸而不是技術(shù)上的炫技需求。1.1 單機(jī)數(shù)據(jù)庫(kù)的三個(gè)天花板任何數(shù)據(jù)庫(kù)落到單機(jī)上都會(huì)撞上三重墻。第一是存儲(chǔ)容量墻一臺(tái)物理機(jī)磁盤(pán)就算做到幾十 TB數(shù)據(jù)量上來(lái)之后備份、恢復(fù)、擴(kuò)容的時(shí)間會(huì)指數(shù)級(jí)上升全量備份跑一整天的大庫(kù)你根本不敢隨便動(dòng)。第二是連接數(shù)墻應(yīng)用側(cè)的連接池、查詢并發(fā)全壓在一個(gè)實(shí)例上CPU 和 IO 先扛不住很多系統(tǒng)的實(shí)際瓶頸根本不是 SQL 慢而是連接數(shù)把數(shù)據(jù)庫(kù)拖垮了。第三是寫(xiě)入吞吐墻單機(jī)寫(xiě)入上限受磁盤(pán)順序?qū)懰俣群腿罩舅⒈P(pán)限制一旦業(yè)務(wù)進(jìn)入千萬(wàn)級(jí)日訂單、億級(jí)日志的規(guī)模單實(shí)例再好的硬件也頂不住。這三堵墻加起來(lái)就到了必須分片的臨界點(diǎn)。很多人會(huì)問(wèn)不是有主從復(fù)制、讀寫(xiě)分離嗎主從復(fù)制解決的是可用性和讀擴(kuò)展寫(xiě)流量始終要落在主庫(kù)上主庫(kù)的命門(mén)并沒(méi)有被真正打開(kāi)。讀寫(xiě)分離同樣如此它只是把讀壓力卸掉了寫(xiě)入和存儲(chǔ)的壓力依然集中在單點(diǎn)。1.2 分片帶來(lái)的兩個(gè)核心收益分片之后最直接的收益是水平擴(kuò)展能力。加機(jī)器就擴(kuò)容數(shù)據(jù)可以被攤到更多節(jié)點(diǎn)上理論上的吞吐和容量能做到線性擴(kuò)展。這里的關(guān)鍵在于線性二字實(shí)現(xiàn)得好不好直接由分片算法決定。第二個(gè)收益是縮小了單個(gè)故障的影響面。一個(gè)分片掛了其他分片還在工作切換到可用分片也能繼續(xù)完成大部分業(yè)務(wù)比整個(gè)庫(kù)不可用要強(qiáng)得多。更要緊的是分片不是簡(jiǎn)單地把數(shù)據(jù)拆開(kāi)而是要把負(fù)載拆開(kāi)。讓每一臺(tái)機(jī)器都承載差不多數(shù)量級(jí)的數(shù)據(jù)和查詢流量避免木桶效應(yīng)——集群里只要有一個(gè)分片被熱點(diǎn)流量打爆整體系統(tǒng)的響應(yīng)就會(huì)跟著崩掉。1.3 分片前必須想清楚的四個(gè)問(wèn)題動(dòng)手分片之前我強(qiáng)烈建議先把下面四個(gè)問(wèn)題答清楚否則后面返工成本極高。問(wèn)題一分片維度和分片鍵選什么分片鍵是數(shù)據(jù)分發(fā)的依據(jù)可以是用戶 ID、訂單 ID、租戶 ID、時(shí)間戳等。分片鍵必須滿足兩個(gè)基本要求業(yè)務(wù)查詢中高頻出現(xiàn)的條件和數(shù)據(jù)分布足夠均勻。選錯(cuò)了分片鍵比如用性別做分片鍵只有兩個(gè)值等于自掘墳?zāi)埂?wèn)題二擴(kuò)容時(shí)數(shù)據(jù)遷移方案是什么大部分分片算法在節(jié)點(diǎn)數(shù)量變化時(shí)都涉及數(shù)據(jù)遷移。遷移的代價(jià)有多大取決于算法本身的設(shè)計(jì)。這一點(diǎn)必須在選型時(shí)看清楚否則后期擴(kuò)容的時(shí)候運(yùn)維同學(xué)會(huì)想打人。問(wèn)題三跨分片查詢能不能接受分片之后一條 SQL 如果沒(méi)帶分片鍵就得跑遍所有分片再匯總結(jié)果這種全片掃描代價(jià)非常大。業(yè)務(wù)設(shè)計(jì)上必須盡量避免跨分片操作比如按用戶分片就要把該用戶的訂單、購(gòu)物車(chē)、優(yōu)惠券都落到同一分片。問(wèn)題四全局唯一 ID 怎么生成分片之后多節(jié)點(diǎn)并發(fā)生成 ID不能依賴單庫(kù)自增。常見(jiàn)的方案有雪花算法、號(hào)段模式、UUID 等這一步如果不配套設(shè)計(jì)后面做數(shù)據(jù)合并、分頁(yè)排序會(huì)很痛苦。分片算法就是在回答數(shù)據(jù)到底該往哪個(gè)節(jié)點(diǎn)上放這個(gè)核心問(wèn)題。接下來(lái)我把實(shí)戰(zhàn)中最常用的幾種算法逐一拆開(kāi)講每種都帶上我實(shí)際項(xiàng)目中的參數(shù)計(jì)算過(guò)程和踩坑心得。2. 哈希分片最直接的均勻分配方案哈希分片是入門(mén)最先接觸到的方案原理簡(jiǎn)單到一句話能講清對(duì)分片鍵取哈希值再對(duì)分片數(shù)量取模得到分片編號(hào)。2.1 取模計(jì)算過(guò)程的完整示例假設(shè)訂單表按訂單號(hào) order_id 分片總共有 4 個(gè)分片節(jié)點(diǎn)編號(hào) 0~3。代碼層面就是shard_id hash(order_id) % 4拿真實(shí)數(shù)據(jù)走一遍計(jì)算。取一條訂單號(hào)NO20250115001先用一種簡(jiǎn)單的哈希函數(shù)比如 Java 的String.hashCode()算出整數(shù)假設(shè)結(jié)果是 2987645341那么2987645341 % 4 1這條訂單落到分片 1。再取另一條NO20250115002哈希值為 1732094587計(jì)算1732094587 % 4 3落到分片 3。這樣所有訂單就按訂單號(hào)被均勻撒到了 4 個(gè)分片里。這里有一個(gè)細(xì)節(jié)問(wèn)題哈希函數(shù)選誰(shuí)業(yè)界最常見(jiàn)的做法有幾種。一是直接用語(yǔ)言內(nèi)置的字符串哈希如 Java 的hashCode但要注意它是有符號(hào)整數(shù)可能返回負(fù)數(shù)取模前需要先取絕對(duì)值。二是用 MD5 截取前 N 位再轉(zhuǎn)整數(shù)這種方式更均勻但計(jì)算成本略高。三是用 CRC32速度快且分布好常用于日志類數(shù)據(jù)。我個(gè)人建議用 CRC32尤其是分片鍵是字符串型訂單號(hào)、手機(jī)號(hào)、設(shè)備號(hào)這類值時(shí)分布效果相當(dāng)穩(wěn)定。實(shí)測(cè)幾百萬(wàn)條訂單數(shù)據(jù)4 分片時(shí)各分片數(shù)據(jù)量相差不會(huì)超過(guò) 2%。2.2 哈希分片的優(yōu)勢(shì)與局限優(yōu)勢(shì)非常突出實(shí)現(xiàn)極其簡(jiǎn)單幾行代碼就完成路由只要哈希函數(shù)選得好數(shù)據(jù)分布非常均勻讀寫(xiě)路由是 O(1) 時(shí)間查詢性能穩(wěn)定。局限也同樣明顯。最致命的是擴(kuò)容災(zāi)難。當(dāng)分片數(shù)從 4 變成 5 時(shí)取?；鶖?shù)變了幾乎所有數(shù)據(jù)的哈希值對(duì) 5 取模的結(jié)果都會(huì)變化意味著大量數(shù)據(jù)需要遷移。舉個(gè)具體例子原本 map 到分片 1 的數(shù)據(jù)重新計(jì)算后可能映射到分片 0、2、4 等任意位置。實(shí)際擴(kuò)容中4 個(gè)分片擴(kuò)到 5 個(gè)往往要遷移 80% 左右的數(shù)據(jù)這種成本在數(shù)據(jù)量大的時(shí)候幾乎是不可接受的。第二個(gè)局限是不支持范圍查詢。訂單號(hào)相近的數(shù)據(jù)會(huì)被哈希到完全不同節(jié)點(diǎn)例如訂單NO20250115001和NO20250115002很可能不在同一個(gè)分片業(yè)務(wù)如果想查今天所有訂單只能全片掃描再合并性能很糟糕。2.3 日常項(xiàng)目里的適用場(chǎng)景與改良方案哈希分片最適合的場(chǎng)景是寫(xiě)多讀少、查詢高度依賴分片鍵的單點(diǎn)查詢場(chǎng)景。典型的例子是消息流水表、日志表、用戶基礎(chǔ)信息表。查詢時(shí)帶上用戶 ID 或消息 ID 這種分片鍵直接路由到目標(biāo)分片性能非常理想。對(duì)擴(kuò)容災(zāi)難這個(gè)硬傷業(yè)界有兩個(gè)改良方向。一個(gè)是雙倍擴(kuò)容法擴(kuò)容時(shí)只從 1 個(gè)分片擴(kuò)到 2 個(gè)、2 個(gè)擴(kuò)到 4 個(gè)、4 個(gè)擴(kuò)到 8 個(gè)保持分片數(shù)為 2 的冪。這樣取?？梢赞D(zhuǎn)化為位運(yùn)算原來(lái)在同一分片的數(shù)據(jù)擴(kuò)容后只會(huì)被拆到兩個(gè)相關(guān)分片遷移量減少到 50%。具體的對(duì)應(yīng)關(guān)系是擴(kuò)容前分片 i擴(kuò)容后只會(huì)落在 i 或 i 原分片數(shù) 這兩個(gè)新分片之一。另一個(gè)改良方案是一致性哈希這個(gè)下面專門(mén)講。如果已經(jīng)明確未來(lái)要多次擴(kuò)容建議直接上一致性哈希不要用裸取模——我見(jiàn)過(guò)好幾個(gè)團(tuán)隊(duì)因?yàn)閳D省事用取模后來(lái)擴(kuò)容時(shí)加班整個(gè)周末搬數(shù)據(jù)。3. 范圍分片給業(yè)務(wù)查詢空間換便利范圍分片是最樸素的分片策略它的核心思想是預(yù)先劃定數(shù)據(jù)區(qū)間每個(gè)分片負(fù)責(zé)一段連續(xù)范圍的數(shù)據(jù)。比如用戶表按用戶 ID 劃分[1, 1000000] 落在分片 0[1000001, 2000000] 落在分片 1如此類推。3.1 怎么定范圍邊界才算合理范圍分片的關(guān)鍵在于區(qū)間邊界的確定。這個(gè)不能拍腦袋要用真實(shí)數(shù)據(jù)分布來(lái)推算。假設(shè)用戶總量預(yù)估 2000 萬(wàn)準(zhǔn)備分 4 片那按平均分布可以每片劃 500 萬(wàn)的范圍。但實(shí)際業(yè)務(wù)中用戶增長(zhǎng)是不均勻的早期用戶密集后期用戶跳躍增長(zhǎng)固定的范圍很快就會(huì)讓不同節(jié)點(diǎn)數(shù)據(jù)量拉開(kāi)差距。所以我更推薦的做法是預(yù)分塊 動(dòng)態(tài)調(diào)整。比如把 0~2 億的用戶 ID 空間先切成 200 個(gè)小區(qū)間塊每塊 100 萬(wàn)再把塊按順序組合分配給 4 個(gè)實(shí)際分片。如果發(fā)現(xiàn)某些塊數(shù)據(jù)量遠(yuǎn)超均值就把這些塊重新分配甚至可以把一塊拆開(kāi)。這個(gè)做法的代價(jià)是路由表需要維護(hù)塊和分片的映射關(guān)系但換來(lái)的是動(dòng)態(tài)調(diào)整空間。3.2 范圍分片的最大優(yōu)點(diǎn)范圍查詢友好范圍分片能讓連續(xù)區(qū)間的數(shù)據(jù)在同一個(gè)分片內(nèi)這使得范圍查詢可以非常高效。比如按時(shí)間分片查詢2025 年 1 月的數(shù)據(jù)只需要定位到存有該時(shí)間段的分片執(zhí)行單分片查詢不需要跨片匯總。而且范圍分片的擴(kuò)容相對(duì)好做新加一個(gè)分片節(jié)點(diǎn)只需要把某個(gè)大區(qū)間的數(shù)據(jù)切一刀遷過(guò)去不需要大規(guī)模搬動(dòng)全量數(shù)據(jù)。從運(yùn)維角度來(lái)說(shuō)這種遷移比哈希取模溫和很多。還有一個(gè)隱性好處分片和業(yè)務(wù)邏輯能對(duì)齊。比如把北京用戶放在一個(gè)分片上海用戶放另一個(gè)分片配合本地部署可以降低跨地域訪問(wèn)延遲。但這種做法要額外評(píng)估數(shù)據(jù)傾斜風(fēng)險(xiǎn)如果某個(gè)城市用戶特別多單分片照樣被打爆。3.3 無(wú)法回避的痛點(diǎn)熱點(diǎn)與數(shù)據(jù)傾斜范圍分片的最大的坑就是熱點(diǎn)和傾斜。如果按時(shí)間分片遇到大促、秒殺這種流量峰值熱點(diǎn)分片會(huì)被瞬間打穿。如果按用戶 ID 范圍分片老用戶的活躍度通常高于新用戶靠前的分片請(qǐng)求量明顯偏高。我自己踩過(guò)一次坑某業(yè)務(wù)按手機(jī)號(hào)前 3 位做范圍分片想當(dāng)然地以為各地區(qū)流量均攤結(jié)果某幾個(gè)省份的號(hào)碼段活躍度極高對(duì)應(yīng)分片 CPU 持續(xù) 90% 以上而另外幾個(gè)分片閑得要數(shù)包。后來(lái)改造時(shí)換成了帶權(quán)重的分配策略把高熱的號(hào)碼段打散到多個(gè)分片才緩過(guò)來(lái)。所以范圍分片比較適合數(shù)據(jù)規(guī)律性強(qiáng)的場(chǎng)景如時(shí)間序列數(shù)據(jù)、明確知道各區(qū)間的訪問(wèn)密度相對(duì)均衡的場(chǎng)景比如 IoT 設(shè)備按區(qū)域編碼分片且各區(qū)域設(shè)備量接近。如果你的業(yè)務(wù)有明顯的頭部熱點(diǎn)需要非常慎重。4. 一致性哈希節(jié)點(diǎn)增刪不再引發(fā)海量遷移一致性哈希的誕生就是為了解決取模擴(kuò)容的數(shù)據(jù)遷移問(wèn)題。1997 年由幾位學(xué)者提出后來(lái)被廣泛應(yīng)用到分布式緩存、數(shù)據(jù)庫(kù)分片、負(fù)載均衡等領(lǐng)域。理解它先從一個(gè)虛擬的環(huán)說(shuō)起。4.1 哈希環(huán)上的路由機(jī)制假設(shè)我們有 4 個(gè)物理分片節(jié)點(diǎn)分別標(biāo)記為 N0、N1、N2、N3。哈希環(huán)是一個(gè)值域從 0 到 2^32-1 的圓形空間。第一步把每個(gè)節(jié)點(diǎn)用自己的標(biāo)識(shí)比如 IP端口取哈希值映射到環(huán)上的某個(gè)位置。第二步數(shù)據(jù)鍵取哈希值同樣映射到環(huán)上然后沿著環(huán)順時(shí)針?lè)较蛘业降谝粋€(gè)節(jié)點(diǎn)位置這個(gè)節(jié)點(diǎn)就是該數(shù)據(jù)的目標(biāo)分片。舉個(gè)例子。數(shù)據(jù)鍵user_128哈希值為 3684349194落在環(huán)上大概 3.4 億的位置。順時(shí)針找一圈最近的節(jié)點(diǎn)哈希位置可能是 N2 在 4.0 億處那么這條數(shù)據(jù)歸 N2。另一個(gè)數(shù)據(jù)鍵哈希值落在 5.0 億順時(shí)針繞完整個(gè)環(huán)發(fā)現(xiàn)最近的節(jié)點(diǎn)回到 N0數(shù)據(jù)就歸 N0。這樣定位的時(shí)間復(fù)雜度依然是 O(log N)因?yàn)楣?jié)點(diǎn)位置可以排序后用二分查找。常見(jiàn)實(shí)現(xiàn)里節(jié)點(diǎn)位置時(shí)通常用一個(gè)有序數(shù)組維護(hù)配合二分即可。4.2 節(jié)點(diǎn)增減時(shí)數(shù)據(jù)的影響范圍一致性哈希最漂亮的地方在于加入或移除一個(gè)節(jié)點(diǎn)時(shí)只影響環(huán)上該節(jié)點(diǎn)相鄰的一小段數(shù)據(jù)。具體來(lái)說(shuō)假設(shè)原環(huán)上有 N2、N3、N4 三個(gè)節(jié)點(diǎn)數(shù)據(jù) key 落在 N2 和 N3 之間的弧段按順時(shí)針規(guī)則映射到 N3。此時(shí)如果新加節(jié)點(diǎn) N5其哈希位置恰好落在 N2 和 N3 的弧段之間那么原本映射到 N3 的一些 key具體說(shuō)是落在 N2 到 N5 之間的 key會(huì)改為映射到 N5。其他弧段的數(shù)據(jù)完全不受影響。我用真實(shí)數(shù)據(jù)算過(guò)4 節(jié)點(diǎn)擴(kuò)到 5 節(jié)點(diǎn)遷移量約為全量數(shù)據(jù)的 1/5也就是 20%。而取模算法擴(kuò)到 5 節(jié)點(diǎn)時(shí)遷移量約 80%。兩者差距一眼就能看出來(lái)。同理刪掉一個(gè)節(jié)點(diǎn)也只需把該節(jié)點(diǎn)的數(shù)據(jù)遷移到它在環(huán)上的后繼節(jié)點(diǎn)其他節(jié)點(diǎn)不用動(dòng)。4.3 虛擬節(jié)點(diǎn)解決兩個(gè)主要問(wèn)題一致性哈希裸用會(huì)暴露兩個(gè)問(wèn)題。一是節(jié)點(diǎn)少時(shí)數(shù)據(jù)分布不均。4 個(gè)節(jié)點(diǎn)映射到環(huán)上如果位置扎堆某些弧段特別短導(dǎo)致映射到某節(jié)點(diǎn)的數(shù)據(jù)量偏大。二是節(jié)點(diǎn)退出時(shí)壓力會(huì)瞬間轉(zhuǎn)移到后繼節(jié)點(diǎn)造成節(jié)點(diǎn)雪崩。解決思路是引入虛擬節(jié)點(diǎn)。每個(gè)物理節(jié)點(diǎn)在環(huán)上放置多個(gè)虛擬節(jié)點(diǎn)比如物理機(jī) A 生成 A0、A1、A2……A150 共 150 個(gè)虛擬節(jié)點(diǎn)每個(gè)虛擬節(jié)點(diǎn)都映射到環(huán)上。數(shù)據(jù)定位到某個(gè)虛擬節(jié)點(diǎn)后再通過(guò)虛擬節(jié)點(diǎn)到物理節(jié)點(diǎn)的映射關(guān)系落到真實(shí)節(jié)點(diǎn)。虛擬節(jié)點(diǎn)的作用非常好理解物理節(jié)點(diǎn)不變的情況下虛擬節(jié)點(diǎn)越多環(huán)上的插樁越密集數(shù)據(jù)分布就越均勻。阿里在早期版本的 Memcached 客戶端里推薦虛擬節(jié)點(diǎn)數(shù)為 150~200 左右這個(gè)量級(jí)下各節(jié)點(diǎn)數(shù)據(jù)量差異可以控制在 5% 以內(nèi)。而節(jié)點(diǎn)退出時(shí)它的虛擬節(jié)點(diǎn)會(huì)稀疏分散在環(huán)上數(shù)據(jù)壓力可以被多個(gè)后繼節(jié)點(diǎn)分?jǐn)偠皇菓坏絾蝹€(gè)節(jié)點(diǎn)頭上。4.4 一致性哈希的落地范式在數(shù)據(jù)庫(kù)分片場(chǎng)景中一致性哈希不是只用在數(shù)據(jù)路由還可以配合元數(shù)據(jù)管理使用。比如分片元數(shù)據(jù)服務(wù)Shard Metadata Service記錄虛擬節(jié)點(diǎn)與物理節(jié)點(diǎn)的映射關(guān)系客戶端每次路由先查本地緩存的元數(shù)據(jù)表命中就直接定位沒(méi)命中則回源服務(wù)更新緩存。我實(shí)際項(xiàng)目中遇到過(guò)這樣的實(shí)現(xiàn)用一致性哈希把 256 個(gè)虛擬節(jié)點(diǎn)均勻布在環(huán)上每個(gè)物理分片持有 64 個(gè)虛擬節(jié)點(diǎn)4 臺(tái)物理節(jié)點(diǎn)。擴(kuò)容時(shí)新節(jié)點(diǎn)加入環(huán)上自動(dòng)接走一部分虛擬節(jié)點(diǎn)的數(shù)據(jù)路由遷移任務(wù)通過(guò)后臺(tái)線程按虛擬節(jié)點(diǎn)粒度執(zhí)行對(duì)業(yè)務(wù)的影響幾乎可以忽略。這種設(shè)計(jì)的好處是遷移的最小單位是虛擬節(jié)點(diǎn)而不是物理分片精細(xì)可控。需要注意的一點(diǎn)是一致性哈希解決了數(shù)據(jù)遷移量問(wèn)題但并沒(méi)有解決熱點(diǎn)問(wèn)題。如果某個(gè)數(shù)據(jù)鍵本身是超級(jí)熱點(diǎn)比如某個(gè)頭部大 V 的博文無(wú)論分片算法是什么該數(shù)據(jù)所在節(jié)點(diǎn)都會(huì)被高并發(fā)打爆。熱點(diǎn)數(shù)據(jù)需要另做二級(jí)緩存、讀寫(xiě)拆分或本地?zé)狳c(diǎn)標(biāo)識(shí)這屬于架構(gòu)層面的問(wèn)題。5. 虛擬桶分片兩階段映射的工業(yè)級(jí)方案虛擬桶在很多成熟的分布式數(shù)據(jù)庫(kù)內(nèi)部被作為核心分片機(jī)制最典型的案例是許多 NewSQL 數(shù)據(jù)庫(kù)的分片單元。它的思路是數(shù)據(jù)鍵先哈希到一個(gè)邏輯桶bucket桶再映射到物理節(jié)點(diǎn)。這里的桶數(shù)量通常遠(yuǎn)大于物理節(jié)點(diǎn)數(shù)量是節(jié)點(diǎn)數(shù)的幾十倍甚至幾百倍。5.1 桶怎么切、桶數(shù)怎么定假設(shè)集群有 4 個(gè)物理節(jié)點(diǎn)我通常會(huì)把桶數(shù)設(shè)為 4 的整數(shù)倍比如 256 個(gè)桶。這樣每個(gè)節(jié)點(diǎn)平均分到 64 個(gè)桶。數(shù)據(jù)定位分兩步。第一步bucket_id hash(data_key) % 256得到一個(gè) 0~255 的桶編號(hào)。第二步再查桶到節(jié)點(diǎn)的映射表確定該桶落在哪個(gè)物理節(jié)點(diǎn)。這里的映射表是獨(dú)立維護(hù)的可以動(dòng)態(tài)調(diào)整調(diào)整時(shí)只需要遷移對(duì)應(yīng)桶的數(shù)據(jù)其他桶不受影響。桶數(shù)選擇的經(jīng)驗(yàn)值桶數(shù)最好是物理節(jié)點(diǎn)數(shù)的倍數(shù)且盡量保持每個(gè)物理節(jié)點(diǎn)持有的桶數(shù)較為均衡。常見(jiàn)做法是桶數(shù)為節(jié)點(diǎn)數(shù)的 64 倍到 128 倍之間。桶數(shù)太多元數(shù)據(jù)表變大路由效率輕微下降桶數(shù)太少節(jié)點(diǎn)增減時(shí)每次遷移的數(shù)據(jù)粒度太粗不夠靈活。5.2 虛擬桶和一致性哈希的關(guān)系對(duì)照虛擬桶和一致性哈希都是在解決節(jié)點(diǎn)變化影響面問(wèn)題但實(shí)現(xiàn)思路不同。一致性哈希把節(jié)點(diǎn)和數(shù)據(jù)都投射到哈希環(huán)上數(shù)據(jù)定位靠環(huán)上的順時(shí)針?biāo)阉魈摂M桶則是在數(shù)據(jù)層和節(jié)點(diǎn)層之間插入了一個(gè)穩(wěn)定的桶層。從運(yùn)維視角看虛擬桶最大的優(yōu)勢(shì)是遷移可控性更強(qiáng)。做一致性哈希時(shí)節(jié)點(diǎn)位置由哈希決定遷移范圍是環(huán)上的弧段定位相對(duì)抽象而虛擬桶有顯式的桶列表運(yùn)維時(shí)可以直接查哪些桶在節(jié)點(diǎn) A 上一條 SQL 就能看到遷移清單執(zhí)行遷移任務(wù)時(shí)也容易做批次控制、限流和失敗重試。從熱點(diǎn)隔離的角度看虛擬桶也更好處理。如果發(fā)現(xiàn)某幾個(gè)桶數(shù)據(jù)量異常大可以把這些桶移動(dòng)到新節(jié)點(diǎn)或者把熱點(diǎn)桶拆細(xì)。這個(gè)在一致性哈希里做起來(lái)會(huì)更繞。5.3 桶映射表的設(shè)計(jì)細(xì)節(jié)桶到節(jié)點(diǎn)的映射表就是一個(gè)簡(jiǎn)單的數(shù)組或哈希表bucket 0 - node1 bucket 1 - node1 bucket 2 - node3 ... bucket 255 - node2元數(shù)據(jù)服務(wù)的實(shí)現(xiàn)上有兩種常見(jiàn)選擇。一種是把整個(gè)映射表放在配置中心客戶端啟動(dòng)時(shí)全量拉取并緩存后續(xù)通過(guò)監(jiān)聽(tīng)配置變更來(lái)更新另一種是放在獨(dú)立的元數(shù)據(jù)服務(wù)中客戶端通過(guò) RPC 查詢這個(gè)適合桶數(shù)極大比如上萬(wàn)的場(chǎng)景。我個(gè)人偏好第一種配置中心全量下發(fā) 本地緩存。因?yàn)橥皵?shù)幾千個(gè)以內(nèi)全量下發(fā)也就幾十 KB客戶端本地用哈希表存著路由時(shí)一次內(nèi)存查詢就搞定性能和直接取模差不了多少。但配置變更時(shí)一定要做好版本號(hào)管理避免客戶端持有舊映射表把數(shù)據(jù)寫(xiě)到錯(cuò)誤節(jié)點(diǎn)——這個(gè)我在生產(chǎn)環(huán)境遇到過(guò)一次配置發(fā)布沒(méi)校驗(yàn)版本號(hào)結(jié)果部分寫(xiě)請(qǐng)求落到了舊節(jié)點(diǎn)排查花了大半天。所以建議客戶端在寫(xiě)入操作中帶上元數(shù)據(jù)版本號(hào)服務(wù)端校驗(yàn)版本不一致時(shí)拒絕寫(xiě)入強(qiáng)制客戶端刷新后再重試。5.4 虛擬桶方案的實(shí)際選型建議如果你的數(shù)據(jù)庫(kù)集群需要進(jìn)行頻繁擴(kuò)容縮容、節(jié)點(diǎn)數(shù)量會(huì)動(dòng)態(tài)變化虛擬桶是一個(gè)比一致性哈希更穩(wěn)健的選擇。業(yè)界很多分布式產(chǎn)品使用了這個(gè)思路來(lái)管理數(shù)據(jù)分布說(shuō)明它經(jīng)受了大規(guī)模生產(chǎn)環(huán)境的考驗(yàn)。選虛擬桶時(shí)重點(diǎn)評(píng)估三點(diǎn)桶數(shù)量規(guī)劃的合理性、元數(shù)據(jù)變更的下發(fā)效率、數(shù)據(jù)遷移的自動(dòng)化程度。如果團(tuán)隊(duì)剛起步只有兩三個(gè)節(jié)點(diǎn)數(shù)據(jù)量也不大直接用簡(jiǎn)單的取?；蛘咭恢滦怨７炊p量。虛擬桶的元數(shù)據(jù)管理會(huì)增加一定的復(fù)雜度小規(guī)模環(huán)境下收益體現(xiàn)不出來(lái)。6. 分片鍵選擇的核心經(jīng)驗(yàn)和避坑指南算法講完了最后落到實(shí)踐層。分片算法選得再好如果分片鍵沒(méi)選對(duì)整體依舊會(huì)崩塌。這里分享一些我在幾個(gè)真實(shí)項(xiàng)目里總結(jié)出的硬經(jīng)驗(yàn)。6.1 分片鍵要滿足的三個(gè)硬條件第一高基數(shù)且分布均勻。分片鍵的候選值必須足夠多且出現(xiàn)頻率接近。用戶 ID、訂單 ID、設(shè)備 ID 都是典型的好鍵。相反性別、產(chǎn)品類型、支付方式這類低基數(shù)字段絕對(duì)不能用用了之后某些分片必然閑置。第二查詢條件必須高頻攜帶。分片鍵必須是絕大多數(shù)查詢能帶上的字段。如果業(yè)務(wù)的主要查詢是根據(jù)用戶 ID 查訂單那用戶 ID 就是最佳分片鍵如果主要查詢是根據(jù)商家 ID 查訂單但你卻用訂單 ID 分片那商家維度的查詢就要垮多個(gè)分片。業(yè)務(wù)分析要前置且要和產(chǎn)品對(duì)齊。第三不可變性。分片鍵一旦確定這條數(shù)據(jù)所在分片就被固定。如果業(yè)務(wù)中存在更新分片鍵的需求就會(huì)觸發(fā)數(shù)據(jù)跨節(jié)點(diǎn)搬遷非常昂貴。所以選鍵時(shí)一定要確認(rèn)該字段在整個(gè)數(shù)據(jù)生命周期內(nèi)不會(huì)變化。6.2 分片鍵和唯一 ID 一起設(shè)計(jì)的組合策略實(shí)際業(yè)務(wù)里經(jīng)常出現(xiàn)既要按用戶分片又要高效查訂單的矛盾。我的做法是定義復(fù)合分片鍵比如分片鍵用user_id但表的主鍵用(user_id, order_id)這樣查詢時(shí)只要帶著user_id就能定位分片再用order_id在片內(nèi)做過(guò)濾。還有另一個(gè)常見(jiàn)組合分片鍵通過(guò)哈希生成配合業(yè)務(wù)鍵做拼接。例如在生成訂單號(hào)時(shí)直接前綴拼接分片號(hào)NO_3_20250115001這樣接收到訂單號(hào)的時(shí)候直接解析出分片號(hào)就能路由連哈希都不用算。很多大廠的實(shí)際分片方案里ID 里帶分片號(hào)是一個(gè)非常常用的優(yōu)化手段。當(dāng)然缺點(diǎn)也很明顯分片號(hào)暴露后無(wú)法輕易改變節(jié)點(diǎn)映射關(guān)系擴(kuò)容時(shí)解析邏輯要配套處理。6.3 冷熱數(shù)據(jù)混合場(chǎng)景的取舍還有一個(gè)容易被忽略的點(diǎn)冷熱數(shù)據(jù)。用戶表里大部分用戶是沉默用戶只有少量活躍用戶這種情況下簡(jiǎn)單的均勻分片并不能解決熱節(jié)點(diǎn)問(wèn)題。通常的做法是主動(dòng)識(shí)別熱分片然后做數(shù)據(jù)再平衡。熱分片處理有幾種常見(jiàn)手段。一是分裂熱分片把熱點(diǎn)分片的數(shù)據(jù)按二級(jí)維度繼續(xù)拆成更細(xì)的兩塊遷移到新節(jié)點(diǎn)。二是熱點(diǎn)數(shù)據(jù)加緩存在分片層之上加分布式緩存扛住讀流量分片只處理回源和寫(xiě)流量。三是讀寫(xiě)分離熱點(diǎn)分片的主備節(jié)點(diǎn)都承擔(dān)讀流量主節(jié)點(diǎn)只承接寫(xiě)。這些都是分片算法之外的補(bǔ)充手段但熱點(diǎn)的實(shí)際問(wèn)題往往就是這樣組合解決的。6.4 擴(kuò)容遷移的現(xiàn)場(chǎng)踩坑清單擴(kuò)容遷移是所有分片方案里最容易出事故的環(huán)節(jié)。我整理一個(gè)自己常用的避坑清單直接抄走就能用。第一遷移前必須做數(shù)據(jù)快照和校驗(yàn)。先記錄遷移前每個(gè)分片的數(shù)據(jù)條數(shù)和關(guān)鍵字段的校驗(yàn)和遷移完成后對(duì)比任何不一致都要停機(jī)排查不能僥幸推進(jìn)。第二遷移過(guò)程必須限速限流。如果一口氣全速搬遷源節(jié)點(diǎn)的 IO 會(huì)被拉滿直接影響在線業(yè)務(wù)。把遷移任務(wù)按桶或子范圍切成小塊每一塊的速率獨(dú)立控制觀察源和目標(biāo)節(jié)點(diǎn)的 CPU、IO 延遲沒(méi)有惡化再繼續(xù)下一塊。第三切換路由前必須做完數(shù)據(jù)校驗(yàn)且舊節(jié)點(diǎn)保留至少一個(gè)完整周期。很多方案為了保證可用性采用雙寫(xiě)模式老路由繼續(xù)承接寫(xiě)流量新路由把全量存量數(shù)據(jù)追平后再一鍵切換切換后觀察一段時(shí)間再停掉雙寫(xiě)。這個(gè)觀察期不要省出過(guò)事后你會(huì)感謝這個(gè)決定。第四業(yè)務(wù)遷移窗口要安排在流量低谷。聽(tīng)起來(lái)是廢話但我真見(jiàn)過(guò)團(tuán)隊(duì)在下午三點(diǎn)做全量數(shù)據(jù)遷移的結(jié)果源節(jié)點(diǎn)延遲飆到秒級(jí)線上商品列表接口全部超時(shí)。寧可等到凌晨讓業(yè)務(wù)方簽字確認(rèn)也不要貪圖自己方便。6.5 分片算法的選型速查表把前面幾種算法做一個(gè)橫向?qū)Ρ确奖阒苯訉?duì)照選型維度哈希取模范圍分片一致性哈希虛擬桶實(shí)現(xiàn)復(fù)雜度極低低中中高數(shù)據(jù)均勻性好易傾斜依賴虛擬節(jié)點(diǎn)數(shù)好范圍查詢不支持友好不支持不支持?jǐn)U容遷移量高約 80%中按區(qū)間低約 20%低按桶遷移熱點(diǎn)處理難難較難容易元數(shù)據(jù)管理無(wú)需要區(qū)間表需要環(huán)映射需要桶映射表適合場(chǎng)景小規(guī)模固定節(jié)點(diǎn)時(shí)間序列、區(qū)間查詢節(jié)點(diǎn)頻繁彈性伸縮大規(guī)模動(dòng)態(tài)集群用這個(gè)表對(duì)照自己的業(yè)務(wù)場(chǎng)景通常很快就能鎖定候選方案。選型之后我還會(huì)建議做一輪壓測(cè)用線上真實(shí)數(shù)據(jù)脫敏后的樣本分別跑均勻性測(cè)試和模擬擴(kuò)容遷移測(cè)試。均勻性測(cè)試看每個(gè)分片的數(shù)據(jù)量和 QPS 是否在合理區(qū)間遷移測(cè)試看數(shù)據(jù)搬遷耗時(shí)和業(yè)務(wù)影響。這兩個(gè)指標(biāo)出來(lái)之后選型結(jié)論基本就穩(wěn)了。7. 實(shí)操過(guò)程回顧與一個(gè)完整的分片實(shí)施示例紙上談兵結(jié)束分享一個(gè)我去年做的完整分片實(shí)施過(guò)程。系統(tǒng)是一個(gè)面向商家側(cè)的交易流水系統(tǒng)每天寫(xiě)入量約 3000 萬(wàn)條流水高峰期寫(xiě)入 QPS 接近 8000單機(jī) MySQL 明顯扛不住。業(yè)務(wù)查詢的特點(diǎn)是大多數(shù)查詢都帶著商家 IDmerchant_id少部分查詢按流水號(hào)精確查詢。7.1 分片方案的確定過(guò)程第一步是選分片鍵。兩個(gè)候選merchant_id 和流水號(hào) trade_no。如果按 merchant_id 分片主查詢能直接路由但流水號(hào)精確查詢會(huì)變成跨片查詢。如果按 trade_no 分片主查詢必須全片掃。權(quán)衡之后選擇了 merchant_id 做分片鍵同時(shí)在應(yīng)用層對(duì) trade_no 冗余一份映射表單獨(dú)建了一層映射把 trade_no 到 merchant_id 的對(duì)應(yīng)關(guān)系存起來(lái)用于流水號(hào)查詢的二次路由。第二步是選算法?？紤]到未來(lái)半年內(nèi)商家數(shù)量增長(zhǎng)可能達(dá)到 3 倍節(jié)點(diǎn)大概率要擴(kuò)直接放棄裸取模。備選就一致哈希和虛擬桶。因?yàn)楣?jié)點(diǎn)數(shù)規(guī)劃是明確的 8 臺(tái)起步容錯(cuò)考慮允許最多擴(kuò)到 32 臺(tái)且遷移需要精細(xì)化控制最終選了虛擬桶方案桶數(shù)設(shè)為 1024每個(gè)物理節(jié)點(diǎn)初始持有 128 個(gè)桶。第三步是定路由層?？蛻舳诵枰酚蓵r(shí)先看本地緩存的桶映射表取MERCHANT_ID的 CRC32 哈希值對(duì) 1024 取模得到桶號(hào)再查桶到節(jié)點(diǎn)的映射得到目標(biāo)節(jié)點(diǎn)。這個(gè)映射表放在配置中心變更時(shí)通過(guò)發(fā)布訂閱推送到客戶端。7.2 幾個(gè)關(guān)鍵參數(shù)的計(jì)算過(guò)程桶數(shù) 1024 是怎么定下來(lái)的基于兩個(gè)約束8 臺(tái)物理節(jié)點(diǎn)要求每臺(tái)持有 128 個(gè)桶1024 是 8 的 128 倍能保證桶按整數(shù)分配。而如果未來(lái)擴(kuò)到 16 臺(tái)每臺(tái)持有 64 個(gè)桶依然均勻。分片鍵的哈希函數(shù)選 CRC32 而不是 MD5原因是流水系統(tǒng)要求低延遲CRC32 的運(yùn)算速度快且分布對(duì)于 merchant_id 這種不均勻字符串依然表現(xiàn)良好。實(shí)測(cè)數(shù)據(jù)約 5 萬(wàn)個(gè)商家 ID映射到 1024 個(gè)桶里桶之間數(shù)據(jù)量標(biāo)準(zhǔn)差控制在平均值的 6% 以內(nèi)完全可接受?？缙樵兊奶幚硪仓v一下。因?yàn)闃I(yè)務(wù)中統(tǒng)計(jì)類報(bào)表經(jīng)常要查某一天的全局流水這種查詢無(wú)法帶分片鍵。我的解決辦法是把當(dāng)天的流水按小時(shí)做離線預(yù)聚合寫(xiě)入一張獨(dú)立的統(tǒng)計(jì)表報(bào)表查詢走統(tǒng)計(jì)表而不是直接跨片掃。這樣把高頻的跨片查詢問(wèn)題轉(zhuǎn)換成了離線計(jì)算問(wèn)題效果立竿見(jiàn)影。如果你也遇到類似問(wèn)題可以考慮在分片之上建一層預(yù)聚合層不要硬扛跨片查詢。7.3 遷移過(guò)程踩過(guò)的具體坑初次數(shù)據(jù)遷移讓我印象最深。方案是舊庫(kù)里按 merchant_id 的哈希桶范圍分批導(dǎo)出導(dǎo)入到新分片并在導(dǎo)入時(shí)記錄每個(gè)桶的遷移水位。跑到一半發(fā)現(xiàn)一個(gè)問(wèn)題因?yàn)榫€上還在持續(xù)寫(xiě)入舊庫(kù)中已經(jīng)導(dǎo)出的桶又有新數(shù)據(jù)進(jìn)來(lái)導(dǎo)致導(dǎo)入完成后數(shù)據(jù)是追平的假象。后來(lái)我調(diào)整了策略遷移期間對(duì)未完成遷移的桶寫(xiě)入路徑先切到新庫(kù)同時(shí)開(kāi)一個(gè)雙寫(xiě)管道把新舊庫(kù)之間的增量通過(guò)消息隊(duì)列補(bǔ)過(guò)去。也就是說(shuō)一個(gè)桶只有當(dāng)存量數(shù)據(jù)遷移完成、且后續(xù)寫(xiě)入都走新庫(kù)時(shí)才算是遷移完成。這個(gè)雙寫(xiě)策略讓最終切換時(shí)幾乎不需要停機(jī)業(yè)務(wù)方反饋只有一個(gè) 5 秒的閃斷。還有一個(gè)細(xì)節(jié)遷移之后要緊盯一段時(shí)間的數(shù)據(jù)核對(duì)。我每天跑一個(gè)比對(duì)任務(wù)統(tǒng)計(jì)舊庫(kù)、新庫(kù)各桶的數(shù)據(jù)條數(shù)和關(guān)鍵字段校驗(yàn)和連續(xù)跑了一周確認(rèn)無(wú)差異后才徹底下線舊庫(kù)資源。這套方案上線后高峰期寫(xiě)入 QPS 穩(wěn)定在 8000 以上單分片 CPU 平均利用率約 55%沒(méi)有出現(xiàn)明顯熱點(diǎn)。擴(kuò)容時(shí)批量遷移 128 個(gè)桶到新節(jié)點(diǎn)配合限流控制在 3000 QPS 以內(nèi)一次擴(kuò)容約需 40 分鐘線上無(wú)感知。最后分享一個(gè)心得體會(huì)分片系統(tǒng)的設(shè)計(jì)里算法永遠(yuǎn)只占 30%剩下 70% 在于元數(shù)據(jù)管理、數(shù)據(jù)遷移工具鏈、監(jiān)控告警和業(yè)務(wù)路由適配。拿算法說(shuō)事的文章太多但真正讓分片系統(tǒng)穩(wěn)定跑在生產(chǎn)環(huán)境的是那些看不見(jiàn)的工程細(xì)節(jié)——版本號(hào)管理、雙寫(xiě)一致性、限流遷移、校驗(yàn)核對(duì)。你動(dòng)手做一個(gè)分片方案時(shí)把這幾個(gè)環(huán)節(jié)做扎實(shí)就已經(jīng)跑贏大多數(shù)團(tuán)隊(duì)了。