0x01：簡介

大中型項目，一旦數(shù)據(jù)量比較大，就要進(jìn)行對數(shù)據(jù)的拆分了，一般有兩種，垂直拆分與水平拆分。

mysql 一般單表 500 萬條，存儲上限 256TB

垂直分庫

一個數(shù)據(jù)庫的數(shù)據(jù)庫量大，拆分出訂單庫和用戶庫

垂直分庫是指按照業(yè)務(wù)將表進(jìn)行分類，分布到不同的數(shù)據(jù)庫上面，每個庫放在不同的服務(wù)器上，其核心思想是專庫專用。

優(yōu)點：解決業(yè)務(wù)層面的耦合，業(yè)務(wù)清晰，能對不同業(yè)務(wù)進(jìn)行分級管理，維護(hù)，監(jiān)控，擴(kuò)展等。高并發(fā)場景下，垂直分庫一定程度上提升 IO。但是依然沒有解決單表數(shù)據(jù)量過大的問題。

拆分思想

隨著業(yè)務(wù)增長，可以將訂單數(shù)據(jù)劃分成兩大類型：分別是熱數(shù)據(jù)和冷數(shù)據(jù)。

• 熱數(shù)據(jù)：3 個月內(nèi)的訂單數(shù)據(jù)，查詢實時性較高;使用 mysql 進(jìn)行存儲，當(dāng)然需要分庫分表；

• 冷數(shù)據(jù) A：3 個月 ~ 12 個月前的訂單數(shù)據(jù)，查詢頻率不高;對于這類數(shù)據(jù)可以存儲在 ES 中，了利用搜索引擎特性基本上可以做到較快的查詢

• 冷數(shù)據(jù) B：1 年前的訂單數(shù)據(jù)，幾乎不會查詢，只有偶爾的查詢需求;對于這類不經(jīng)常查詢的數(shù)據(jù)，可以存放到 Hive 中。

Hash 取模方案

以水平分表為例

在我們設(shè)計系統(tǒng)之前，可以先預(yù)估一下大概這幾年的訂單量，如：4000 萬。每張表我們可以容納 1000 萬，也我們可以設(shè)計 4 張表進(jìn)行存儲。

• 優(yōu)點：

訂單數(shù)據(jù)可以均勻的放到那 4 張表中，這樣此訂單進(jìn)行操作時，就不會有熱點問題。

• 缺點：

將來的數(shù)據(jù)遷移和擴(kuò)容，會很難。數(shù)據(jù)不連續(xù)

Range 范圍方案

以水平分表為例

• 優(yōu)點：有利于擴(kuò)容，不需要數(shù)據(jù)遷移

• 缺點：有熱點問題

分組思想

先按范圍進(jìn)行分組。比如 0-4000 萬分到 group1，然后 group1 中再進(jìn)行 Hash 分，這樣當(dāng)擴(kuò)容的時候，直接新增一個 group2，存儲 4000 萬到 8000 萬的數(shù)據(jù)。然后每個組里的表或者庫再進(jìn)行 Hash 分。

水平分表

分表時要選擇適當(dāng)?shù)姆直聿呗裕堑臄?shù)據(jù)能夠較為均勻的分到不同的表中，并且不影響查詢。

大部分?jǐn)?shù)據(jù)都是與用戶關(guān)聯(lián)的，因此，用戶 id 是最常用的分表字段。因為大部分查詢都需要帶上用戶 id，這樣既不影響查詢，又能夠使數(shù)據(jù)較為均衡地分布到各個表中(當(dāng)然，有的場景也可能會出現(xiàn)冷熱數(shù)據(jù)分布不均衡的情況)。

拆分的記錄根據(jù)user_id%256取得對應(yīng)的表進(jìn)行存儲，前臺應(yīng)用則根據(jù)對應(yīng)的 user_id%256，找到對應(yīng)訂單存儲的表進(jìn)行訪問。（即 id 除以 256 余數(shù)為 0 則查 0 號表）

垂直分表

比如當(dāng)用戶瀏覽商品列表時，只有感興趣的才會查看商品的詳細(xì)描述，且該字段存儲空間較大，訪問頻次低，只有商品名稱，商品價格等字段是用戶關(guān)心的，訪問頻次高。故可以將商品信息表拆分成兩張表

這樣可以避免 IO 爭搶并減少鎖表的幾率，查看詳情與商品信心瀏覽互不影響。

垂直分庫

垂直分庫是原本庫里有三張表，現(xiàn)在每個庫里有一張表

水平分庫

分表能夠解決單表數(shù)據(jù)量過大帶來的查詢效率下降的問題，但是，卻無法給數(shù)據(jù)庫的并發(fā)處理能力帶來質(zhì)的提升。面對高并發(fā)的讀寫訪問，當(dāng)數(shù)據(jù)庫 master 服務(wù)器無法承載寫操作壓力時，不管如何擴(kuò)展 slave 服務(wù)器，此時都沒有意義了。

水平分庫就是每個庫的表都還是一樣的， 只是將數(shù)據(jù)分散到不同的庫里

分庫可以采用通過一個關(guān)鍵字取模的方式

讀寫分離

讀寫分離一般適用于主從結(jié)構(gòu)，從節(jié)點負(fù)責(zé)讀，主節(jié)點負(fù)責(zé)寫

分庫分表

有時數(shù)據(jù)庫可能既面臨著高并發(fā)訪問的壓力，又需要面對海量數(shù)據(jù)的存儲問題，這時需要對數(shù)據(jù)庫既采用分表策略，又采用分庫策略，以便同時擴(kuò)展系統(tǒng)的并發(fā)處理能力，以及提升單表的查詢性能，這就是所謂的分庫分表。

分庫分表的策略比前面的僅分庫或者僅分表的策略要更為復(fù)雜，一種分庫分表的路由策略如下：

1. 中間變量 = user_id % (分庫數(shù)量 * 每個庫的表數(shù)量)

2. 庫 = 取整數(shù) (中間變量 / 每個庫的表數(shù)量)

3. 表 = 中間變量 % 每個庫的表數(shù)量

如何做分庫分表

1：根據(jù)業(yè)務(wù)分成用戶，商品，訂單模塊，每個對應(yīng)不同的庫

將不同的業(yè)務(wù)放到不同的庫中，將原來所有壓力由同一個庫中分散到不同的庫中，提升系統(tǒng)吞吐量

分表策略

orderid%100 方式，但這種……加庫怎么辦？范圍查詢怎么辦？根據(jù) userid 查怎么辦？

0x02: 主流框架

數(shù)據(jù)庫中間件分為兩類

• proxy：中間經(jīng)過一層代理，需要獨立部署

• client：在客戶端就知道指定到那個數(shù)據(jù)庫

各個中間件

• shardingSphere

當(dāng)當(dāng)開源的，屬于 client 層方案。確實之前用的還比較多一些，因為 SQL 語法支持也比較多，沒有太多限制，而且目前推出到了 2.0 版本，支持分庫分表、讀寫分離、分布式 id 生成、柔性事務(wù)（最大努力送達(dá)型事務(wù)、TCC 事務(wù)）。而且確實之前使用的公司會比較多一些（這個在官網(wǎng)有登記使用的公司，可以看到從 2017 年一直到現(xiàn)在，是不少公司在用的），目前社區(qū)也還一直在開發(fā)和維護(hù)，還算是比較活躍，個人認(rèn)為算是一個現(xiàn)在也可以選擇的方案。

sharding-jdbc 這種 client 層方案的優(yōu)點在于不用部署，運維成本低，不需要代理層的二次轉(zhuǎn)發(fā)請求，性能很高，但是如果遇到升級啥的需要各個系統(tǒng)都重新升級版本再發(fā)布，各個系統(tǒng)都需要耦合 sharding-jdbc 的依賴；

• MyCAT（基于阿里開源的 Cobar 產(chǎn)品而研發(fā)）

基于 cobar 改造的，屬于 proxy 層方案，支持的功能非常完善，而且目前應(yīng)該是非常火的而且不斷流行的數(shù)據(jù)庫中間件，社區(qū)很活躍，也有一些公司開始在用了。但是確實相比于 sharding jdbc 來說，年輕一些，經(jīng)歷的錘煉少一些。

mycat 這種 proxy 層方案的缺點在于需要部署，自己及運維一套中間件，運維成本高，但是好處在于對于各個項目是透明的，如果遇到升級之類的都是自己中間件那里搞就行了。

問題

事務(wù)問題

方案一：使用分布式事務(wù)

• 優(yōu)點：交由數(shù)據(jù)庫管理，簡單有效

• 缺點：性能代價高，特別是 shard 越來越多時

方案二：由應(yīng)用程序和數(shù)據(jù)庫共同控制

• 原理：將一個跨多個數(shù)據(jù)庫的分布式事務(wù)分拆成多個僅處 于單個數(shù)據(jù)庫上面的小事務(wù)，并通過應(yīng)用程序來總控 各個小事務(wù)。

• 優(yōu)點：性能上有優(yōu)勢

• 缺點：需要應(yīng)用程序在事務(wù)控制上做靈活設(shè)計。如果使用 了spring的事務(wù)管理，改動起來會面臨一定的困難。

唯一主鍵

參考：業(yè)務(wù) ID 的生成方式

https://github.com/3218870799/-Note/blob/main/我的博客/業(yè)務(wù)ID的生成方式.md

跨節(jié)點語句

join
count(*)
order by

分頁：需要在不同的分片節(jié)點中將數(shù)據(jù)進(jìn)行排序并返回，并將不同分片返回的結(jié)果集進(jìn)行匯總和再次排序，最后再返回給用戶。

取出第十頁，每頁 10 個

分別在各個節(jié)點上得到結(jié)果后在應(yīng)用程序端進(jìn)行合并。

數(shù)據(jù)遷移

現(xiàn)在有一個未分庫分表的系統(tǒng)，未來要分庫分表，如何設(shè)計才可以讓系統(tǒng)從未分庫分表動態(tài)切換到分庫分表上？

停機(jī)遷移方案

雙寫遷移方案

就是在線上系統(tǒng)里面，之前所有寫庫的地方，增刪改操作，都除了對老庫增刪改，都加上對新庫的增刪改，這就是所謂雙寫，同時寫倆庫，老庫和新庫。

跑起來讀老庫數(shù)據(jù)讀到寫入新庫，寫的時候要根據(jù) gmt_modified 這類字段判斷這條數(shù)據(jù)最后修改的時間，除非是讀出來的數(shù)據(jù)在新庫里沒有，或者是比新庫的數(shù)據(jù)新才會寫。

接著導(dǎo)完一輪之后，有可能數(shù)據(jù)還是存在不一致，那么就程序自動做一輪校驗，比對新老庫每個表的每條數(shù)據(jù)，接著如果有不一樣的，就針對那些不一樣的，從老庫讀數(shù)據(jù)再次寫。反復(fù)循環(huán)，直到兩個庫每個表的數(shù)據(jù)都完全一致為止。

容量規(guī)劃，擴(kuò)容問題

來自淘寶綜合業(yè)務(wù)平臺團(tuán)隊，它利用對 2 的倍數(shù)取余具有向前兼容的特性（如對 4 取余得 1 的數(shù)對 2 取余也是 1）來分配數(shù)據(jù)，避免了行級別的數(shù)據(jù)遷移，但是依然需要進(jìn)行表級別的遷移，同時對擴(kuò)容規(guī)模和分表數(shù)量都有限制。

停機(jī)擴(kuò)容

導(dǎo)數(shù)工具

source：//www.yuque.com/jykss/jykss/snls62#kqv9R

喜歡，在看