關注網際網路後端技術-MySQL在大型網站的應用架構演變

edithfang發表於2014-06-18
後端MySql網站應用架構

作為最流行的開源資料庫，MySQL被廣泛應用在Web應用程式以及其它中小型專案上。然而不可忽視的是，在許多大型IT公司中，MySQL在高度優化和定製化後，已逐漸偏離了原有的開源版本，更像是一種分支，比如Facebook前不久開源的WebScaleSQL。近日，有一篇博文，從大型網站架構發展的角度看MySQL應用所發生的改變，這裡為大家分享。

以下為博文：

寫在最前： 

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

可擴充套件性

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

  • Scale-up：縱向擴充套件，通過替換為更好的機器和資源來實現伸縮，提升服務能力
  • Scale-out：橫向擴充套件,  通過加節點（機器）來實現伸縮，提升服務能力

可擴充套件性的理想狀態 關注網際網路後端技術-MySQL在大型網站的應用架構演變

一個服務，當面臨更高的併發的時候，能夠通過簡單增加機器來提升服務支撐的併發度，且增加機器過程中對線上服務無影響（no down time），這就是可擴充套件性的理想狀態！架構的演變V1.0  簡單網站架構一個簡單的小型網站或者應用背後的架構可以非常簡單，資料儲存只需要一個Mysql Instance就能滿足資料讀取和寫入需求（這裡忽略掉了資料備份的例項），處於這個時間段的網站，一般會把所有的資訊存到一個Database Instance裡面。

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

  • 資料量的總大小  一個機器放不下
  • 資料的索引（B+ Tree）一個機器的記憶體放不下 
  • 訪問量（讀寫混合）一個例項不能承受

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

這裡簡單舉個我的例子，對於使用者資訊這類表 （3個索引），16G記憶體能放下，大概2000萬行資料的索引，簡單的讀和寫混合訪問量3000/s左右沒有問題，你的應用場景是否？

V2.0 垂直拆分

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


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

單例項單業務依然存在V1.0所述瓶頸：遇到瓶頸時可以考慮往本文更高V版本升級，若是讀請求導致達到效能瓶頸可以考慮往V3.0升級， 其他瓶頸考慮往V4.0升級。

V3.0  主從架構

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


在這樣的架構下，我們來看看資料儲存的瓶頸是什麼？很明瞭，寫入量主庫不能承受。

V4.0  水平拆分

對於V2.0、V3.0方案遇到瓶頸時，都可以通過水平拆分來解決，水平拆分和垂直拆分有較大區別，垂直拆分拆完的結果，在一個例項上是擁有全量資料的，而水平拆分之後，任何例項都只有全量的1/n的資料，以下圖UserInfo的拆分為例，將UserInfo拆分為3個Cluster，每個Cluster持有總量的1/3資料，3個Cluster資料的總和等於一份完整資料。

注：這裡不再叫單個例項 而是叫一個Cluster 代表包含主從的一個小MySQL叢集。


那麼，這樣架構中的資料該如何路由？

1. Range拆分

sharding key按連續區間段路由，一般用在有嚴格自增ID需求的場景上，如UserId、UserId Range的小例子，以UserId 3000萬為Range進行拆分：1號Cluster的UserId是1-3000萬，2號Cluster  UserId是 3001萬-6000萬。

2. List拆分

List拆分與Range拆分思路一樣，都是通過給不同的sharding key來路由到不同的Cluster，但是具體方法有些不同。List主要用來做sharding key不是連續區間的序列落到一個Cluster的情況，如以下場景：

假定有20個音像店，分佈在4個有經銷權的地區，如下表所示： 

地區   商店ID 號 
北區   3, 5, 6, 9, 17 
東區   1, 2, 10, 11, 19, 20 
西區   4, 12, 13, 14, 18 
中心區 7, 8, 15, 16

業務希望能夠把一個地區的所有資料組織到一起來搜尋，這種場景List拆分可以輕鬆搞定

3. Hash拆分

通過對sharding key 進行雜湊的方式來進行拆分，常用的雜湊方法有除餘，字串雜湊等等，除餘如按UserId%n的值來決定資料讀寫哪個Cluster，其他雜湊類演算法這裡就不細展開講了。

4. 資料拆分後引入的問題

資料水平拆分引入的問題主要是隻能通過sharding key來讀寫操作，例如以UserId為sharding key的切分例子，讀UserId的詳細資訊時，一定需要先知道UserId，這樣才能推算出在哪個Cluster進而進行查詢，假設我需要按UserName進行檢索使用者資訊，需要引入額外的反向索引機制（類似HBase二級索引），如在Redis上儲存username->userid的對映，以UserName查詢的例子變成了先通過查詢username->userid，再通過userid查詢相應的資訊。

實際上這個做法很簡單，但是我們不要忽略了一個額外的隱患，那就是資料不一致的隱患。儲存在Redis裡的username->userid和儲存在MySQL裡的userid->username必須需要是一致的，這個保證起來很多時候是一件比較困難的事情，舉個例子來說，對於修改使用者名稱這個場景，你需要同時修改Redis和Mysql。這兩個東西是很難做到事務保證的，如MySQL操作成功，但是Redis卻操作失敗了（分散式事務引入成本較高）。對於網際網路應用來說，可用性是最重要的，一致性是其次，所以能夠容忍小量的不一致出現. 畢竟從佔比來說，這類的不一致的比例可以微乎其微到忽略不計。（一般寫更新也會採用mq來保證直到成功為止才停止重試操作）

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

在這個拆分理念上搭建起來的架構，理論上不存在瓶頸（sharding key能確保各Cluster流量相對均衡的前提下)。不過確有一件噁心的事情，那就是Cluster擴容的時候重做資料的成本，如我原來有3個Cluster，但是現在我的資料增長比較快，我需要6個Cluster，那麼我們需要將每個Cluster 一拆為二，一般的做法是：

  1. 摘下一個slave，停同步
  2. 對寫記錄增量log（實現上可以業務方對寫操作多一次寫持久化mq或者MySQL主建立trigger記錄寫等等方式）
  3. 開始對靜態slave做資料一拆為二
  4. 回放增量寫入，直到追上的所有增量，與原Cluster基本保持同步
  5. 寫入切換，由原3 Cluster 切換為6 Cluster

有沒有類似飛機空中加油的感覺，這是一個髒活，累活，容易出問題的活，為了避免這個，我們一般在最開始的時候，設計足夠多的sharding cluster來防止可能的Cluster擴容這件事情。

V5.0  雲端計算 騰飛（雲資料庫）

雲端計算現在是各大IT公司內部作為節約成本的一個突破口，對於資料儲存的MySQL來說，如何讓其成為一個SaaS是關鍵點。在MS的官方文件中，把構建一個足夠成熟的SaaS（MS簡單列出了SAAS應用的4級成熟度）所面臨的3個主要挑戰：可配置性，可擴充套件性，多使用者儲存結構設計稱為"three headed monster"。可配置性和多使用者儲存結構設計在MySQL SaaS這個問題中並不是特別難辦的一件事情，所以這裡重點說一下可擴充套件性。

MySQL作為一個SaaS服務，在架構演變為V4.0之後，依賴良好的sharding key設計，已經不再存在擴充套件性問題，只是他在面對擴容縮容時，有一些髒活需要幹，而作為SaaS，並不能避免擴容縮容這個問題，所以只要能把V4.0的髒活變成：第1，擴容縮容對前端APP透明（業務程式碼不需要任何改動）；第2，擴容縮容全自動化且對線上服務無影響。如果實現了這兩點，那麼他就拿到了作為SaaS的門票。

對於架構實現的關鍵點，需要滿足對業務透明，擴容縮容對業務不需要任何改動，那麼就必須eat our own dog food，在你MySQL SaaS內部解決這個問題，一般的做法是我們需要引入一個Proxy，Proxy來解析SQL協議，按sharding key來尋找Cluster，判斷是讀操作還是寫操作來請求Master或者Slave，這一切內部的細節都由Proxy來遮蔽。

這裡借淘寶的圖來列舉一下Proxy需要幹哪些事情

對於架構實現的關鍵點，擴容縮容全自動化且對線上服務無影響； 擴容縮容對應到的資料操作即為資料拆分和資料合併，要做到完全自動化有非常多不同的實現方式，總體思路和V4.0介紹的瓶頸部分有關，目前來看這個問題比較好的方案就是實現一個偽裝Slave的Sync Slave，解析MySQL同步協議，然後實現資料拆分邏輯，把全量資料進行拆分。具體架構見下圖：


其中Sync Slave對於Original Master來說，和一個普通的Mysql Slave沒有任何區別，也不需要任何額外的區分對待。需要擴容/縮容時，掛上一個Sync slave，開始全量同步+增量同步，等待一段時間追資料。以擴容為例，若擴容後的服務和擴容前資料已經基本同步了，這時候如何做到切換對業務無影響？ 其實關鍵點還是在引入的Proxy，這個問題轉換為了如何讓Proxy做熱切換後端的問題。這已經變成一個非常好處理的問題了。

另外值得關注的是：2014年5月28日——為了滿足當下對Web及雲應用需求，甲骨文宣佈推出MySQL Fabric，在對應的資料部分我也放了很多Fabric的資料，有興趣的可以看看，說不定會是以後的一個解決雲資料庫擴容縮容的手段。

V more ?等待革命……

淘寶用例

Mysql  Fabric

http://mysqlmusings.blogspot.jp/2013/09/brief-introduction-to-mysql-fabric.html

http://vnwrites.blogspot.jp/2013/09/mysqlfabric-sharding-introduction.html

http://vnwrites.blogspot.in/2013/09/mysqlfabric-sharding-example.html

http://vnwrites.blogspot.in/2013/09/mysqlfabric-sharding-migration.html

http://vnwrites.blogspot.jp/2013/09/mysqlfabric-sharding-maintenance.html

本文轉載自：http://www.cnblogs.com/Creator/p/3776110.html

WEB MYSQL
評論(0)

相關文章