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