首頁>Club>
4
回覆列表
  • 1 # 小沐Vlog

    一、基本概念

    二、資料庫架構設計思路

    (1)可用性

    (2)讀效能

    (3)一致性

    (4)擴充套件性

    一、基本概念

    概念一“單庫”

    概念二“分片”

    分片解決的是“資料量太大”的問題,也就是通常說的“水平切分”。

    一旦引入分片,勢必有“資料路由”的概念,哪個資料訪問哪個庫。

    路由規則通常有3種方法:

    (1)範圍:range

    優點:簡單,容易擴充套件

    缺點:各庫壓力不均(新號段更活躍)

    (2)雜湊:hash

    優點:簡單,資料均衡,負載均勻

    缺點:遷移麻煩(2庫擴3庫資料要遷移)

    (3)路由服務:router-config-server

    優點:靈活性強,業務與路由演算法解耦

    缺點:每次訪問資料庫前多一次查詢

    大部分網際網路公司採用的方案二:雜湊分庫,雜湊路由

    概念三“分組”

    分組解決“可用性”問題,分組通常透過主從複製的方式實現。

    網際網路公司資料庫實際軟體架構是:又分片,又分組(如下圖)

    二、資料庫架構設計思路

    資料庫軟體架構師平時設計些什麼東西呢?至少要考慮以下四點:

    (1)如何保證資料可用性

    (2)如何提高資料庫讀效能(大部分應用讀多寫少,讀會先成為瓶頸)

    (3)如何保證一致性

    (4)如何提高擴充套件性

    2.1如何保證資料的可用性?

    解決可用性問題的思路是=>冗餘

    如何保證站點的可用性?複製站點,冗餘站點

    如何保證服務的可用性?複製服務,冗餘服務

    如何保證資料的可用性?複製資料,冗餘資料

    資料的冗餘,會帶來一個副作用=>引發一致性問題(先不說一致性問題,先說可用性)

    如何保證資料庫“讀”高可用?

    冗餘讀庫

    冗餘讀庫帶來的副作用?讀寫有延時,可能不一致

    上面這個圖是很多網際網路公司mysql的架構,寫仍然是單點,不能保證寫高可用。

    如何保證資料庫“寫”高可用?

    冗餘寫庫

    採用雙主互備的方式,可以冗餘寫庫

    帶來的副作用?雙寫同步,資料可能衝突(例如“自增id”同步衝突),如何解決同步衝突,有兩種常見解決方案:

    (1)兩個寫庫使用不同的初始值,相同的步長來增加id:1寫庫的id為0,2,4,6...;2寫庫的id為1,3,5,7…

    (2)不使用資料的id,業務層自己生成唯一的id,保證資料不衝突

    58同城沒有使用上述兩種架構來做讀寫的“高可用”,58同城採用的是“雙主當主從用”的方式:

    仍是雙主,但只有一個主提供服務(讀+寫),另一個主是“shadow-master”,只用來保證高可用,平時不提供服務。

    master掛了,shadow-master頂上(vip漂移,對業務層透明,不需要人工介入)

    這種方式的好處:

    1)讀寫沒有延時

    2)讀寫高可用

    不足:

    1)不能透過加從庫的方式擴充套件讀效能

    2)資源利用率為50%,一臺冗餘主沒有提供服務

    那如何提高讀效能呢?進入第二個話題,如何提供讀效能。

    2.2如何擴充套件讀效能?

    提高讀效能的方式大致有三種,第一種是建立索引。這種方式不展開,要提到的一點是,不同的庫可以建立不同的索引。

    寫庫不建立索引;

    線上讀庫建立線上訪問索引,例如uid;

    線下讀庫建立線下訪問索引,例如time;

    第二種擴充讀效能的方式是,增加從庫,這種方法大家用的比較多,但是,存在兩個缺點:

    (1)從庫越多,同步越慢

    (2)同步越慢,資料不一致視窗越大(不一致後面說,還是先說讀效能的提高)

    58同城沒有采用這種方法提高資料庫讀效能(沒有從庫),採用的是增加快取。常見的快取架構如下:

    上游是業務應用,下游是主庫,從庫(讀寫分離),快取。

    58同城的玩法是:服務+資料庫+快取一套

    業務層不直接面向db和cache,服務層遮蔽了底層db、cache的複雜性。為什麼要引入服務層,今天不展開,58採用了“服務+資料庫+快取一套”的方式提供資料訪問,用cache提高讀效能。

    不管採用主從的方式擴充套件讀效能,還是快取的方式擴充套件讀效能,資料都要複製多份(主+從,db+cache),一定會引發一致性問題。

    2.3如何保證一致性?

    主從資料庫的一致性,通常有兩種解決方案:

    (1)中介軟體

    如果某一個key有寫操作,在不一致時間視窗內,中介軟體會將這個key的讀操作也路由到主庫上。

    這個方案的缺點是,資料庫中介軟體的門檻較高(百度,騰訊,阿里,360等一些公司有,當然58也有)

    (2)強制讀主

    58的“雙主當主從用”的架構,不存在主從不一致的問題。

    第二類不一致,是db與快取間的不一致

    常見的快取架構如上,此時寫操作的順序是:

    (1)淘汰cache

    (2)寫資料庫

    讀操作的順序是:

    (1)讀cache,如果cache hit則返回

    (2)如果cache miss,則讀從庫

    (3)讀從庫後,將資料放回cache

    在一些異常時序情況下,有可能從【從庫讀到舊資料(同步還沒有完成),舊資料入cache後】,資料會長期不一致。

    解決辦法是“快取雙淘汰”,寫操作時序升級為:

    (1)淘汰cache

    (2)寫資料庫

    (3)在經驗“主從同步延時視窗時間”後,再次發起一個非同步淘汰cache的請求

    這樣,即使有髒資料如cache,一個小的時間視窗之後,髒資料還是會被淘汰。帶來的代價是,多引入一次讀miss(成本可以忽略)。

    除此之外,58同城的最佳實踐之一是:建議為所有cache中的item設定一個超時時間。

    說完一致性,最後一個話題是擴充套件性。

    2.4如何提高資料庫的擴充套件性?

    原來用hash的方式路由,分為2個庫,資料量還是太大,要分為3個庫,勢必需要進行資料遷移,58同城有一個很帥氣的“資料庫秒級擴容”方案。

    如何秒級擴容?

    首先,我們不做2庫變3庫的擴容,我們做2庫變4庫(庫加倍)的擴容(未來4->8->16)

    服務+資料庫是一套(省去了快取)

    資料庫採用“雙主”的模式。

    擴容步驟:

    第一步,將一個主庫提升

    第二步,修改配置,2庫變4庫(原來MOD2,現在配置修改後MOD4)

    擴容完成

    原MOD2為偶的部分,現在會MOD4餘0或者2

    原MOD2為奇的部分,現在會MOD4餘1或者3

    資料不需要遷移,同時,雙主互相同步,一遍是餘0,一邊餘2,兩邊資料同步也不會衝突,秒級完成擴容!

    最後,要做一些收尾工作:

    (1)將舊的雙主同步解除

    (2)增加新的雙主(雙主是保證可用性的,shadow-master平時不提供服務)

    這樣,秒級別內,我們就完成了2庫變4庫的擴充套件。

    OK,今天主要分享了58同城,資料庫軟體架構上:

    (1)如何保證資料可用性

    (2)如何提高資料庫讀效能

    (3)如何保證資料一致性

    (4)如何進行秒級擴容

  • 2 # 水西哥

    ( 1 ) 將概念結構轉換為一般的關係、網狀、層次模型;

    ( 2 ) 將轉換來的關係、網狀、層次模型向指定資料庫管理系統支援的資料模型轉換;

    ( 3 ) 對資料模型進行最佳化。

  • 中秋節和大豐收的關聯?
  • 五指毛桃燉湯要多久?