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++編程！彎道超車，快人一步！筆者這里或許可以幫到你~
分享（原始碼、專案實戰視頻、專案筆記，基礎入門教程）
歡迎轉行和學習編程的伙伴，利用更多的資料學習成長比自己琢磨更快哦！
免費學習書籍：
免費學習資料：
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/261697.html
標籤：MySQL
上一篇：MySQL學習04（DQL查詢）
下一篇：Redis-第九章節-動態字串