隨著我們業(yè)務(wù)的發(fā)展，每日的訂單量接近 100 萬。這個(gè)時(shí)候，訂單庫(kù)已有上億條記錄，訂單表有上百個(gè)字段，這些數(shù)據(jù)存儲(chǔ)在一個(gè) Oracle 數(shù)據(jù)庫(kù)里。當(dāng)時(shí)，我們已經(jīng)實(shí)現(xiàn)了訂單的服務(wù)化改造，只有訂單服務(wù)才能訪問這個(gè)訂單數(shù)據(jù)庫(kù)，但隨著單量的增長(zhǎng)以及在線促銷的常態(tài)化，單一數(shù)據(jù)庫(kù)的存儲(chǔ)容量和訪問性能都已經(jīng)不能滿足業(yè)務(wù)需求了，訂單數(shù)據(jù)庫(kù)已成為系統(tǒng)的瓶頸。所以，對(duì)這個(gè)數(shù)據(jù)庫(kù)的拆分勢(shì)在必行。

數(shù)據(jù)庫(kù)拆分一般有兩種做法，一個(gè)是垂直分庫(kù)，還有一個(gè)是水平分庫(kù)。

垂直分庫(kù)簡(jiǎn)單來說，垂直分庫(kù)就是數(shù)據(jù)庫(kù)里的表太多，我們把它們分散到多個(gè)數(shù)據(jù)庫(kù)，一般是根據(jù)業(yè)務(wù)進(jìn)行劃分，把關(guān)系密切的表放在同一個(gè)數(shù)據(jù)庫(kù)里，這個(gè)改造相對(duì)比較簡(jiǎn)單。

水平分庫(kù)某些表太大，單個(gè)數(shù)據(jù)庫(kù)存儲(chǔ)不下，或者數(shù)據(jù)庫(kù)的讀寫性能有壓力。通過水平分庫(kù)，我們把一張表拆成多張表，每張表存放部分記錄，分別保存在不同的數(shù)據(jù)庫(kù)里，水平分庫(kù)需要對(duì)應(yīng)用做比較大的改造。

圖片

通過水平分庫(kù)，你們將訂單的基本信息、商品明細(xì)和擴(kuò)展信息分散到多個(gè)數(shù)據(jù)庫(kù)中，這樣做主要是為了解決兩個(gè)問題：一是減少了單個(gè)數(shù)據(jù)庫(kù)的數(shù)據(jù)量，從而提高了讀寫效率；二是分散了數(shù)據(jù)庫(kù)的負(fù)載，使系統(tǒng)能夠更好地?cái)U(kuò)展和維護(hù)。簡(jiǎn)而言之，就是讓數(shù)據(jù)庫(kù)更快、系統(tǒng)運(yùn)行更穩(wěn)定。

水平分庫(kù)后，應(yīng)用通過訂單服務(wù)來訪問多個(gè)訂單數(shù)據(jù)庫(kù)，具體的方式如下圖所示：

圖片

原來的一個(gè) Oracle 庫(kù)被現(xiàn)在的多個(gè) MySQL 庫(kù)給取代了，每個(gè) MySQL 數(shù)據(jù)庫(kù)包括了 1 主 1 備 2 從，都支持讀寫分離，主備之間通過自帶的同步機(jī)制來實(shí)現(xiàn)數(shù)據(jù)同步。所以，你可以發(fā)現(xiàn)，這個(gè)項(xiàng)目實(shí)際包含了水平分庫(kù)和去 Oracle 兩大改造目標(biāo)。

分庫(kù)維度怎么定？

首先，我們需要考慮根據(jù)哪個(gè)字段來作為分庫(kù)的維度。這個(gè)字段選擇的標(biāo)準(zhǔn)是，盡量避免應(yīng)用代碼和 SQL 性能受到影響。

具體地說，就是現(xiàn)有的 SQL 在分庫(kù)后，它的訪問盡量落在單個(gè)數(shù)據(jù)庫(kù)里，否則原來的單庫(kù)訪問就變成了多庫(kù)掃描，不但 SQL 的性能會(huì)受到影響，而且相應(yīng)的代碼也需要進(jìn)行改造。

具體到訂單數(shù)據(jù)庫(kù)的拆分，你可能首先會(huì)想到按照用戶 ID 來進(jìn)行拆分。這個(gè)結(jié)論是沒錯(cuò)，但我們最好還是要有量化的數(shù)據(jù)支持，不能拍腦袋。這里，最好的做法是，先收集所有 SQL，挑選出 WHERE 語(yǔ)句中最常出現(xiàn)的過濾字段，比如說這里有三個(gè)候選對(duì)象，分別是用戶 ID、訂單 ID 和商家 ID，每個(gè)字段在 SQL 中都會(huì)出現(xiàn)三種情況：

單 ID 過濾，比如說“用戶 ID=？”；

多 ID 過濾，比如“用戶 ID IN(?,?,?)”；

該 ID 不出現(xiàn)。

最后，我們分別統(tǒng)計(jì)這三個(gè)字段的使用情況，假設(shè)共有 500 個(gè) SQL 訪問訂單庫(kù)，3 個(gè)候選字段出現(xiàn)的情況如下：

圖片

從這張表格的分析來看，選擇按用戶 ID 進(jìn)行分庫(kù)是顯而易見的最佳選擇。但這只是基于靜態(tài)數(shù)據(jù)的判斷。實(shí)際上，不同 SQL 的訪問頻次各不相同，因此，進(jìn)一步分析每條 SQL 的實(shí)際訪問量變得至關(guān)重要。在我們的項(xiàng)目中，我們聚焦于執(zhí)行頻率最高的前15條 SQL，它們占據(jù)了總執(zhí)行次數(shù)的85%，具有很高的代表性。通過分析，如果采用用戶 ID 作為分庫(kù)的依據(jù)，發(fā)現(xiàn)這些 SQL 中有85% 的訪問會(huì)集中在某個(gè)特定的數(shù)據(jù)庫(kù)上，13% 的訪問分布在幾個(gè)數(shù)據(jù)庫(kù)中，僅有2% 的訪問需要查詢所有數(shù)據(jù)庫(kù)。因此，從動(dòng)態(tài)的 SQL 執(zhí)行頻次來看，使用用戶 ID 進(jìn)行分庫(kù)顯然優(yōu)于采用其他標(biāo)識(shí)符。這樣的量化分析不僅證實(shí)了按用戶 ID 分庫(kù)是最優(yōu)策略，而且還明確了分庫(kù)對(duì)現(xiàn)有系統(tǒng)的具體影響。例如，在本案例中，85% 的 SQL 都會(huì)被定向到同一個(gè)數(shù)據(jù)庫(kù)，這意味著相對(duì)于未分庫(kù)的狀態(tài)，這部分?jǐn)?shù)據(jù)的訪問性能將得到提升，同時(shí)也消除了我們對(duì)分庫(kù)有效性的疑慮，增強(qiáng)了我們進(jìn)行分庫(kù)的決心。

數(shù)據(jù)怎么分？

一般有兩種數(shù)據(jù)分法：根據(jù) ID 范圍進(jìn)行分庫(kù)，比如把用戶 ID 為 1 ~ 999 的記錄分到第一個(gè)庫(kù)，1000 ~ 1999 的分到第二個(gè)庫(kù)，以此類推。

根據(jù) ID 取模進(jìn)行分庫(kù)，比如把用戶 ID mod 10，余數(shù)為 0 的記錄放到第一個(gè)庫(kù)，余數(shù)為 1 的放到第二個(gè)庫(kù)，以此類推。

這兩種分法，各自存在優(yōu)缺點(diǎn)，如下表所示：

圖片

在實(shí)踐中，為了運(yùn)維方便，選擇 ID 取模進(jìn)行分庫(kù)的做法比較多。同時(shí)為了數(shù)據(jù)遷移方便，一般分庫(kù)的數(shù)量是按照倍數(shù)增加的，比如說，一開始是 4 個(gè)庫(kù)，二次分裂為 8 個(gè)，再分成 16 個(gè)。這樣對(duì)于某個(gè)庫(kù)的數(shù)據(jù)，在分裂的時(shí)候，一半數(shù)據(jù)會(huì)移到新庫(kù)，剩余的可以不用動(dòng)。與此相反，如果我們每次只增加一個(gè)庫(kù)，所有記錄都要按照新的模數(shù)做調(diào)整。

分幾個(gè)庫(kù)？

確定了數(shù)據(jù)分片的方案后，接下來要解決的問題是分成多少個(gè)數(shù)據(jù)庫(kù)。數(shù)據(jù)庫(kù)能夠處理的記錄數(shù)量上限是決定因素之一。

通常情況下，當(dāng)MySQL數(shù)據(jù)庫(kù)的記錄數(shù)超過5000萬，或Oracle數(shù)據(jù)庫(kù)的記錄數(shù)超過1億時(shí)，數(shù)據(jù)庫(kù)的負(fù)載會(huì)變得很高，這也取決于字段的數(shù)量、大小以及查詢的復(fù)雜性。

在保證不超過單個(gè)數(shù)據(jù)庫(kù)記錄處理上限的情況下，如果分庫(kù)太少，我們無法實(shí)現(xiàn)分散存儲(chǔ)的目的，也不能有效減輕數(shù)據(jù)庫(kù)的性能壓力；而分得太多雖然能提高單個(gè)數(shù)據(jù)庫(kù)的訪問性能，但對(duì)于需要跨多個(gè)數(shù)據(jù)庫(kù)進(jìn)行的訪問操作，應(yīng)用程序必須同時(shí)連接多個(gè)數(shù)據(jù)庫(kù)。并行訪問會(huì)消耗更多的線程資源，而串行訪問則會(huì)大幅增加處理時(shí)間。

此外，數(shù)據(jù)庫(kù)數(shù)量的增加也意味著更多的硬件成本。因此，確定分庫(kù)數(shù)量需要進(jìn)行全面評(píng)估。通常建議初次進(jìn)行數(shù)據(jù)庫(kù)分片時(shí)，可以選擇創(chuàng)建4到8個(gè)數(shù)據(jù)庫(kù)。例如，在我們的項(xiàng)目中，我們選擇創(chuàng)建了6個(gè)數(shù)據(jù)庫(kù)，這一數(shù)量能夠滿足訂單業(yè)務(wù)在未來一段時(shí)間內(nèi)的需求。

分庫(kù)路由

在實(shí)施數(shù)據(jù)庫(kù)分庫(kù)時(shí)，雖然這一變化不涉及業(yè)務(wù)邏輯，但它必定會(huì)對(duì)應(yīng)用程序產(chǎn)生影響。為最小化這種影響，關(guān)鍵在于確保分庫(kù)邏輯盡可能只在數(shù)據(jù)訪問層（DAL）處理，而對(duì)上層的訂單服務(wù)保持透明，這樣，服務(wù)層代碼就無需進(jìn)行大幅修改。實(shí)現(xiàn)這一目標(biāo)確實(shí)具有一定挑戰(zhàn)性。以下是一些建議，用以明確DAL和訂單服務(wù)各自的職責(zé)范圍：

當(dāng)涉及到單一數(shù)據(jù)庫(kù)的訪問時(shí)，例如查詢操作明確指定了用戶ID，則此類SQL查詢應(yīng)直接路由至特定的數(shù)據(jù)庫(kù)。這種情況下，DAL應(yīng)負(fù)責(zé)自動(dòng)完成路由，且當(dāng)數(shù)據(jù)庫(kù)分裂時(shí)，僅需調(diào)整路由邏輯中的模數(shù)即可，而無需修改應(yīng)用層代碼。

對(duì)于簡(jiǎn)單的跨庫(kù)查詢，DAL應(yīng)負(fù)責(zé)匯集來自各個(gè)分庫(kù)的結(jié)果，并對(duì)上層應(yīng)用保持透明。

針對(duì)需要進(jìn)行聚合操作的復(fù)雜查詢（如涉及groupby、orderby、min、max、avg等操作），建議讓DAL層先行匯總各分庫(kù)的查詢結(jié)果，隨后由訂單服務(wù)層完成進(jìn)一步處理。這樣的安排既考慮到了DAL層實(shí)現(xiàn)所有聚合操作邏輯復(fù)雜度較高的問題，也顧及到根據(jù)實(shí)際經(jīng)驗(yàn)，這類需求在應(yīng)用層處理會(huì)更加靈活和高效。

數(shù)據(jù)訪問層還可以細(xì)分為底層的JDBC驅(qū)動(dòng)層和更上層的數(shù)據(jù)訪問層。若在JDBC層面實(shí)現(xiàn)分庫(kù)邏輯，會(huì)使系統(tǒng)開發(fā)復(fù)雜度增加，靈活性降低，且目前缺乏成功案例。在實(shí)踐中，更常見的做法是在持久層框架的基礎(chǔ)上進(jìn)一步封裝，形成一個(gè)分布式數(shù)據(jù)訪問層（DDAL），以便實(shí)現(xiàn)分庫(kù)路由。

分頁(yè)處理

在實(shí)施水平分庫(kù)之后，確實(shí)，分頁(yè)查詢變得更加復(fù)雜，特別是當(dāng)查詢需要遍歷所有分庫(kù)時(shí)。例如，假設(shè)要按時(shí)間順序展示某商家的所有訂單，每頁(yè)顯示100條記錄。因?yàn)槭前瓷碳也樵?，需遍歷全部數(shù)據(jù)庫(kù)。若數(shù)據(jù)庫(kù)共有8個(gè)，分頁(yè)邏輯會(huì)相應(yīng)變復(fù)雜：

對(duì)于第1頁(yè)數(shù)據(jù)，需從每個(gè)數(shù)據(jù)庫(kù)獲取前100條記錄，匯總后共得到800條記錄。接著，在應(yīng)用層進(jìn)行二次排序，最終僅保留前100條。

若獲取第10頁(yè)數(shù)據(jù)，每個(gè)庫(kù)需要提供前1000條記錄（100*10），合計(jì)8000條記錄。然后，再次在應(yīng)用層進(jìn)行排序，并選取第900到1000條記錄作為結(jié)果。

這一機(jī)制說明，分頁(yè)查詢?cè)诜謳?kù)環(huán)境下需要從每個(gè)數(shù)據(jù)庫(kù)中獲取更多數(shù)據(jù)，并且在應(yīng)用層執(zhí)行二次排序，導(dǎo)致內(nèi)存和處理時(shí)間需求隨著分頁(yè)深度的增加而顯著增長(zhǎng)。與此相對(duì)，單庫(kù)環(huán)境下的分頁(yè)查詢則簡(jiǎn)單得多，直接從數(shù)據(jù)庫(kù)獲取所需頁(yè)的記錄，無需應(yīng)用層排序。

解決分庫(kù)環(huán)境下分頁(yè)問題的策略包括：

前端應(yīng)用分頁(yè)：可以限制用戶只能訪問前n頁(yè)數(shù)據(jù)。這種做法業(yè)務(wù)上通常是可接受的，因?yàn)橛脩艉苌傩枰榭春罄m(xù)頁(yè)面。若用戶確實(shí)需要訪問更深的頁(yè)面，可以引導(dǎo)他們縮小查詢范圍再次進(jìn)行查詢。

在采用用戶 ID 作為分庫(kù)依據(jù)的系統(tǒng)中，確實(shí)存在一個(gè)挑戰(zhàn)，即如何高效地處理基于非分庫(kù)字段（例如訂單 ID）的查詢。直接查詢所有分庫(kù)會(huì)導(dǎo)致大量不必要的資源消耗。為了解決這一問題，創(chuàng)建一個(gè)訂單 ID 與用戶 ID 之間的映射關(guān)系（Lookup 表）是一個(gè)有效的策略。這樣，每次基于訂單 ID 的查詢首先訪問 Lookup 表來確定對(duì)應(yīng)的用戶 ID，進(jìn)而實(shí)現(xiàn)對(duì)特定分庫(kù)的直接定位。

Lookup 表的設(shè)計(jì)是這樣的：

字段限定：該表僅包含兩個(gè)字段——訂單 ID 和用戶 ID，這使得它在存儲(chǔ)和查詢性能上都非常高效。

獨(dú)立存儲(chǔ)：Lookup 表存放在一個(gè)獨(dú)立的數(shù)據(jù)庫(kù)中，這樣做不僅避免了與業(yè)務(wù)數(shù)據(jù)的混淆，還能提高查詢效率。

緩存優(yōu)化：為進(jìn)一步提高查詢性能，可以利用分布式緩存來存儲(chǔ)這些映射關(guān)系。這樣，常見的查詢可以直接從緩存中獲取結(jié)果，大大減少數(shù)據(jù)庫(kù)訪問次數(shù)。

數(shù)據(jù)一致性：在新增訂單時(shí)，除了在訂單數(shù)據(jù)庫(kù)中添加記錄外，還需同步更新 Lookup 表。這確保了訂單 ID 到用戶 ID 的映射關(guān)系始終保持最新。

理任務(wù)：對(duì)于需要批量獲取數(shù)據(jù)的場(chǎng)景，可以增加每批次的數(shù)據(jù)量，例如，每次處理5000條記錄。這樣做可以有效減少分頁(yè)訪問次數(shù)，減輕數(shù)據(jù)庫(kù)壓力。

利用大數(shù)據(jù)平臺(tái)：在分庫(kù)設(shè)計(jì)中，通常會(huì)配備大數(shù)據(jù)平臺(tái)來匯總所有分庫(kù)的數(shù)據(jù)。對(duì)于某些分頁(yè)查詢，可以考慮通過大數(shù)據(jù)平臺(tái)來實(shí)現(xiàn)，特別是當(dāng)需要全庫(kù)數(shù)據(jù)概覽時(shí)。

整體架構(gòu)

在這種架構(gòu)下，上層應(yīng)用（如訂單服務(wù)）與數(shù)據(jù)庫(kù)之間的交云通過一系列中間層來實(shí)現(xiàn)分庫(kù)的邏輯，同時(shí)保持對(duì)上層服務(wù)的透明性。這種設(shè)計(jì)不僅優(yōu)化了數(shù)據(jù)存取效率，還大大簡(jiǎn)化了應(yīng)用層的開發(fā)和維護(hù)。下面是這個(gè)系統(tǒng)架構(gòu)的關(guān)鍵組成部分及其功能：

分庫(kù)代理：這是分庫(kù)邏輯的核心，它負(fù)責(zé)實(shí)現(xiàn)包括聚合運(yùn)算和訂單 ID 到用戶 ID 的映射在內(nèi)的所有分庫(kù)相關(guān)功能。通過分庫(kù)代理，訂單服務(wù)無需關(guān)心背后的分庫(kù)邏輯，可以像訪問單一數(shù)據(jù)庫(kù)一樣進(jìn)行數(shù)據(jù)操作。

Lookup 表：專門用于存儲(chǔ)訂單 ID 和用戶 ID 之間的映射關(guān)系，這樣即使是基于非分庫(kù)字段（訂單 ID）的查詢也能快速定位到對(duì)應(yīng)的數(shù)據(jù)庫(kù)。Lookup 表的存在是優(yōu)化查詢性能的關(guān)鍵，尤其是在基于訂單 ID 查詢時(shí)，能夠直接指向單個(gè)庫(kù)，避免全庫(kù)掃描。

緩存（Cache）：為了進(jìn)一步提升查詢效率，Lookup 表的數(shù)據(jù)會(huì)被緩存在分布式緩存中。這種機(jī)制可以減少對(duì)數(shù)據(jù)庫(kù)的直接訪問，快速響應(yīng)查詢請(qǐng)求，特別是對(duì)于高頻訪問的數(shù)據(jù)。

分布式數(shù)據(jù)訪問層（DDAL）：提供數(shù)據(jù)庫(kù)路由功能，能夠根據(jù)用戶 ID 準(zhǔn)確地定位到特定的分庫(kù)。對(duì)于需要跨多個(gè)數(shù)據(jù)庫(kù)進(jìn)行的操作，DDAL 還支持多線程并發(fā)訪問模式以及簡(jiǎn)單的結(jié)果匯總，優(yōu)化了數(shù)據(jù)訪問的效率和響應(yīng)時(shí)間。

數(shù)據(jù)初始化與同步：Lookup 表的初始數(shù)據(jù)來源于現(xiàn)有的分庫(kù)數(shù)據(jù)，確保了從一開始就能正確映射訂單 ID 和用戶 ID。當(dāng)有新的訂單記錄產(chǎn)生時(shí)，分庫(kù)代理會(huì)負(fù)責(zé)異步將這些新記錄寫入Lookup 表，保持?jǐn)?shù)據(jù)的一致性和最新性。

如何安全落地？

為了確保訂單水平分庫(kù)的平穩(wěn)過渡，整個(gè)遷移和上線過程采用了分階段實(shí)施的策略。這種方法不僅能夠降低風(fēng)險(xiǎn)，還能確保在轉(zhuǎn)換期間系統(tǒng)的穩(wěn)定性和數(shù)據(jù)的一致性。下面是實(shí)施過程的詳細(xì)步驟：

階段一：技術(shù)驗(yàn)證和部分功能遷移

并行運(yùn)行Oracle和MySQL數(shù)據(jù)庫(kù)：在初始階段，所有的數(shù)據(jù)讀寫操作仍然指向原有的Oracle數(shù)據(jù)庫(kù)。同時(shí)，通過數(shù)據(jù)同步程序，定期（例如，每3分鐘）將Oracle數(shù)據(jù)庫(kù)中的數(shù)據(jù)增量同步到多個(gè)MySQL庫(kù)中。這樣做的目的是確保MySQL數(shù)據(jù)庫(kù)能夠及時(shí)反映最新數(shù)據(jù)狀態(tài)，同時(shí)驗(yàn)證數(shù)據(jù)同步的準(zhǔn)確性和效率。

選擇非實(shí)時(shí)場(chǎng)景進(jìn)行驗(yàn)證：挑選一些對(duì)數(shù)據(jù)實(shí)時(shí)性要求不高的業(yè)務(wù)場(chǎng)景（如查詢歷史訂單）作為先行者，將這部分業(yè)務(wù)的數(shù)據(jù)訪問切換到MySQL數(shù)據(jù)庫(kù)。這一步驟旨在驗(yàn)證整個(gè)方案的可行性，包括分庫(kù)代理、DDAL、Lookup表等基礎(chǔ)設(shè)施的功能和性能。

階段二：全面業(yè)務(wù)遷移

全面接入MySQL：在第一階段驗(yàn)證無大的技術(shù)問題后，接下來將所有實(shí)時(shí)讀寫操作切換到MySQL數(shù)據(jù)庫(kù)。這一步驟要求徹底廢棄Oracle數(shù)據(jù)庫(kù)，意味著MySQL將成為系統(tǒng)的主要數(shù)據(jù)存儲(chǔ)方案。

業(yè)務(wù)功能驗(yàn)證：在這一階段，重點(diǎn)是驗(yàn)證遷移后的業(yè)務(wù)功能是否正常。所有依賴訂單服務(wù)的應(yīng)用都需要接入新的MySQL數(shù)據(jù)庫(kù)。通過大量的測(cè)試來確保性能和功能符合預(yù)期。

實(shí)施這個(gè)分庫(kù)方案時(shí)，分兩個(gè)階段一次性成功地完成了上線，特別是在第二階段，超過100個(gè)依賴訂單服務(wù)的應(yīng)用僅通過簡(jiǎn)單重啟就順利完成了系統(tǒng)升級(jí)，期間未遇到較大的問題。這個(gè)案例充分證明了分階段實(shí)施策略的有效性，同時(shí)也展示了良好的前期準(zhǔn)備和詳盡測(cè)試的重要性。通過這種方式，可以在最大程度上減少遷移帶來的風(fēng)險(xiǎn)，確保系統(tǒng)遷移的平穩(wěn)執(zhí)行。