面試官:“談談分庫分表吧”

引言

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

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

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

那麼回事。


一、為什麼要分庫分表

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

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

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

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


二、如何分庫分表

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

據庫整體性能。核心理念就是對數據進行切分(Sharding),以及切分後如何對數據的快速定位與整合。

針對數據切分類型,大致可以分為:垂直(縱向)切分和水平(橫向)切分兩種。

1、垂直切分

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

垂直分庫

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

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

據庫,這個比較好理解。

面試官:“談談分庫分表吧”

垂直分表

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

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

order表:


面試官:“談談分庫分表吧”


拆分後


面試官:“談談分庫分表吧”


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

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

優點:

  • 業務間解耦,不同業務的數據進行獨立的維護、監控、擴展
  • 在高併發場景下,一定程度上緩解了數據庫的壓力

缺點:

  • 提升了開發的複雜度,由於業務的隔離性,很多表無法直接訪問,必須通過接口方式聚合數據,
  • 分佈式事務管理難度增加
  • 數據庫還是存在單表數據量過大的問題,並未根本上解決,需要配合水平切分

2、水平切分

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

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

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

order_1表:

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

庫內分表

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

面試官:“談談分庫分表吧”

分庫分表

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

優點:

  • 解決高併發時單庫數據量過大的問題,提升系統穩定性和負載能力
  • 業務系統改造的工作量不是很大

缺點:

  • 跨分片的事務一致性難以保證
  • 跨庫的join關聯查詢性能較差
  • 擴容的難度和維護量較大,(拆分成幾千張子表想想都恐怖)

三、數據該往哪個庫的表存?

分庫分表以後會出現一個問題,一張表會出現在多個數據庫裡,到底該往哪個庫的表裡存呢?

1、根據取值範圍

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

優點:

  • 單表數據量是可控的
  • 水平擴展簡單隻需增加節點即可,無需對其他分片的數據進行遷移
  • 能快速定位要查詢的數據在哪個庫

缺點:

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

2、hash取模

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,用戶信息可能就不再在同一個庫中。

四、分庫分表後會有哪些坑?


1、事務一致性問題

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

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


2、分頁、排序的坑

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

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

3、全局唯一主鍵問題

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

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

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


五、分庫分表工具?

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

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

  • sharding-jdbc(噹噹)
  • TSharding(蘑菇街)
  • Atlas(奇虎360)
  • Cobar(阿里巴巴)
  • MyCAT(基於Cobar)
  • Oceanus(58同城) Vitess(谷歌)


分享到:


相關文章: