面試總被問分庫分表怎么辦？你可以這樣懟他

微服務、分布式大行其道的當下，中、高級Java工程師面試題中高并發、大數據量、分庫分表等已經成

了面試的高頻詞匯，這些知識不了解面試通過率不會太高。你可以不會用，但你不能不知道，就是這么

一種現狀。技術名詞大多晦澀難懂，不要死記硬背理解最重要，當你捅破那層窗戶紙，發現其實它也就

那么回事。

關系型數據庫以MySQL為例，單機的存儲能力、連接數是有限的，它自身就很容易會成為系統的瓶

頸。當單表數據量在百萬以里時，我們還可以通過添加從庫、優化索引提升性能。一旦數據量朝著千萬

以上趨勢增長，再怎么優化數據庫，很多操作性能仍下降嚴重。為了減少數據庫的負擔，提升數據庫響

應速度，縮短查詢時間，這時候就需要進行分庫分表。

分庫分表就是要將大量數據分散到多個數據庫中，使每個數據庫中數據量小響應速度快，以此來提升數

據庫整體性能。核心理念就是對數據進行切分（Sharding），以及切分后如何對數據的快速定位與整合。

針對數據切分類型，大致可以分為：垂直（縱向）切分和水平（橫向）切分兩種。

垂直切分又細分為垂直分庫和垂直分表

垂直分庫

垂直分庫是基于業務分類的，和我們常聽到的微服務治理觀念很相似，每一個獨立的服務都擁有自己的

數據庫，需要不同業務的數據需接口調用。而垂直分庫也是按照業務分類進行劃分，每個業務有獨立數

據庫，這個比較好理解。

垂直分表

垂直分表是基于數據表的列為依據切分的，是一種大表拆小表的模式。

例如：一個order表有很多字段，把長度較大且訪問不頻繁的字段，拆分出來創建一個單獨的擴展表work_extend進行存儲。

order表：

拆分后

order核心表：

work_extend表：

數據庫是以行為單位將數據加載到內存中，這樣拆分以后核心表大多是訪問頻率較高的字段，而且字段

長度也都較短，可以加載更多數據到內存中，增加查詢的命中率，減少磁盤IO，以此來提升數據庫性能。

優點：

業務間解耦，不同業務的數據進行獨立的維護、監控、擴展

在高并發場景下，一定程度上緩解了數據庫的壓力

缺點：

提升了開發的復雜度，由于業務的隔離性，很多表無法直接訪問，必須通過接口方式聚合數據，

分布式事務管理難度增加

數據庫還是存在單表數據量過大的問題，并未根本上解決，需要配合水平切分

前邊說了垂直切分還是會存在單表數據量過大的問題，當我們的應用已經無法在細粒度的垂直切分時，依舊存在單庫讀寫、存儲性能瓶頸，這時就要配合水平切分一起了。

水平切分將一張大數據量的表，切分成多個表結構相同，而每個表只占原表一部分數據，然后按不同的條件分散到多個數據庫中。

假如一張order表有2000萬數據，水平切分后出來四個表，order_1、order_2、order_3、order_4，每張表數據500萬，以此類推。

order_1表：

水平切分又分有庫內分表和分庫分表

庫內分表

庫內分表雖然將表拆分，但子表都還是在同一個數據庫實例中，只是解決了單一表數據量過大的問題，并沒有將拆分后的表分布到不同機器的庫上，還在競爭同一個物理機的CPU、內存、網絡IO。

分庫分表

分庫分表則是將切分出來的子表，分散到不同的數據庫中，從而使得單個表的數據量變小，達到分布式的效果。

優點：

解決高并發時單庫數據量過大的問題，提升系統穩定性和負載能力

業務系統改造的工作量不是很大

缺點：

跨分片的事務一致性難以保證

跨庫的join關聯查詢性能較差

擴容的難度和維護量較大，（拆分成幾千張子表想想都恐怖）

分庫分表以后會出現一個問題，一張表會出現在多個數據庫里，到底該往哪個庫的表里存呢？

按照時間區間或ID區間來切分，舉個栗子：假如我們切分的是用戶表，可以定義每個庫的User表里只存10000條數據，第一個庫userId從1 ~ 9999，第二個庫10000 ~ 20000，第三個庫20001~ 30000......以此類推。

優點：

單表數據量是可控的

水平擴展簡單只需增加節點即可，無需對其他分片的數據進行遷移

能快速定位要查詢的數據在哪個庫

缺點：

由于連續分片可能存在數據熱點，如果按時間字段分片，有些分片存儲最近時間段內的數據，可能會被頻繁的讀寫，而有些分片存儲的歷史數據，則很少被查詢

hash取模mod（對hash結果取余數 (hash() mod N)）的切分方式比較常見，還拿User表舉例，對數據庫從0到N-1進行編號，對User表中userId字段進行取模，得到余數i，i=0存第一個庫，i=1存第二個庫，i=2存第三個庫....以此類推。

這樣同一個用戶的數據都會存在同一個庫里，用userId作為條件查詢就很好定位了

優點：

數據分片相對比較均勻，不易出現某個庫并發訪問的問題

缺點：

但這種算法存在一些問題，當某一臺機器宕機，本應該落在該數據庫的請求就無法得到正確的處理，這時宕掉的實例會被踢出集群，此時算法變成hash(userId) mod N-1，用戶信息可能就不再在同一個庫中。

由于表分布在不同庫中，不可避免會帶來跨庫事務問題。一般可使用"XA協議"和"兩階段提交"處理，但是這種方式性能較差，代碼開發量也比較大。

通常做法是做到最終一致性的方案，往往不苛求系統的實時一致性，只要在允許的時間段內達到最終一致性即可，可采用事務補償的方式。

日常開發中分頁、排序是必備功能，而多庫進行查詢時limit分頁、order by排序，著實讓人比較頭疼。

分頁需按照指定字段進行排序，如果排序字段恰好是分片字段時，通過分片規則就很容易定位到分片的位置；一旦排序字段非分片字段時，就需要先在不同的分片節點中將數據進行排序并返回，然后將不同分片返回的結果集進行匯總和再次排序，最終返回給用戶，過程比較復雜。

由于分庫分表后，表中的數據同時存在于多個數據庫，而某個分區數據庫的自增主鍵已經無法滿足全局

唯一，所以此時一個能夠生成全局唯一ID的系統是非常必要的。那么這個全局唯一ID就叫分布式ID。可

以參考我之前寫的這篇文章《一口氣說出 9種 分布式ID生成方式，面試官有點懵了》

自己開發分庫分表工具的工作量是巨大的，好在業界已經有了很多比較成熟的分庫分表中間件，我們可

以將更多的時間放在業務實現上

sharding-jdbc（當當）

TSharding（蘑菇街）

Atlas（奇虎360）

Cobar（阿里巴巴）

MyCAT（基于Cobar）

Oceanus（58同城） Vitess（谷歌）

----

分布式 數據庫

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。