mysql 在大型應用中的架構演變

時間 2019-12-09

標籤 mysql 大型應用架構演變欄目 MySQL 简体版

原文原文鏈接

文正整理自：http://www.csdn.net/article/2014-06-10/2820160html

可擴展性前端

架構的可擴展性每每和併發是息息相關，沒有併發的增加，也就沒有必要作高可擴展性的架構，這裏對可擴展性進行簡單介紹一下，經常使用的擴展手段有如下兩種：mysql

Scale-up：縱向擴展，經過替換爲更好的機器和資源來實現伸縮，提高服務能力
Scale-out：橫向擴展, 經過加節點（機器）來實現伸縮，提高服務能力

對於互聯網的高併發應用來講，無疑橫向擴展才是出路，同時經過縱向購買更高端的機器也一直是咱們所避諱的問題，也不是長久之計。那麼，在橫向擴展的理論下，可擴展性的理想狀態是什麼？算法

可擴展性的理想狀態sql

一個服務，當面臨更高的併發的時候，可以經過簡單增長機器來提高服務支撐的併發度，且增長機器過程當中對線上服務無影響（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 一拆爲二，通常的作法是：

摘下一個slave，停同步
對寫記錄增量log（實現上能夠業務方對寫操做多一次寫持久化mq或者MySQL主建立trigger記錄寫等等方式）
開始對靜態slave作數據一拆爲二
回放增量寫入，直到追上的全部增量，與原Cluster基本保持同步
寫入切換，由原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來屏蔽。

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

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

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