首頁  >  文章  >  資料庫  >  mysql在大型網站的應用架構演變

mysql在大型網站的應用架構演變

伊谢尔伦
伊谢尔伦原創
2016-11-24 11:09:47893瀏覽

本文主要描述在網站的不同的並發訪問量級下,Mysql架構的演變

  可擴展性

  架構的可擴展性往往和並發是息息相關,沒有並發的增長,也沒有必要做高可擴展性的架構,這裡對可擴展性進行簡單介紹一下,常用的擴展手段有以下兩種

  Scale-up :  縱向擴展,透過替換為更好的機器和資源來實現伸縮,提升服務能力

  Scale -out : 橫向擴展,  透過加節點(機器)來實現伸縮,提升服務能力

  對於互聯網的高並發應用來說,無疑Scale out才是出路,透過縱向的買更高端的機器一直是我們所避諱的問題,也不是長久之計,在scale out的理論下,可擴展性的理想狀態是什麼?

  可擴展性的理想狀態

  一個服務,當面臨更高的並發的時候,能夠透過簡單增加機器來提升服務支撐的並發度,且增加機器過程中對線上服務無影響(no down time ),這就是可擴展性的理想狀態!

 架構的演變

  V1.0  簡單網站架構

  一個簡單的小型網站或者應用背後的架構可以非常簡單,  資料儲存只需要一個sqlmy instance資料備份的實例了),處於這個時間段的網站,一般會把所有的資訊存到一個database instance裡面。

mysql在大型網站的應用架構演變

在這樣的架構下,我們來看看資料儲存的瓶頸是什麼?

  1.資料量的總大小  一個機器放不下時

  2.資料的索引(B+ Tree)一個機器的內存放不下時

㟎  3.只有當以上3件事情任何一件或多件滿足時,我們才需要考慮往下一級演進。 從此我們可以看出,事實上對於許多小公司小應用,這種架構已經足夠滿足他們的需求了,初期資料量的準確評估是杜絕過度設計很重要的一環,畢竟沒有人願意為不可能發生的事情而浪費自己的經驗。

  這裡簡單舉個我的例子,對於用戶資訊這類表(3個索引),16G內存能放下大概2000W行數據的索引,簡單的讀和寫混合訪問量3000/s左右沒有問題,你的應用場景是否

  V2.0 垂直分割

  一般當V1.0 遇到瓶頸時,首先最簡單的拆分方法就是垂直拆分,何謂垂直?就是從業務角度來看,將關聯性不強的資料拆分到不同的instance上,以達到消除瓶頸的目標。以圖中的為例,將使用者資訊數據,和業務數據拆分到不同的三個實例上。對於重複讀取類型比較多的場景,我們也可以加一層cache,來減少對DB的壓力。

在這樣的架構下,我們來看看資料儲存的瓶頸是什麼? mysql在大型網站的應用架構演變

  1.單一實例單業務依然存在V1.0所述瓶頸

  遇到瓶頸時可以考慮往本文更高V版本升級, 若是讀取請求導致達到性能瓶頸可以考慮往V3.0升級, 其他瓶頸考慮往V4.0升級

  V3.0  主從架構

  此類架構主要解決V2.0架構下的讀取問題,透過給Instance掛資料即時備份的思路來遷移讀取的壓力,在Mysql的場景下就是透過主從結構,主庫抗寫壓力,透過從函式庫來分擔讀取壓力,對於寫少讀多的應用,V3.0主從架構完全能夠勝任

mysql在大型網站的應用架構演變

 在這樣的架構下,我們來看看資料儲存的瓶頸是什麼?

  1.寫入量主庫不能承受

  V4.0  水平分割

  對於V2.0 V3.0方案遇到瓶頸時,都可以透過水平分割來解決,水平分割和垂直分割來解決,水平分割和垂直分割有較大差異,垂直拆分拆完的結果,在一個實例上是擁有全量數據的,而水平拆分之後,任何實例都只有全量的1/n的數據,以下圖Userinfo的拆分為例,將userinfo拆分為3個cluster,每個cluster持有總量的1/3數據,3個cluster數據的總和等於一份完整數據(註:這裡不再叫單一實例而是叫一個cluster 代表包含主從的一個小mysql叢集)

mysql在大型網站的應用架構演變

 資料如何路由?

  1.Range拆分

  sharding key按連續區間段路由,一般用在有嚴格自增ID需求的場景上,如Userid, Userid Range的小例子:以userid 3000W 為Rangecluster userid 1-3000W  2號cluster  userid   3001W-6000W

  2.Listid   3001W-6000W

  2.Listid   3001W-6000W

  2.List

  Listuster與Range分離方法,List主要用來做sharding key不是連續區間的序列落到一個cluster的情況🎜🎜🎜🎜
陳述:
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn