亚洲综合小说另类图片

<dfn id="4z7un"><s id="4z7un"></s></dfn>
          1. <nav id="4z7un"><sup id="4z7un"></sup></nav>
            <th id="4z7un"></th>

          2. <output id="4z7un"><small id="4z7un"><input id="4z7un"></input></small></output>
            八周年活動月
            歡迎訪問長沙友點軟件科技有限公司旗下產品友點CMS官方網站!
            友點CMS

            關注互聯網后端技術-MySQL在大型網站的應用架構演變

            來源:友點CMS 日期:2015-01-06 18:30:40 屬于:數據庫

            雖然許多人不滿意MySQL被Oracle收購后的發展進度,但是該開源數據庫被應用的廣泛程度仍然不容質疑。然而開源到大型企業應用必然存在著很多的技術挑戰,這里我們一起看不同并發訪問量級下,Mysql架構的演變。

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

            以下為博文:

            寫在最前:

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

            可擴展性

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

            • Scale-up:縱向擴展,通過替換為更好的機器和資源來實現伸縮,提升服務能力
            • Scale-out:橫向擴展,  通過加節點(機器)來實現伸縮,提升服務能力

            可擴展性的理想狀態 

            一個服務,當面臨更高的并發的時候,能夠通過簡單增加機器來提升服務支撐的并發度,且增加機器過程中對線上服務無影響(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"??膳渲眯院投嘤脩舸鎯Y構設計在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 ?等待革命……

            淘寶用例

            • 淘寶RDS 云數據庫設計:http://blog.csdn.net/ywh147/article/details/8954625  
            • http://www.infoq.com/cn/news/2012/10/taobao-ump

            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

            亚洲综合小说另类图片
            <dfn id="4z7un"><s id="4z7un"></s></dfn>
                    1. <nav id="4z7un"><sup id="4z7un"></sup></nav>
                      <th id="4z7un"></th>

                    2. <output id="4z7un"><small id="4z7un"><input id="4z7un"></input></small></output>