隨著大型互聯(lián)網(wǎng)應(yīng)用的發(fā)展，海量數(shù)據(jù)的存儲(chǔ)和訪問(wèn)成為系統(tǒng)設(shè)計(jì)的瓶頸，分布式處理成為不二選擇。數(shù)據(jù)庫(kù)拆分，特別是水平分庫(kù)是個(gè)高難度的活，涉及一系列技術(shù)決策。
　　本人有幸負(fù)責(zé)1號(hào)店訂單水平分庫(kù)的方案設(shè)計(jì)及實(shí)施落地，這里結(jié)合項(xiàng)目實(shí)踐，對(duì)水平分庫(kù)做一個(gè)系統(tǒng)地剖析，希望為大家水平分庫(kù)（包括去IOE）改造提供思路，主要內(nèi)容包括：
　　水平分庫(kù)說(shuō)明分庫(kù)維度– 根據(jù)哪個(gè)字段分庫(kù)分庫(kù)策略– 記錄如何分配到不同庫(kù)分庫(kù)數(shù)量– 初始庫(kù)數(shù)量及庫(kù)數(shù)量如何增長(zhǎng) 路由透明– 如何實(shí)現(xiàn)庫(kù)路由，支持應(yīng)用透明分頁(yè)處理– 跨多個(gè)庫(kù)的分頁(yè)case如何處理Lookup映射—非分庫(kù)字段映射到分庫(kù)字段，實(shí)現(xiàn)單庫(kù)訪問(wèn)整體架構(gòu)– 分庫(kù)的整體技術(shù)架構(gòu) 上線步驟– 分庫(kù)改造實(shí)施上線項(xiàng)目總結(jié)
　　水平分庫(kù)說(shuō)明
　　數(shù)據(jù)庫(kù)拆分有兩種：
　　1）垂直分庫(kù)
　　數(shù)據(jù)庫(kù)里的表太多，拿出部分到新的庫(kù)里，一般是根據(jù)業(yè)務(wù)劃分表，關(guān)系密切的表放同一數(shù)據(jù)庫(kù)，應(yīng)用修改數(shù)據(jù)庫(kù)連接即可，比較簡(jiǎn)單。
　　2）水平分庫(kù)
　　某張表太大，單個(gè)數(shù)據(jù)庫(kù)存儲(chǔ)不下或訪問(wèn)性能有壓力，把一張表拆成多張，每張表存放部分記錄，保存在不同的數(shù)據(jù)庫(kù)里，水平分庫(kù)需要對(duì)系統(tǒng)做大的改造。
　　
　　1號(hào)店核心的訂單表存儲(chǔ)在Oracle數(shù)據(jù)庫(kù)，記錄有上億條，字段有上百個(gè)，訪問(wèn)的模式也是復(fù)雜多樣，隨著業(yè)務(wù)快速增長(zhǎng)，無(wú)論存儲(chǔ)空間或訪問(wèn)性能都面臨巨大挑戰(zhàn)，特別在大促時(shí)，訂單庫(kù)已成為系統(tǒng)瓶頸。
　　通常有兩種解決辦法：
　　1）Scale up，升級(jí)Oracle數(shù)據(jù)庫(kù)所在的物理機(jī)，提升內(nèi)存/存儲(chǔ)/IO性能，但這種升級(jí)費(fèi)用昂貴，并且只能滿足短期需要。
　　2）Scale out，把訂單庫(kù)拆分為多個(gè)庫(kù)，分散到多臺(tái)機(jī)器進(jìn)行存儲(chǔ)和訪問(wèn)，這種做法支持水平擴(kuò)展，可以滿足長(zhǎng)遠(yuǎn)需要。
　　1號(hào)店采取后一種做法，它的訂單庫(kù)主要包括訂單主表/訂單明細(xì)表（記錄商品明細(xì)）/訂單擴(kuò)展表，水平分庫(kù)即把這3張表的記錄分到多個(gè)數(shù)據(jù)庫(kù)中，訂單水平分庫(kù)效果如下圖所示：
　　
　　原來(lái)一個(gè)Oracle庫(kù)被多個(gè)MySQL庫(kù)取代，支持1主多備和讀寫(xiě)分離，主備之間通過(guò)MySQL自帶的數(shù)據(jù)同步機(jī)制（SLA《1秒），所有應(yīng)用通過(guò)訂單服務(wù)訪問(wèn)訂單數(shù)據(jù)。
　　分庫(kù)維度
　　水平分庫(kù)首先要考慮根據(jù)哪個(gè)字段作為分庫(kù)維度，選擇標(biāo)準(zhǔn)是盡量避免應(yīng)用代碼和SQL性能受影響，這就要求當(dāng)前SQL在分庫(kù)后，訪問(wèn)盡量落在單個(gè)庫(kù)里，否則單庫(kù)訪問(wèn)變成多庫(kù)掃描，讀寫(xiě)性能和應(yīng)用邏輯都會(huì)受較大影響，。