Java互聯網架構-Mysql分庫分表訂單生成系統實戰分析

概述

分庫分表的必要性

首先咱們來了解一下爲何要作分庫分表。在咱們的業務（web應用）中，關係型數據庫自己比較容易成爲系統性能瓶頸，單機存儲容量、鏈接數、處理能力等都頗有限，數據庫自己的「有狀態性」致使了它並不像Web和應用服務器那麼容易擴展。那麼在咱們的業務中，是否真的有必要進行分庫分表，就能夠從上面幾個條件來考慮。

· 單機儲存容量。您的數據量是否在單機儲存中碰到瓶頸。好比餓了麼一天產生的用戶行爲數據就有24T，那麼在傳統的單機儲存中確定是不夠的。

· 鏈接數、處理能力。在咱們的用戶量達到必定程度時，特定時間的併發量又成了一個大問題，在一個高併發的網站中秒級數十萬的併發量都是很正常的。在普通的單機數據庫中秒級千次的操做問題都很大。

因此在咱們進行分庫分表以前咱們最好考慮一下，咱們的數據量是否是夠大，併發量是否是夠大。若是您的回答是確定的，那咱們就開始作吧。

分庫分表的幾種方法

在分庫分表中，咱們有幾種不一樣的劃分方式：垂直分表、垂直分庫、水平分表、水平分庫分表。分的方式大同小異，主要思想都是化大爲小，且能夠融合使用。

垂直分表

垂直分表在平常的開發和設計中比較常見，簡單來說就是「大表拆小表」，拆分是基於關係型數據庫中的列進行的。咱們在基礎數據庫課程中老師就教導咱們，一個表的字段不要太多，就算數據量沒有那麼大，爲了表的合理性咱們也會作。好比，某個表中的字段比較多，能夠新創建一張「擴展表」，將不常用或者長度較大的字段拆分出去放到「擴展表」中。

好比在一張產品表中（id, name, price, company, ），咱們將經常使用的（id, name, price, company）字段放在一個表中，而不經常使用的（）字段放在拓展表中，那咱們查詢時優先查詢經常使用字段，在有必要時才查詢拓展字段。能夠有效的提升效率，同時減小字段後咱們在一個表中能夠容納的數據數量也提升了。

垂直分表還有一個好處，能使得咱們的微服務的關注點更加明確。

Note：分表的操做最好在數據庫設計階段就作完，若是在後續開發過程當中再拆分，則可能須要大量的更改SQL語句。

垂直分庫

垂直分庫的基本思路即是咱們按照不一樣的業務模塊來劃分出不一樣的數據庫。垂直分庫在「微服務」盛行的今天已經很是普及了。就像咱們上面所說的，這能使得咱們的微服務的關注點更加明確。也就是業務邏輯更加清晰。

好比在咱們的業務中，User, Product, Company等都屬於不一樣業務模塊，即可將其放在不一樣的數據庫。

水平分表

水平分表的思想很簡單，就至關於一摞烙餅一百個，而後我每十個放一個籃子。在數據庫中的表現就是，我一個User表有100萬條數據，那麼我0-10w放在一個表中，10-20w放一個表中，類推（固然這只是其中一種分佈規律）。這樣能夠下降單表的數據量，優化查詢性能。

水平分表可以下降單表的數據量，在必定程度上可以緩解查詢性能的瓶頸。但其本質上仍是在一個數據庫中，因此當查詢上升到數據庫級，其IO瓶頸並無獲得好的解決。因此並不推薦單純的水平分表作法。

水平分庫分表

水平分庫分表與水平分表的思想相同，即將同一表中的大量數據分層次的儲存，不一樣的在於將分出來的表放在不一樣的數據庫中。在高併發和海量數據的場景下，分庫分表可以有效緩解單機和單庫的性能瓶頸和壓力，突破IO、鏈接數、硬件資源的瓶頸。固然，投入的硬件成本也會更高。同時，這也會帶來一些複雜的技術問題和挑戰（例如：跨分片的複雜查詢，跨分片事務等）。

本人結合項目實踐，對水平分庫作一個系統地剖析，但願爲你們水平分庫（包括去IOE）改造提供整體思路。

主要內容包括：

水平分庫說明

分庫維度-- 根據哪一個字段分庫

分庫策略-- 記錄如何分配到不一樣庫

分庫數量-- 初始庫數量及庫數量如何增加

路由透明-- 如何實現庫路由，支持應用透明

分頁處理-- 跨多個庫的分頁case如何處理

Lookup映射—非分庫字段映射到分庫字段，實現單庫訪問

總體架構-- 分庫的總體技術架構

上線步驟-- 分庫改造實施上線

項目總結

水平分庫說明

數據庫拆分有兩種：

1) 垂直分庫

數據庫裏的表太多，拿出部分到新的庫裏，通常是根據業務劃分表，關係密切的表放同一數據庫，應用修改數據庫鏈接便可，比較簡單。

2) 水平分庫

某張表太大，單個數據庫存儲不下或訪問性能有壓力，把一張表拆成多張，每張表存放部分記錄，保存在不一樣的數據庫裏，水平分庫須要對系統作大的改造。

訂單表存儲在Oracle數據庫，記錄有上億條，字段有上百個，訪問的模式也是複雜多樣，隨着業務快速增加，不管存儲空間或訪問性能都面臨巨大挑戰，特別在大促時，訂單庫已成爲系統瓶頸。

一般有兩種解決辦法：

Scale up，升級Oracle數據庫所在的物理機，提高內存/存儲/IO性能，但這種升級費用昂貴，而且只能知足短時間須要。

Scale out，把訂單庫拆分爲多個庫，分散到多臺機器進行存儲和訪問，這種作法支持水平擴展，能夠知足長遠須要。

採起後一種作法，它的訂單庫主要包括訂單主表/訂單明細表（記錄商品明細）/訂單擴展表，水平分庫即把這3張表的記錄分到多個數據庫中，訂單水平分庫效果以下圖所示：

原來一個Oracle庫被多個MySQL庫取代，支持1主多備和讀寫分離，主備之間經過MySQL自帶的數據同步機制（SLA<1秒），全部應用經過訂單服務訪問訂單數據。

分庫維度

水平分庫首先要考慮根據哪一個字段做爲分庫維度，選擇標準是儘可能避免應用代碼和SQL性能受影響，這就要求當前SQL在分庫後，訪問儘可能落在單個庫裏，不然單庫訪問變成多庫掃描，讀寫性能和應用邏輯都會受較大影響。

對於訂單拆分，你們首先想到的是按照用戶Id拆分，結論沒錯，但最好仍是數聽說話，不能拍腦殼。好的作法是首先收集全部SQL，挑選where語句最常出現的過濾字段，好比用戶Id/訂單Id/商家Id，每一個字段在SQL中有三種狀況：

單Id過濾，如用戶Id=？

多Id過濾，如用戶Id IN (?,?,?)

該Id不出現

而後進一步統計，假設共有500個SQL訪問訂單庫，3個過濾字段出現狀況以下：

過濾字段單Id過濾多Id過濾不出現

用戶Id12040330

訂單Id6080360

商家Id150485

結論明顯，應該選擇用戶Id進行分庫。

等一等，這只是靜態分析，每一個SQL訪問的次數是不同的，所以還要分析每一個SQL的訪問量。咱們分析了Top15執行最多的SQL (它們佔總執行次數85%)，若是按照用戶Id分庫，這些SQL 85%落到單個數據庫, 13%落到多個數據庫，只有2%須要遍歷全部數據庫，明顯優於使用其餘Id進行分庫。

經過量化分析，咱們知道按照用戶Id分庫是最優的，同時也大體知道分庫對現有系統的影響，好比這個例子中，85%的SQL會落到單個數據庫，這部分的訪問性能會優化，堅決了各方對分庫的信心。

分庫策略

分庫維度肯定後，如何把記錄分到各個庫裏呢？通常有兩種方式：

根據數值範圍，好比用戶Id爲1-9999的記錄分到第一個庫，10000-20000的分到第二個庫，以此類推。

根據數值取模，好比用戶Id mod n，餘數爲0的記錄放到第一個庫，餘數爲1的放到第二個庫，以此類推。

兩種分法的優劣比較以下：

評價指標按照範圍分庫按照Mod分庫

庫數量前期數目比較小，能夠隨用戶/業務按需增加前期即根據mode因子肯定庫數量，數目通常比較大

訪問性能前期庫數量小，全庫查詢消耗資源少，單庫查詢性能略差前期庫數量大，全庫查詢消耗資源多，單庫查詢性能略好

調整庫數量比較容易，通常只需爲新用戶增長庫，老庫拆分也隻影響單個庫困難，改變mod因子致使數據在全部庫之間遷移

數據熱點新舊用戶購物頻率有差別，有數據熱點問題新舊用戶均勻到分佈到各個庫，無熱點

實踐中，爲了處理簡單，選擇mod分庫的比較多。同時二次分庫時，爲了數據遷移方便，通常是按倍數增長，好比初始4個庫，二次分裂爲8個，再16個。這樣對於某個庫的數據，一半數據移到新庫，剩餘不動，對比每次只增長一個庫，全部數據都要大規模變更。

補充下，mod分庫通常每一個庫記錄數比較均勻，但也有些數據庫，存在超級Id，這些Id的記錄遠遠超過其餘Id，好比在廣告場景下，某個大廣告主的廣告數可能佔整體很大比例。若是按照廣告主Id取模分庫，某些庫的記錄數會特別多，對於這些超級Id，須要提供單獨庫來存儲記錄。

分庫數量

分庫數量首先和單庫能處理的記錄數有關，通常來講，Mysql 單庫超過5000萬條記錄，Oracle單庫超過1億條記錄，DB壓力就很大(固然處理能力和字段數量/訪問模式/記錄長度有進一步關係)。

在知足上述前提下，若是分庫數量少，達不到分散存儲和減輕DB性能壓力的目的；若是分庫的數量多，好處是每一個庫記錄少，單庫訪問性能好，但對於跨多個庫的訪問，應用程序須要訪問多個庫，若是是併發模式，要消耗寶貴的線程資源；若是是串行模式，執行時間會急劇增長。

最後分庫數量還直接影響硬件的投入，通常每一個分庫跑在單獨物理機上，多一個庫意味多一臺設備。因此具體分多少個庫，要綜合評估，通常初次分庫建議分4-8個庫。

路由透明

分庫從某種意義上來講，意味着DB schema改變了，必然影響應用，但這種改變和業務無關，因此要儘可能保證分庫對應用代碼透明，分庫邏輯儘可能在數據訪問層處理。固然徹底作到這一點很困難，具體哪些應該由DAL負責，哪些由應用負責，這裏有一些建議：

對於單庫訪問，好比查詢條件指定用戶Id，則該SQL只需訪問特定庫。此時應該由DAL層自動路由到特定庫，當庫二次分裂時，也只要修改mod 因子，應用代碼不受影響。

對於簡單的多庫查詢，DAL負責彙總各個數據庫返回的記錄，此時仍對上層應用透明。

對於帶聚合運算的多庫查詢，如帶groupBy/orderby/min/max/avg等關鍵字，建議DAL彙總單個庫返回的結果，上層應用作進一步處理。一方面DAL全面支持各類case，實現很複雜；另外一方面，從1號店實踐來看，這樣的例子很少，在上層應用做針對性處理，更加靈活。

DAL可進一步細分爲JDBC和DAL兩層，基於JDBC層面實現分庫路由，系統開發難度大，靈活性低，目前也沒有很好的成功案例；通常是基於持久層框架進一步封裝成DDAL(分佈式數據訪問層)，實現分庫路由，1號店DAL即基於iBatis進行上層封裝而來。

分頁處理

分庫後，有些分頁查詢須要遍歷全部庫，這些case是分庫最大的受害者L。

舉個分頁的例子，好比要求按時間順序展現某個商家的訂單，每頁100條記錄，因爲是按商家查詢，須要遍歷全部數據庫，假設庫數量是8，咱們來看下分頁處理邏輯：

若是取第1頁數據，則須要從每一個庫裏按時間順序取前100條記錄，8個庫彙總後有800條，而後對這800條記錄在應用裏進行二次排序，最後取前100條。

若是取第10頁數據，則須要從每一個庫裏取前1000(100*10)條記錄，彙總後有8000條記錄，而後對這8000條記錄二次排序後取（900,1000）條記錄。

分庫狀況下，對於第k頁記錄，每一個庫要多取100*(k-1)條記錄，全部庫加起來，多取的記錄更多，因此越是靠後的分頁，系統要耗費更多內存和執行時間。

對比沒分庫的狀況，不管取那一頁，都只要從單個DB裏取100條記錄，並且無需在應用內部作二次排序，很是簡單。

那如何解決分庫狀況下的分頁問題呢？有如下幾種辦法：

若是是在前臺應用提供分頁，則限定用戶只能看前面n頁，這個限制在業務上也是合理的，通常看後面的分頁意義不大（若是必定要看，能夠要求用戶縮小範圍從新查詢）。

若是是後臺批處理任務要求分批獲取數據，則能夠加大page size，好比每次獲取5000條記錄，有效減小分頁數（固然離線訪問通常走備庫，避免衝擊主庫）。

分庫設計時，通常還有配套大數據平臺彙總全部分庫的記錄，有些分頁查詢能夠考慮走大數據平臺。

Lookup映射

分庫字段只有一個，好比這裏是用戶Id，但訂單表還有其餘字段可惟一區分記錄，好比訂單Id，給定一個訂單Id，相應記錄必定在某個庫裏。若是盲目地查詢全部分庫，則帶來沒必要要的開銷，Lookup映射可根據訂單Id，找到相應的用戶Id，從而實現單庫定位。

能夠事先檢索全部訂單Id和用戶Id，保存在Lookup表裏，Lookup表的記錄數和訂單庫記錄總數相等，但它只有2個字段，因此存儲和查詢性能都不是問題。實際使用時，通常經過分佈式緩存來優化Lookup性能。對於新增的訂單，除了寫訂單表，同時要寫Lookup表。

總體架構

訂單生成水平分庫的整體技術架構以下圖所示：

上層應用經過訂單服務/分庫代理和DAL訪問數據庫。

代理對訂單服務實現功能透明，包括聚合運算，非用戶Id到用戶Id的映射。

Lookup表用於訂單Id/用戶Id映射，保證按訂單Id訪問時，能夠直接落到單個庫，Cache是Lookup的內存數據映像，提高性能，cache故障時，直接訪問Lookup表。

DAL提供庫的路由，根據用戶Id定位到某個庫，對於多庫訪問，DAL支持可選的併發訪問模式，並支持簡單記錄彙總。

Lookup表初始化數據來自於現有分庫數據，新增記錄時，直接由代理異步寫入。

上線步驟

訂單表是核心業務表，它的水平拆分影響不少業務，自己的技術改造也很大，很容易出紕漏，上線時，必須謹慎考慮，整個方案實施過程以下：

首先實現Oracle和MySQL兩套庫並行，全部數據訪問指向Oracle庫，經過數據同步程序把數據從Oracle拆分到多個MySQL分庫，好比3分鐘增量同步一次。

按照上述架構圖搭建整個體系，選擇幾個對數據實時性不高的訪問例子（如訪問歷史訂單），轉向MySQL分庫訪問，而後逐漸增長更多非實時case，以檢驗整套體系可行性。

若是性能和功能都沒問題，再一次性把全部實時讀寫訪問轉向MySQL，廢棄Oracle。

這個上線步驟多了數據同步程序的開發（大約1人周工做量，風險很低），但分散了風險，把第一步的技術風險（Lookup/DAL等基礎設施改造）和第二步的業務功能風險（Oracle改MySQL語法）分開。兩階段上線都是一次性成功，特別是第二階段上線，100多個依賴方應用簡單重啓即完成升級，中間沒有出現一例較大問題。

總結

到這裏，Mysql分庫分表訂單生成系統實戰分析就結束了，，不足之處還望你們多多包涵！！以爲收穫的話能夠點個關注收藏轉發一波喔，謝謝大佬們支持。（吹一波，233~~）

下面和你們交流幾點編程的經驗：

一、多寫多敲代碼，好的代碼與紮實的基礎知識必定是實踐出來的

2丶 測試、測試再測試，若是你不完全測試本身的代碼，那恐怕你開發的就不僅是代碼，可能還會聲名狼藉。

3丶 簡化編程，加快速度，代碼風騷，在你完成編碼後，應回頭而且優化它。從長遠來看，這裏或那裏一些的改進，會讓後來的支持人員更加輕鬆。