面試總被問(wèn)分庫(kù)分表怎么辦？這些知識(shí)點(diǎn)你要懂
引言
微服務(wù)、分布式大行其道的當(dāng)下，中、高級(jí)Java工程師面試題中高并發(fā)、大數(shù)據(jù)量、分庫(kù)分表等已經(jīng)成了面試的高頻詞匯，這些知識(shí)不了解面試通過(guò)率不會(huì)太高。
你可以不會(huì)用，但你不能不知道，就是這么一種現(xiàn)狀。技術(shù)名詞大多晦澀難懂，不要死記硬背理解最重要，當(dāng)你捅破那層窗戶(hù)紙，發(fā)現(xiàn)其實(shí)它也就那么回事。
一、為什么要分庫(kù)分表
關(guān)系型數(shù)據(jù)庫(kù)以MySQL為例，單機(jī)的存儲(chǔ)能力、連接數(shù)是有限的，它自身就很容易會(huì)成為系統(tǒng)的瓶頸。當(dāng)單表數(shù)據(jù)量在百萬(wàn)以里時(shí)，我們還可以通過(guò)添加從庫(kù)、優(yōu)化索引提升性能。
一旦數(shù)據(jù)量朝著千萬(wàn)以上趨勢(shì)增長(zhǎng)，再怎么優(yōu)化數(shù)據(jù)庫(kù)，很多操作性能仍下降嚴(yán)重。為了減少數(shù)據(jù)庫(kù)的負(fù)擔(dān)，提升數(shù)據(jù)庫(kù)響應(yīng)速度，縮短查詢(xún)時(shí)間，這時(shí)候就需要進(jìn)行分庫(kù)分表。
二、如何分庫(kù)分表
分庫(kù)分表就是要將大量數(shù)據(jù)分散到多個(gè)數(shù)據(jù)庫(kù)中，使每個(gè)數(shù)據(jù)庫(kù)中數(shù)據(jù)量小響應(yīng)速度快，以此來(lái)提升數(shù)據(jù)庫(kù)整體性能。
核心理念就是對(duì)數(shù)據(jù)進(jìn)行切分（Sharding），以及切分后如何對(duì)數(shù)據(jù)的快速定位與整合。
針對(duì)數(shù)據(jù)切分類(lèi)型，大致可以分為：垂直（縱向）切分和水平（橫向）切分兩種。
1、垂直切分
垂直切分又細(xì)分為垂直分庫(kù)和垂直分表
垂直分庫(kù)
垂直分庫(kù)是基于業(yè)務(wù)分類(lèi)的，和我們常聽(tīng)到的微服務(wù)治理觀念很相似，每一個(gè)獨(dú)立的服務(wù)都擁有自己的數(shù)據(jù)庫(kù)，需要不同業(yè)務(wù)的數(shù)據(jù)需接口調(diào)用。
而垂直分庫(kù)也是按照業(yè)務(wù)分類(lèi)進(jìn)行劃分，每個(gè)業(yè)務(wù)有獨(dú)立數(shù)據(jù)庫(kù)，這個(gè)比較好理解。
垂直分表
垂直分表是基于數(shù)據(jù)表的列為依據(jù)切分的，是一種大表拆小表的模式。
例如：一個(gè)order表有很多字段，把長(zhǎng)度較大且訪問(wèn)不頻繁的字段，拆分出來(lái)創(chuàng)建一個(gè)單獨(dú)的擴(kuò)展表work_extend進(jìn)行存儲(chǔ)。
order表：
| id | workNo | price | describe | … |
|---|---|---|---|---|
| int（12) | int（2) | int（15) | varchar（2000) |
order核心表：
| id | workNo | price | … |
|---|---|---|---|
| int（12) | int（2) | int（15) |
work_extend表：
| id | workNo | describe | … |
|---|---|---|---|
| int（12) | int（2) | varchar（2000) |
數(shù)據(jù)庫(kù)是以行為單位將數(shù)據(jù)加載到內(nèi)存中，這樣拆分以后核心表大多是訪問(wèn)頻率較高的字段，而且字段
長(zhǎng)度也都較短，可以加載更多數(shù)據(jù)到內(nèi)存中，增加查詢(xún)的命中率，減少磁盤(pán)IO，以此來(lái)提升數(shù)據(jù)庫(kù)性能。
優(yōu)點(diǎn)：
- 業(yè)務(wù)間解耦，不同業(yè)務(wù)的數(shù)據(jù)進(jìn)行獨(dú)立的維護(hù)、監(jiān)控、擴(kuò)展
- 在高并發(fā)場(chǎng)景下，一定程度上緩解了數(shù)據(jù)庫(kù)的壓力
缺點(diǎn)：
- 提升了開(kāi)發(fā)的復(fù)雜度，由于業(yè)務(wù)的隔離性，很多表無(wú)法直接訪問(wèn)，必須通過(guò)接口方式聚合數(shù)據(jù)，
- 分布式事務(wù)管理難度增加
- 數(shù)據(jù)庫(kù)還是存在單表數(shù)據(jù)量過(guò)大的問(wèn)題，并未根本上解決，需要配合水平切分
2、水平切分
前邊說(shuō)了垂直切分還是會(huì)存在單表數(shù)據(jù)量過(guò)大的問(wèn)題，當(dāng)我們的應(yīng)用已經(jīng)無(wú)法在細(xì)粒度的垂直切分時(shí)，
依舊存在單庫(kù)讀寫(xiě)、存儲(chǔ)性能瓶頸，這時(shí)就要配合水平切分一起了。
水平切分將一張大數(shù)據(jù)量的表，切分成多個(gè)表結(jié)構(gòu)相同，而每個(gè)表只占原表一部分?jǐn)?shù)據(jù)，然后按不同的條件分散到多個(gè)數(shù)據(jù)庫(kù)中。
假如一張order表有2000萬(wàn)數(shù)據(jù)，水平切分后出來(lái)四個(gè)表，order_1、order_2、order_3、order_4，每張表數(shù)據(jù)500萬(wàn)，以此類(lèi)推。
order_1表：
| id | workNo | price | describe | … |
|---|---|---|---|---|
| int（12) | int（2) | int（15) | varchar（200 |
order_2表：
| id | workNo | price | describe | … |
|---|---|---|---|---|
| int（12) | int（2) | int（15) | varchar（200 |
order_3表：
| id | workNo | price | describe | … |
|---|---|---|---|---|
| int（12) | int（2) | int（15) | varchar（200 |
order_4表：
| id | workNo | price | describe | … |
|---|---|---|---|---|
| int（12) | int（2) | int（15) | varchar（200 |
水平切分又分有庫(kù)內(nèi)分表和分庫(kù)分表
庫(kù)內(nèi)分表
庫(kù)內(nèi)分表雖然將表拆分，但子表都還是在同一個(gè)數(shù)據(jù)庫(kù)實(shí)例中，只是解決了單一表數(shù)據(jù)量過(guò)大的問(wèn)題，并沒(méi)有將拆分后的表分布到不同機(jī)器的庫(kù)上，還在競(jìng)爭(zhēng)同一個(gè)物理機(jī)的CPU、內(nèi)存、網(wǎng)絡(luò)IO。
分庫(kù)分表
分庫(kù)分表則是將切分出來(lái)的子表，分散到不同的數(shù)據(jù)庫(kù)中，從而使得單個(gè)表的數(shù)據(jù)量變小，達(dá)到分布式的效果。
優(yōu)點(diǎn)：
- 解決高并發(fā)時(shí)單庫(kù)數(shù)據(jù)量過(guò)大的問(wèn)題，提升系統(tǒng)穩(wěn)定性和負(fù)載能力
- 業(yè)務(wù)系統(tǒng)改造的工作量不是很大
缺點(diǎn)：
- 跨分片的事務(wù)一致性難以保證
- 跨庫(kù)的join關(guān)聯(lián)查詢(xún)性能較差
- 擴(kuò)容的難度和維護(hù)量較大，（拆分成幾千張子表想想都恐怖）
三、數(shù)據(jù)該往哪個(gè)庫(kù)的表存？
分庫(kù)分表以后會(huì)出現(xiàn)一個(gè)問(wèn)題，一張表會(huì)出現(xiàn)在多個(gè)數(shù)據(jù)庫(kù)里，到底該往哪個(gè)庫(kù)的表里存呢？
1、根據(jù)取值范圍
按照時(shí)間區(qū)間或ID區(qū)間來(lái)切分，舉個(gè)栗子：假如我們切分的是用戶(hù)表，可以定義每個(gè)庫(kù)的User表里只存10000條數(shù)據(jù)，第一個(gè)庫(kù)userId從1 ~ 9999，第二個(gè)庫(kù)10000 ~ 20000，第三個(gè)庫(kù)20001~ 30000……以此類(lèi)推。
優(yōu)點(diǎn)：
- 單表數(shù)據(jù)量是可控的
- 水平擴(kuò)展簡(jiǎn)單只需增加節(jié)點(diǎn)即可，無(wú)需對(duì)其他分片的數(shù)據(jù)進(jìn)行遷移
- 能快速定位要查詢(xún)的數(shù)據(jù)在哪個(gè)庫(kù)
缺點(diǎn)：
- 由于連續(xù)分片可能存在數(shù)據(jù)熱點(diǎn)，如果按時(shí)間字段分片，有些分片存儲(chǔ)最近時(shí)間段內(nèi)的數(shù)據(jù)，可能會(huì)被頻繁的讀寫(xiě)，而有些分片存儲(chǔ)的歷史數(shù)據(jù)，則很少被查詢(xún)
2、hash取模
hash取模mod（對(duì)hash結(jié)果取余數(shù) (hash() mod N)）的切分方式比較常見(jiàn)，還拿User表舉例，對(duì)數(shù)據(jù)庫(kù)從0到N-1進(jìn)行編號(hào)，對(duì)User表中userId字段進(jìn)行取模，得到余數(shù)i，i=0存第一個(gè)庫(kù)，i=1存第二個(gè)庫(kù)，i=2存第三個(gè)庫(kù)….以此類(lèi)推。
這樣同一個(gè)用戶(hù)的數(shù)據(jù)都會(huì)存在同一個(gè)庫(kù)里，用userId作為條件查詢(xún)就很好定位了
優(yōu)點(diǎn)：
- 數(shù)據(jù)分片相對(duì)比較均勻，不易出現(xiàn)某個(gè)庫(kù)并發(fā)訪問(wèn)的問(wèn)題
缺點(diǎn)：
- 但這種算法存在一些問(wèn)題，當(dāng)某一臺(tái)機(jī)器宕機(jī)，本應(yīng)該落在該數(shù)據(jù)庫(kù)的請(qǐng)求就無(wú)法得到正確的處理，這時(shí)宕掉的實(shí)例會(huì)被踢出集群，此時(shí)算法變成hash(userId) mod N-1，用戶(hù)信息可能就不再在同一個(gè)庫(kù)中。
四、分庫(kù)分表后會(huì)有哪些坑？
1、事務(wù)一致性問(wèn)題
由于表分布在不同庫(kù)中，不可避免會(huì)帶來(lái)跨庫(kù)事務(wù)問(wèn)題。一般可使用"XA協(xié)議"和"兩階段提交"處理，但是這種方式性能較差，代碼開(kāi)發(fā)量也比較大。
通常做法是做到最終一致性的方案，往往不苛求系統(tǒng)的實(shí)時(shí)一致性，只要在允許的時(shí)間段內(nèi)達(dá)到最終一致性即可，可采用事務(wù)補(bǔ)償?shù)姆绞健?/p>
2、分頁(yè)、排序的坑
日常開(kāi)發(fā)中分頁(yè)、排序是必備功能，而多庫(kù)進(jìn)行查詢(xún)時(shí)limit分頁(yè)、order by排序，著實(shí)讓人比較頭疼。
分頁(yè)需按照指定字段進(jìn)行排序，如果排序字段恰好是分片字段時(shí)，通過(guò)分片規(guī)則就很容易定位到分片的位置；一旦排序字段非分片字段時(shí)，就需要先在不同的分片節(jié)點(diǎn)中將數(shù)據(jù)進(jìn)行排序并返回，然后將不同分片返回的結(jié)果集進(jìn)行匯總和再次排序，最終返回給用戶(hù)，過(guò)程比較復(fù)雜。
3、全局唯一主鍵問(wèn)題
由于分庫(kù)分表后，表中的數(shù)據(jù)同時(shí)存在于多個(gè)數(shù)據(jù)庫(kù)，而某個(gè)分區(qū)數(shù)據(jù)庫(kù)的自增主鍵已經(jīng)無(wú)法滿(mǎn)足全局
唯一，所以此時(shí)一個(gè)能夠生成全局唯一ID的系統(tǒng)是非常必要的。那么這個(gè)全局唯一ID就叫分布式ID。
可以參考我之前寫(xiě)的這篇文章《一口氣說(shuō)出 9種 分布式ID生成方式，面試官有點(diǎn)懵了》
五、分庫(kù)分表工具？
自己開(kāi)發(fā)分庫(kù)分表工具的工作量是巨大的，好在業(yè)界已經(jīng)有了很多比較成熟的分庫(kù)分表中間件，我們可
以將更多的時(shí)間放在業(yè)務(wù)實(shí)現(xiàn)上
- sharding-jdbc（當(dāng)當(dāng)）
- TSharding（蘑菇街）
- Atlas（奇虎360）
- Cobar（阿里巴巴）
- MyCAT（基于Cobar）
- Oceanus（58同城） Vitess（谷歌）
