經過四道常問面試題，帶你瞭解什麼是數據庫分庫分表

時間 2019-12-10

標籤經過常問面試瞭解什麼數據庫分庫分表欄目快樂工作简体版

原文原文鏈接

編者語：爲了不被誤解爲：「手裏有把錘子，看什麼都是釘子！」，說明一下不是什麼業務都適合分佈式數據庫，更不是用了分佈式數據庫性能就必定能獲得擴展。面試

其次：本文爲純乾貨，建議先轉發、收藏再觀看。sql

分佈式數據庫已經流行好多年，產品很是衆多，其中分佈式數據庫中間件使用場景最廣。本文主要是經過幾道關於分庫分表的常問面試題帶你深刻了解數據庫分庫分表，但願對你們可以有所幫助！數據庫

一：面試題

爲何要分庫分表？
用過哪些分庫分表中間件？
不一樣的分庫分表中間件都有什麼優勢和缺點？
大傢俱體是如何對數據庫如何進行垂直拆分或水平拆分的？

2、面試官心理分析

其實這塊確定是扯到高併發了，由於分庫分表必定是爲了支撐高併發、數據量大兩個問題的。並且如今說實話，尤爲是互聯網類的公司面試，基本上都會來這麼一下，分庫分表如此廣泛的技術問題，不問實在是不行，而若是你不知道那也實在是說不過去！緩存

3、面試題剖析

3.一、爲何要分庫分表？（設計高併發系統的時候，數據庫層面該如何設計？）服務器

說白了，分庫分表是兩回事兒，你們可別搞混了，多是光分庫不分表，也多是光分表不分庫，都有可能。網絡

我先給你們拋出來一個場景。併發

假如咱們如今是一個小創業公司（或者是一個 BAT 公司剛興起的一個新部門），如今註冊用戶就 20 萬，天天活躍用戶就 1 萬，天天單表數據量就 1000，而後高峯期每秒鐘併發請求最多就 10。天，就這種系統，隨便找一個有幾年工做經驗的，而後帶幾個剛培訓出來的，隨便乾乾均可以。負載均衡

結果沒想到咱們運氣竟然這麼好，碰上個 CEO 帶着咱們走上了康莊大道，業務發展迅猛，過了幾個月，註冊用戶數達到了 2000 萬！天天活躍用戶數 100 萬！天天單表數據量 10 萬條！高峯期每秒最大請求達到 1000！同時公司還順帶着融資了兩輪，進帳了幾個億人民幣啊！公司估值達到了驚人的幾億美金！這是小獨角獸的節奏！運維

好吧，沒事，如今你們感受壓力已經有點大了，爲啥呢？由於天天多 10 萬條數據，一個月就多 300 萬條數據，如今我們單表已經幾百萬數據了，立刻就破千萬了。可是勉強還能撐着。高峯期請求如今是 1000，我們線上部署了幾臺機器，負載均衡搞了一下，數據庫撐 1000QPS 也還湊合。可是你們如今開始感受有點擔憂了，接下來咋整呢......分佈式

再接下來幾個月，個人天，CEO 太牛逼了，公司用戶數已經達到 1 億，公司繼續融資幾十億人民幣啊！公司估值達到了驚人的幾十億美金，成爲了國內今年最牛逼的明星創業公司！天，咱們太幸運了。

可是咱們同時也是不幸的，由於此時天天活躍用戶數上千萬，天天單表新增數據多達 50 萬，目前一個表總數據量都已經達到了兩三千萬了！扛不住啊！數據庫磁盤容量不斷消耗掉！高峯期併發達到驚人的 5000~8000！別開玩笑了，哥。我跟你保證，你的系統支撐不到如今，已經掛掉了！

好吧，因此你看到這裏差很少就理解分庫分表是怎麼回事兒了，實際上這是跟着你的公司業務發展走的，你公司業務發展越好，用戶就越多，數據量越大，請求量越大，那你單個數據庫必定扛不住。

分表

好比你單表都幾千萬數據了，你肯定你能扛住麼？絕對不行，單表數據量太大，會極大影響你的 sql 執行的性能，到了後面你的 sql 可能就跑的很慢了。通常來講，就以個人經驗來看，單表到幾百萬的時候，性能就會相對差一些了，你就得分表了。

分表是啥意思？就是把一個表的數據放到多個表中，而後查詢的時候你就查一個表。好比按照用戶 id 來分表，將一個用戶的數據就放在一個表中。而後操做的時候你對一個用戶就操做那個表就行了。這樣能夠控制每一個表的數據量在可控的範圍內，好比每一個表就固定在 200 萬之內。

分庫

分庫是啥意思？就是你一個庫通常咱們經驗而言，最多支撐到併發 2000，必定要擴容了，並且一個健康的單庫併發值你最好保持在每秒 1000 左右，不要太大。那麼你能夠將一個庫的數據拆分到多個庫中，訪問的時候就訪問一個庫好了。

這就是所謂的分庫分表，爲啥要分庫分表？你明白了吧。

3.二、用過哪些分庫分表中間件？不一樣的分庫分表中間件都有什麼優勢和缺點？

這個其實就是看看你瞭解哪些分庫分表的中間件，各個中間件的優缺點是啥？而後你用過哪些分庫分表的中間件。

比較常見的包括：

cobar
TDDL
atlas
sharding-jdbc
mycat

3.2.1：cobar

阿里 b2b 團隊開發和開源的，屬於 proxy 層方案，就是介於應用服務器和數據庫服務器之間。應用程序經過 JDBC 驅動訪問 cobar 集羣，cobar 根據 SQL 和分庫規則對 SQL 作分解，而後分發到 MySQL 集羣不一樣的數據庫實例上執行。早些年還能夠用，可是最近幾年都沒更新了，基本沒啥人用，差很少算是被拋棄的狀態吧。並且不支持讀寫分離、存儲過程、跨庫 join 和分頁等操做。

3.2.2：TDDL

淘寶團隊開發的，屬於 client 層方案。支持基本的 crud 語法和讀寫分離，但不支持 join、多表查詢等語法。目前使用的也很少，由於還依賴淘寶的 diamond 配置管理系統。

3.2.3：atlas

360 開源的，屬於 proxy 層方案，之前是有一些公司在用的，可是確實有一個很大的問題就是社區最新的維護都在 5 年前了。因此，如今用的公司基本也不多了。

3.2.4：sharding-jdbc

噹噹開源的，屬於 client 層方案。確實以前用的還比較多一些，由於 SQL 語法支持也比較多，沒有太多限制，並且目前推出到了 2.0 版本，支持分庫分表、讀寫分離、分佈式 id 生成、柔性事務（最大努力送達型事務、TCC 事務）。並且確實以前使用的公司會比較多一些（這個在官網有登記使用的公司，能夠看到從 2017 年一直到如今，是有很多公司在用的），目前社區也還一直在開發和維護，還算是比較活躍，我的認爲算是一個如今也能夠選擇的方案。

3.2.5：mycat

基於 cobar 改造的，屬於 proxy 層方案，支持的功能很是完善，並且目前應該是很是火的並且不斷流行的數據庫中間件，社區很活躍，也有一些公司開始在用了。可是確實相比於 sharding jdbc 來講，年輕一些，經歷的錘鍊少一些。

小結

綜上，如今其實建議考量的，就是 sharding-jdbc 和 mycat，這兩個均可以去考慮使用。

sharding-jdbc 這種 client 層方案的優勢在於不用部署，運維成本低，不須要代理層的二次轉發請求，性能很高，可是若是遇到升級啥的須要各個系統都從新升級版本再發布，各個系統都須要耦合 sharding-jdbc 的依賴；

mycat 這種 proxy 層方案的缺點在於須要部署，本身運維一套中間件，運維成本高，可是好處在於對於各個項目是透明的，若是遇到升級之類的都是本身中間件那裏搞就好了。

一般來講，這兩個方案其實均可以選用，可是我我的建議中小型公司選用 sharding-jdbc，client 層方案輕便，並且維護成本低，不須要額外增派人手，並且中小型公司系統複雜度會低一些，項目也沒那麼多；可是中大型公司最好仍是選用 mycat 這類 proxy 層方案，由於可能大公司系統和項目很是多，團隊很大，人員充足，那麼最好是專門弄我的來研究和維護 mycat，而後大量項目直接透明使用便可。

3.三、大傢俱體是如何對數據庫如何進行垂直拆分或水平拆分的？

水平拆分的意思，就是把一個表的數據給弄到多個庫的多個表裏去，可是每一個庫的表結構都同樣，只不過每一個庫表放的數據是不一樣的，全部庫表的數據加起來就是所有數據。水平拆分的意義，就是將數據均勻放更多的庫裏，而後用多個庫來扛更高的併發，還有就是用多個庫的存儲容量來進行擴容。

垂直拆分的意思，就是把一個有不少字段的表給拆分紅多個表，或者是多個庫上去。每一個庫表的結構都不同，每一個庫表都包含部分字段。通常來講，會將較少的訪問頻率很高的字段放到一個表裏去，而後將較多的訪問頻率很低的字段放到另一個表裏去。由於數據庫是有緩存的，你訪問頻率高的行字段越少，就能夠在緩存裏緩存更多的行，性能就越好。這個通常在表層面作的較多一些。

這個其實挺常見的，不必定我說，你們不少同窗可能本身都作過，把一個大表拆開，訂單表、訂單支付表、訂單商品表。

還有表層面的拆分，就是分表，將一個表變成 N 個表，就是讓每一個表的數據量控制在必定範圍內，保證 SQL 的性能。不然單表數據量越大，SQL 性能就越差。通常是 200 萬行左右，不要太多，可是也得看具體你怎麼操做，也多是 500 萬，或者是 100 萬。你的SQL越複雜，就最好讓單錶行數越少。

好了，不管分庫仍是分表，上面說的那些數據庫中間件都是能夠支持的。就是基本上那些中間件能夠作到你分庫分表以後，中間件能夠根據你指定的某個字段值，好比說 userid，自動路由到對應的庫上去，而後再自動路由到對應的表裏去。

你就得考慮一下，你的項目裏該如何分庫分表？通常來講，垂直拆分，你能夠在表層面來作，對一些字段特別多的表作一下拆分；水平拆分，你能夠說是併發承載不了，或者是數據量太大，容量承載不了，你給拆了，按什麼字段來拆，你本身想好；分表，你考慮一下，你若是哪怕是拆到每一個庫裏去，併發和容量都ok了，可是每一個庫的表仍是太大了，那麼你就分表，將這個表分開，保證每一個表的數據量並非很大。

並且這兒還有兩種分庫分表的方式：

一種是按照 range 來分，就是每一個庫一段連續的數據，這個通常是按好比時間範圍來的，可是這種通常較少用，由於很容易產生熱點問題，大量的流量都打在最新的數據上了。
或者是按照某個字段 hash 一下均勻分散，這個較爲經常使用。

range 來分，好處在於說，擴容的時候很簡單，由於你只要預備好，給每月都準備一個庫就能夠了，到了一個新的月份的時候，天然而然，就會寫新的庫了；缺點，可是大部分的請求，都是訪問最新的數據。實際生產用 range，要看場景。

hash 分發，好處在於說，能夠平均分配每一個庫的數據量和請求壓力；壞處在於說擴容起來比較麻煩，會有一個數據遷移的過程，以前的數據須要從新計算 hash 值從新分配到不一樣的庫或表。

四：總結

分佈式數據庫（中間件）的特色就是分庫分表，這個比較靈活和容易理解，使用場景最廣。 SQL可否將該分佈式數據庫的性能能力都發揮出來，取決於SQL的寫法，通常跟拆分鍵的行爲有關。不一樣分佈式數據庫產品的功能有細節上的差異，可是分庫分表的邏輯基本相同，因此上面的分析一樣適用於其餘分佈式數據庫（中間件）產品。

我的總結，若有表達不當之處歡迎指正。