新手編程之旅：MySQL中的關鍵點！一文帶你搞懂它

Mysql的使用很是廣泛，跟mysql有關的話題也很是多，如性能優化、高可用性、強一致性、安全、備份、集羣、橫向擴展、縱向擴展、負載均衡、讀寫分離等。

要想掌握其中的精髓，可得花費很多功力，雖然目前流行的mysql替代方案有不少，但是從最小成本最容易維護的角度而言，mysql仍是首選。

下面從應用場景的角度切入，對mysql的技術點進行組織，寫一份知識圖譜，方便進行更深刻的學習和總結。

 

單Master

 

單Master的狀況是廣泛存在的，對於不少我的站點、初創公司、小型內部系統，考慮到成本、更新頻率、系統重要性等問題，系統只依賴一個單例數據庫提供服務，基本上已經知足需求。這種場景下我以爲重點應該關注的話題有上圖所示的四點。

其中最重要的環節是數據備份，若是是交易量很是低，而且具備很是明確的服務時間段特性的話，簡單的mysqldump是能夠勝任的。可是這是有缺陷的，數據還原以後註定從備份點到還原點之間的數據會丟失。

然而在極多數的狀況下，備份的工做是無法馬虎的，以下列舉的幾點小細節，下學期將分享更多操做性的文章。

1）冷備：停機，直接copy物理文件，InnoDB引擎（frm文件、共享表空間文件、獨立表空間文件、重作日誌文件、my.cnf）。

恢復：把文件copy到對應目錄。

2）熱備： Ibbackup或者XtraBackup工具，記錄重作日誌文件檢查點的LSN，copy共享表空間文件以及獨立表空間文件（不產生任何阻塞），記錄copy後重作日誌文件檢查點的LSN，copy備份是產生的重作日誌。

恢復：恢復表空間文件，應用重作日誌文件。

3）溫備：

mysqldump，–single-transaction參數進行事務管理保證數據一致性。備份時不能用DDL語句。 恢復：直接執行文件，mysql –uroot –p <文件名.sql>

二進制半同步複製，主從服務器增量複製

恢復：mysqlbinlog

一主一從

 

考慮一主一從的多數初衷是系統性能和系統高可用性問題，除了單Master場景中的備份工做須要作好之外，還有性能優化、讀寫分離、負載均衡三項重點工做須要考慮。其中性能優化的內容比較多，

也是一塊大主題，要從系統的服務指標做爲依據採起相應的動做，多數系統要求的是3秒內完成請求，整體換算下來，數據庫大概能夠有1.5秒的總執行時間，能知足這個性能要求就是合理的優化方案。

讀寫分離和負載均衡的實現相對簡單些，我目前維護的系統比較落後，沒有作讀寫分離，由於是一套以報表類功能爲主的系統，而負載均衡是依賴php代碼來作的，從實際運維效果來看，

不大理想，並且負載均衡的代碼過度嵌入到業務邏輯代碼中，給代碼維護帶來必定噪音。

一主 n 從

 

一旦開始考慮一主多從的服務器架構，則證實你的系統對可用性、一致性、性能中一種或者多種的要求比較高。好多系統在開始搭建的時候都會往這個方向看齊，畢竟這樣「看起來」系統會健壯不少。不過其實並不能單單依靠mysql的配置和mysql自帶的中間件來解決可用性、一致性方面的問題。

橫向集羣

 

系統龐大到須要分庫分表，實際上是一件可喜可賀的事情，可是切記的是要前面提到性能優化工做作到極致以後纔好考慮這些會增長系統複雜度的解決方案。橫向集羣主要是從業務特性的角度對系統進行切分，

最完全就是切分紅了各個子系統，子系統之間經過一些數據同步的方案來把一些核心數據進行共享，以免跨庫調用跨庫join。

而後是各類系統接口調用，把大事務拆成小事務，事務之間作好隔離和同步。上圖中的三個問題在橫向集羣的架構體系中應屬於頗有特點的問題，在實際項目中實際上是儘可能去避免這些需求的存在的，

不過若是確實須要了，也得有解決方案。

縱向集羣

 

橫向集羣的切分思路最終是切分子系統，而縱向集羣最後遇到的最棘手的問題是擴縮容，我運維的一個系統是提早對數據作了256個切片，256切片中0~127切片和128~255切片分別存在兩個一主兩從的數據庫集羣中，

系統運維了3年多，目前尚未擴容需求。設計初衷應該是考慮獲得，假設有一天數據量很是大，能夠把256個切片分4大片，分別存儲到4個一主兩從的集羣中，從而實現擴容。

這個思路的確是可取的，只是咱們的分庫邏輯當前是php代碼實現，也有必定程度上影響了業務代碼的邏輯，運維起來有點心驚膽戰，仍是保持業務代碼清爽比較好。

 

 

另外若是你想更好的提高你的編程能力，學好C語言C++編程！彎道超車，快人一步！筆者這裏或許能夠幫到你~

分享（源碼、項目實戰視頻、項目筆記，基礎入門教程）

歡迎轉行和學習編程的夥伴，利用更多的資料學習成長比本身琢磨更快哦！

免費學習書籍：

 

免費學習資料：