分庫分表在設計高併發系統的作用?不同的分庫分表中間件都有什麼優點和缺點?如何對數據庫如何進行垂直拆分或水平拆分的?

分庫分表在設計高併發系統的作用?不同的分庫分表中間件都有什麼優點和缺點?如何對數據庫如何進行垂直拆分或水平拆分的?

 

面試題

爲什麼要分庫分表(設計高併發系統的時候,數據庫層面該如何設計)?用過哪些分庫分表中間件?不同的分庫分表中間件都有什麼優點和缺點?你們具體是如何對數據庫如何進行垂直拆分或水平拆分的?

面試官心理分析

其實這塊肯定是扯到高併發了,因爲分庫分表一定是爲了支撐高併發、數據量大兩個問題的。而且現在說實話,尤其是互聯網類的公司面試,基本上都會來這麼一下,分庫分表如此普遍的技術問題,不問實在是不行,而如果你不知道那也實在是說不過去!

面試題剖析

爲什麼要分庫分表?(設計高併發系統的時候,數據庫層面該如何設計?)

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

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

假如我們現在是一個小創業公司(或者是一個 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 左右,不要太大。那麼你可以將一個庫的數據拆分到多個庫中,訪問的時候就訪問一個庫好了。

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

# 分庫分表前 分庫分表後
併發支撐情況 MySQL 單機部署,扛不住高併發 MySQL從單機到多機,能承受的併發增加了多倍
磁盤使用情況 MySQL 單機磁盤容量幾乎撐滿 拆分爲多個庫,數據庫服務器磁盤使用率大大降低
SQL 執行性能 單表數據量太大,SQL 越跑越慢 單表數據量減少,SQL 執行效率明顯提升

用過哪些分庫分表中間件?不同的分庫分表中間件都有什麼優點和缺點?

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

比較常見的包括:

  • cobar
  • TDDL
  • atlas
  • sharding-jdbc
  • mycat

cobar

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

TDDL

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

atlas

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

sharding-jdbc

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

mycat

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

總結

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

sharding-jdbc 這種 client 層方案的優點在於不用部署,運維成本低,不需要代理層的二次轉發請求,性能很高,但是如果遇到升級啥的需要各個系統都重新升級版本再發布,各個系統都需要耦合 sharding-jdbc 的依賴;

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

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

你們具體是如何對數據庫如何進行垂直拆分或水平拆分的?

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

 

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

 

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

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

好了,無論分庫還是分表,上面說的那些數據庫中間件都是可以支持的。就是基本上那些中間件可以做到你分庫分表之後,中間件可以根據你指定的某個字段值,比如說 userid,自動路由到對應的庫上去,然後再自動路由到對應的表裏去

你就得考慮一下,你的項目裏該如何分庫分表?一般來說,垂直拆分,你可以在表層面來做,對一些字段特別多的表做一下拆分;水平拆分,你可以說是併發承載不了,或者是數據量太大,容量承載不了,你給拆了,按什麼字段來拆,你自己想好;分表,你考慮一下,你如果哪怕是拆到每個庫裏去,併發和容量都ok了,但是每個庫的表還是太大了,那麼你就分表,將這個表分開,保證每個表的數據量並不是很大。

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

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

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

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

繼續閱讀

 

來源:“創享視界”,創享視界(creativeview.cn)是一個帶動全民顛覆八小時工作制,通過投稿把自己的創意智慧變現的方式創造被動收入,從而實現財務自由的平臺。我們相信,創新思維不僅有助於打造更出色的產品,還可以讓世界變得更美好,讓人人受益。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章