MySQL的使用非常普遍衷模，跟MySQL有關(guān)的話題也非常多鹊汛，如性能優(yōu)化蒲赂、高可用性、強一致性刁憋、安全滥嘴、備份、集群至耻、橫向擴展若皱、縱向擴展、負載均衡尘颓、讀寫分離等走触。要想掌握其中的精髓，可得花費不少功力疤苹，雖然目前流行的MySQL替代方案有很多互广，可是從最小成本最容易維護的角度而言，MySQL還是首選。

下面從應(yīng)用場景的角度切入惫皱，對MySQL的技術(shù)點進行組織像樊，寫一份知識圖譜，方便進行更深入的學(xué)習(xí)和總結(jié)旅敷。

如下圖整理生棍，我試著把MySQL的應(yīng)用場景分為6種，每種場景下需要考慮的重點問題不一樣媳谁，從而引出不同問題點下需要補齊的知識點涂滴，后續(xù)繼續(xù)基于這些知識點進行學(xué)習(xí)和整理。

一晴音、單Master

單Master的情況是普遍存在的氢妈，對于很多個人站點、初創(chuàng)公司段多、小型內(nèi)部系統(tǒng)首量，考慮到成本、更新頻率进苍、系統(tǒng)重要性等問題加缘，系統(tǒng)只依賴一個單例數(shù)據(jù)庫提供服務(wù)，基本上已經(jīng)滿足需求觉啊。這種場景下我覺得重點應(yīng)該關(guān)注的話題有上圖所示的四點拣宏。

其中最重要的環(huán)節(jié)是數(shù)據(jù)備份，如果是交易量非常低杠人，并且具有非常明確的服務(wù)時間段特性的話勋乾，簡單的mysqldump是可以勝任的。但是這是有缺陷的嗡善，數(shù)據(jù)還原之后注定從備份點到還原點之間的數(shù)據(jù)會丟失辑莫。然而在極多數(shù)的情況下，備份的工作是沒法馬虎的罩引，如下列舉的幾點小細節(jié)各吨，下學(xué)期將分享更多操作性的文章。

1）冷備：停機袁铐，直接copy物理文件揭蜒，InnoDB引擎（frm文件、共享表空間文件剔桨、獨立表空間文件屉更、重做日志文件、my.cnf）洒缀。

恢復(fù)：把文件copy到對應(yīng)目錄瑰谜。

2）熱備： Ibbackup或者XtraBackup工具，記錄重做日志文件檢查點的LSN，copy共享表空間文件以及獨立表空間文件（不產(chǎn)生任何阻塞）似舵，記錄copy后重做日志文件檢查點的LSN脚猾，copy備份是產(chǎn)生的重做日志。

恢復(fù)：恢復(fù)表空間文件砚哗，應(yīng)用重做日志文件龙助。

3）溫備：

mysqldump，--single-transaction參數(shù)進行事務(wù)管理保證數(shù)據(jù)一致性蛛芥。備份時不能用DDL語句提鸟。 恢復(fù)：直接執(zhí)行文件，mysql –uroot –p <文件名.sql>

二進制半同步復(fù)制仅淑，主從服務(wù)器增量復(fù)制

恢復(fù)：mysqlbinlog

二称勋、一主一從

考慮一主一從的多數(shù)初衷是系統(tǒng)性能和系統(tǒng)高可用性問題，除了單Master場景中的備份工作需要做好以外涯竟，還有性能優(yōu)化赡鲜、讀寫分離、負載均衡三項重點工作需要考慮庐船。其中性能優(yōu)化的內(nèi)容比較多银酬，也是一塊大主題，要從系統(tǒng)的服務(wù)指標(biāo)作為依據(jù)采取相應(yīng)的動作筐钟，多數(shù)系統(tǒng)要求的是3秒內(nèi)完成請求揩瞪，總體換算下來，數(shù)據(jù)庫大概可以有1.5秒的總執(zhí)行時間篓冲，能滿足這個性能要求就是合理的優(yōu)化方案李破。下學(xué)期以這樣的優(yōu)先級來分別整理內(nèi)容：索引優(yōu)化 -》 表設(shè)計優(yōu)化 -》數(shù)據(jù)庫配置優(yōu)化 -》硬件優(yōu)化。

讀寫分離和負載均衡的實現(xiàn)相對簡單些壹将，我目前維護的系統(tǒng)比較落后嗤攻，沒有做讀寫分離，因為是一套以報表類功能為主的系統(tǒng)瞭恰，而負載均衡是依賴php代碼來做的屯曹，從實際運維效果來看，不大理想惊畏，而且負載均衡的代碼過分嵌入到業(yè)務(wù)邏輯代碼中，給代碼維護帶來一定噪音密任。下學(xué)期計劃對各種中間件進行實踐和性能測試颜启，到時候把一些測試數(shù)據(jù)分享出來。

三浪讳、一主 n 從

一旦開始考慮一主多從的服務(wù)器架構(gòu)缰盏，則證明你的系統(tǒng)對可用性、一致性、性能中一種或者多種的要求比較高口猜。好多系統(tǒng)在開始搭建的時候都會往這個方向看齊负溪，畢竟這樣“看起來”系統(tǒng)會健壯很多。不過其實并不能單單依靠MySQL的配置和MySQL自帶的中間件來解決可用性济炎、一致性方面的問題川抡。

四、橫向集群

系統(tǒng)龐大到需要分庫分表须尚，其實是一件可喜可賀的事情崖堤，但是切記的是要前面提到性能優(yōu)化工作做到極致之后才好考慮這些會增加系統(tǒng)復(fù)雜度的解決方案。橫向集群主要是從業(yè)務(wù)特性的角度對系統(tǒng)進行切分耐床，最徹底就是切分成了各個子系統(tǒng)密幔，子系統(tǒng)之間通過一些數(shù)據(jù)同步的方案來把一些核心數(shù)據(jù)進行共享，以避免跨庫調(diào)用跨庫join撩轰。

然后是各種系統(tǒng)接口調(diào)用胯甩，把大事務(wù)拆成小事務(wù)，事務(wù)之間做好隔離和同步堪嫂。上圖中的三個問題在橫向集群的架構(gòu)體系中應(yīng)屬于很有特色的問題蜡豹，在實際項目中其實是盡量去避免這些需求的存在的，不過如果確實需要了溉苛，也得有解決方案镜廉。下學(xué)期也將針對這些問題進行逐一整理，并測試一下一些號稱支持這些功能的中間件愚战。

五娇唯、縱向集群

橫向集群的切分思路最終是切分子系統(tǒng)，而縱向集群最后遇到的最棘手的問題是擴縮容寂玲，我運維的一個系統(tǒng)是提前對數(shù)據(jù)做了256個切片塔插，256切片中0~127切片和128~255切片分別存在兩個一主兩從的數(shù)據(jù)庫集群中，系統(tǒng)運維了3年多拓哟，目前還沒有擴容需求想许。設(shè)計初衷應(yīng)該是考慮得到，假設(shè)有一天數(shù)據(jù)量非常大断序，可以把256個切片分4大片流纹，分別存儲到4個一主兩從的集群中，從而實現(xiàn)擴容违诗。

這個思路的確是可取的漱凝，只是我們的分庫邏輯當(dāng)前是php代碼實現(xiàn)，也有一定程度上影響了業(yè)務(wù)代碼的邏輯诸迟，運維起來有點心驚膽戰(zhàn)茸炒，還是保持業(yè)務(wù)代碼清爽比較好愕乎。

下學(xué)期將介紹一些實現(xiàn)了庫路由功能的中間件的使用，也根據(jù)實際情況把想到的一些擴縮容方案實踐一遍壁公，敬請期待實操效果的分享感论。

六、混合模式

與其說這部分內(nèi)容討論上面5種場景的混合紊册，不如說這部分內(nèi)容是做總結(jié)比肄。上面的5種場景中，一共列舉了17個問題點湿硝，這17個問題點基本上都是疊加式的薪前，越往深入的框架去做就越需要考慮齊這17個問題點。17個問題點考慮全了关斜，混合模式下的問題就不成問題了示括。