? ?正文? ?

?

?

面試中我們經(jīng)常會碰到的關(guān)于分庫分表的幾個面試連環(huán)炮！今天就給大家一一介紹！希望對大家面試的時候能夠有所幫助！

• 為什么要分庫分表？

• 用過哪些分庫分表中間件？

• 不同的分庫分表中間件都有什么優(yōu)點和缺點？

• 你們具體是如何對數(shù)據(jù)庫如何進行垂直拆分或水平拆分的？

?

一、面試題

為什么要分庫分表（設(shè)計高并發(fā)系統(tǒng)的時候，數(shù)據(jù)庫層面該如何設(shè)計）？用過哪些分庫分表中間件？不同的分庫分表中間件都有什么優(yōu)點和缺點？你們具體是如何對數(shù)據(jù)庫如何進行垂直拆分或水平拆分的？

?

二、面試官心理分析

其實這塊肯定是扯到高并發(fā)了，因為分庫分表一定是為了支撐高并發(fā)、數(shù)據(jù)量大兩個問題的。而且現(xiàn)在說實話，尤其是互聯(lián)網(wǎng)類的公司面試，基本上都會來這么一下，分庫分表如此普遍的技術(shù)問題，不問實在是不行，而如果你不知道那也實在是說不過去！

?

三、面試題剖析

1、為什么要分庫分表？（設(shè)計高并發(fā)系統(tǒng)的時候，數(shù)據(jù)庫層面該如何設(shè)計？）

說白了，分庫分表是兩回事兒，大家可別搞混了，可能是光分庫不分表，也可能是光分表不分庫，都有可能。

我先給大家拋出來一個場景。

假如我們現(xiàn)在是一個小創(chuàng)業(yè)公司（或者是一個 BAT 公司剛興起的一個新部門），現(xiàn)在注冊用戶就 20 萬，每天活躍用戶就 1 萬，每天單表數(shù)據(jù)量就 1000，然后高峰期每秒鐘并發(fā)請求最多就 10。天，就這種系統(tǒng)，隨便找一個有幾年工作經(jīng)驗的，然后帶幾個剛培訓(xùn)出來的，隨便干干都可以。

結(jié)果沒想到我們運氣居然這么好，碰上個 CEO 帶著我們走上了康莊大道，業(yè)務(wù)發(fā)展迅猛，過了幾個月，注冊用戶數(shù)達到了 2000 萬！每天活躍用戶數(shù) 100 萬！每天單表數(shù)據(jù)量 10 萬條！高峰期每秒最大請求達到 1000！同時公司還順帶著融資了兩輪，進賬了幾個億人民幣啊！公司估值達到了驚人的幾億美金！這是小獨角獸的節(jié)奏！

好吧，沒事，現(xiàn)在大家感覺壓力已經(jīng)有點大了，為啥呢？因為每天多 10 萬條數(shù)據(jù)，一個月就多 300 萬條數(shù)據(jù)，現(xiàn)在咱們單表已經(jīng)幾百萬數(shù)據(jù)了，馬上就破千萬了。但是勉強還能撐著。高峰期請求現(xiàn)在是 1000，咱們線上部署了幾臺機器，負載均衡搞了一下，數(shù)據(jù)庫撐 1000QPS 也還湊合。但是大家現(xiàn)在開始感覺有點擔(dān)心了，接下來咋整呢......

再接下來幾個月，我的天，CEO 太牛逼了，公司用戶數(shù)已經(jīng)達到 1 億，公司繼續(xù)融資幾十億人民幣啊！公司估值達到了驚人的幾十億美金，成為了國內(nèi)今年最牛逼的明星創(chuàng)業(yè)公司！天，我們太幸運了。

但是我們同時也是不幸的，因為此時每天活躍用戶數(shù)上千萬，每天單表新增數(shù)據(jù)多達 50 萬，目前一個表總數(shù)據(jù)量都已經(jīng)達到了兩三千萬了！扛不住啊！數(shù)據(jù)庫磁盤容量不斷消耗掉！高峰期并發(fā)達到驚人的 5000~8000！別開玩笑了，哥。我跟你保證，你的系統(tǒng)支撐不到現(xiàn)在，已經(jīng)掛掉了！

好吧，所以你看到這里差不多就理解分庫分表是怎么回事兒了，實際上這是跟著你的公司業(yè)務(wù)發(fā)展走的，你公司業(yè)務(wù)發(fā)展越好，用戶就越多，數(shù)據(jù)量越大，請求量越大，那你單個數(shù)據(jù)庫一定扛不住。

?

分表

比如你單表都幾千萬數(shù)據(jù)了，你確定你能扛住么？絕對不行，單表數(shù)據(jù)量太大，會極大影響你的 sql 執(zhí)行的性能，到了后面你的 sql 可能就跑的很慢了。一般來說，就以我的經(jīng)驗來看，單表到幾百萬的時候，性能就會相對差一些了，你就得分表了。

分表是啥意思？就是把一個表的數(shù)據(jù)放到多個表中，然后查詢的時候你就查一個表。比如按照用戶 id 來分表，將一個用戶的數(shù)據(jù)就放在一個表中。然后操作的時候你對一個用戶就操作那個表就好了。這樣可以控制每個表的數(shù)據(jù)量在可控的范圍內(nèi)，比如每個表就固定在 200 萬以內(nèi)。

?

分庫

分庫是啥意思？就是你一個庫一般我們經(jīng)驗而言，最多支撐到并發(fā) 2000，一定要擴容了，而且一個健康的單庫并發(fā)值你最好保持在每秒 1000 左右，不要太大。那么你可以將一個庫的數(shù)據(jù)拆分到多個庫中，訪問的時候就訪問一個庫好了。

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

?

2、用過哪些分庫分表中間件？不同的分庫分表中間件都有什么優(yōu)點和缺點？

這個其實就是看看你了解哪些分庫分表的中間件，各個中間件的優(yōu)缺點是啥？然后你用過哪些分庫分表的中間件。

比較常見的包括：

• cobar

• TDDL

• atlas

• sharding-jdbc

• mycat

cobar

阿里 b2b 團隊開發(fā)和開源的，屬于 proxy 層方案，就是介于應(yīng)用服務(wù)器和數(shù)據(jù)庫服務(wù)器之間。應(yīng)用程序通過 JDBC 驅(qū)動訪問 cobar 集群，cobar 根據(jù) SQL 和分庫規(guī)則對 SQL 做分解，然后分發(fā)到 MySQL 集群不同的數(shù)據(jù)庫實例上執(zhí)行。早些年還可以用，但是最近幾年都沒更新了，基本沒啥人用，差不多算是被拋棄的狀態(tài)吧。而且不支持讀寫分離、存儲過程、跨庫 join 和分頁等操作。

TDDL

淘寶團隊開發(fā)的，屬于 client 層方案。支持基本的 crud 語法和讀寫分離，但不支持 join、多表查詢等語法。目前使用的也不多，因為還依賴淘寶的 diamond 配置管理系統(tǒng)。

atlas

360 開源的，屬于 proxy 層方案，以前是有一些公司在用的，但是確實有一個很大的問題就是社區(qū)最新的維護都在 5 年前了。所以，現(xiàn)在用的公司基本也很少了。

sharding-jdbc

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

mycat

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

?

總結(jié)

綜上，現(xiàn)在其實建議考量的，就是 sharding-jdbc 和 mycat，這兩個都可以去考慮使用。

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

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

通常來說，這兩個方案其實都可以選用，但是我個人建議中小型公司選用 sharding-jdbc，client 層方案輕便，而且維護成本低，不需要額外增派人手，而且中小型公司系統(tǒng)復(fù)雜度會低一些，項目也沒那么多；但是中大型公司最好還是選用 mycat 這類 proxy 層方案，因為可能大公司系統(tǒng)和項目非常多，團隊很大，人員充足，那么最好是專門弄個人來研究和維護 mycat，然后大量項目直接透明使用即可。

?

3、你們具體是如何對數(shù)據(jù)庫如何進行垂直拆分或水平拆分的？

水平拆分的意思，就是把一個表的數(shù)據(jù)給弄到多個庫的多個表里去，但是每個庫的表結(jié)構(gòu)都一樣，只不過每個庫表放的數(shù)據(jù)是不同的，所有庫表的數(shù)據(jù)加起來就是全部數(shù)據(jù)。水平拆分的意義，就是將數(shù)據(jù)均勻放更多的庫里，然后用多個庫來扛更高的并發(fā)，還有就是用多個庫的存儲容量來進行擴容。

垂直拆分的意思，就是把一個有很多字段的表給拆分成多個表，或者是多個庫上去。每個庫表的結(jié)構(gòu)都不一樣，每個庫表都包含部分字段。一般來說，會將較少的訪問頻率很高的字段放到一個表里去，然后將較多的訪問頻率很低的字段放到另外一個表里去。因為數(shù)據(jù)庫是有緩存的，你訪問頻率高的行字段越少，就可以在緩存里緩存更多的行，性能就越好。這個一般在表層面做的較多一些。

這個其實挺常見的，不一定我說，大家很多同學(xué)可能自己都做過，把一個大表拆開，訂單表、訂單支付表、訂單商品表。

還有表層面的拆分，就是分表，將一個表變成 N 個表，就是讓每個表的數(shù)據(jù)量控制在一定范圍內(nèi)，保證 SQL 的性能。否則單表數(shù)據(jù)量越大，SQL 性能就越差。一般是 200 萬行左右，不要太多，但是也得看具體你怎么操作，也可能是 500 萬，或者是 100 萬。你的SQL越復(fù)雜，就最好讓單表行數(shù)越少。

好了，無論分庫還是分表，上面說的那些數(shù)據(jù)庫中間件都是可以支持的。就是基本上那些中間件可以做到你分庫分表之后，中間件可以根據(jù)你指定的某個字段值，比如說 userid，自動路由到對應(yīng)的庫上去，然后再自動路由到對應(yīng)的表里去。

你就得考慮一下，你的項目里該如何分庫分表？一般來說，垂直拆分，你可以在表層面來做，對一些字段特別多的表做一下拆分；水平拆分，你可以說是并發(fā)承載不了，或者是數(shù)據(jù)量太大，容量承載不了，你給拆了，按什么字段來拆，你自己想好；分表，你考慮一下，你如果哪怕是拆到每個庫里去，并發(fā)和容量都o(jì)k了，但是每個庫的表還是太大了，那么你就分表，將這個表分開，保證每個表的數(shù)據(jù)量并不是很大。

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

• 一種是按照 range 來分，就是每個庫一段連續(xù)的數(shù)據(jù)，這個一般是按比如時間范圍來的，但是這種一般較少用，因為很容易產(chǎn)生熱點問題，大量的流量都打在最新的數(shù)據(jù)上了。

• 或者是按照某個字段 hash 一下均勻分散，這個較為常用。

range 來分，好處在于說，擴容的時候很簡單，因為你只要預(yù)備好，給每個月都準(zhǔn)備一個庫就可以了，到了一個新的月份的時候，自然而然，就會寫新的庫了；缺點，但是大部分的請求，都是訪問最新的數(shù)據(jù)。實際生產(chǎn)用 range，要看場景。

hash 分發(fā)，好處在于說，可以平均分配每個庫的數(shù)據(jù)量和請求壓力；壞處在于說擴容起來比較麻煩，會有一個數(shù)據(jù)遷移的過程，之前的數(shù)據(jù)需要重新計算 hash。值重新分配到不同的庫或表。

總結(jié)

以上是生活随笔為你收集整理的为什么要分库分表？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。