享學課堂特邀作者：老顧

轉載請宣告出處！

何為“三高”程式設計師，當然不是指高血壓、高血糖、高血脂，而是高學歷、高薪資、高顏值。那麼Mysql的“三高”又是什麼呢？

前言

小夥伴們在專案開發中，無法避免的要跟資料庫打交道，一般在網際網路公司所採用的資料庫都為Mysql，而且創業公司都採用的單機方式。

這種方式自己玩玩可以，運用到實際專案中，那肯定要挨批的。一方面資料不安全，萬一資料庫的電腦磁碟壞了，就坑了。另一方面資料庫的併發能力是有限的，一般併發數200～500就差不多了，當然你要繼續往上增，也是可以的，那就影響整體Mysql的響應時間。

今天老顧來講講Mysql的三高叢集架構，所謂三高，就是“高可用”、“高負載”、“高效能”的架構

老顧這裡說明一下，只是從整體上面介紹叢集方案，不會那麼深入；但會講一些網上缺失的、而且很重要的思想。瞭解全面架構是非常重要的，具體細節自行查閱。

主從架構

Mysql的主從架構是最容易想到的，先來個圖：

主從方案是我們很多中介軟體採用的方式，Mysql的主從方式，資料由主Mysql同步到從Mysql中，資料同步是單向的。

同步的方案有幾種方案（非同步、同步、半同步），網上介紹很多，老顧就不詳細講了。

主從方案的特點：

1、解決了資料安全問題

2、結合一些中介軟體（如：mycat）或工具（如：sharding-jdbc）實現讀寫分離；提高Mysql的整體效能/負載

注：讀寫分離含義：資料的更新（即寫請求）操作的是主Mysql，資料再同步到從Mysql中；讀取資料（讀請求）是訪問的從Mysql。

我們從圖中可以看出，一主多從的方案中只有一個寫節點（主mysql），一旦主Mysql出現問題，整個系統就無法進行寫請求，那肯定是不行的。主Mysql有單節點故障隱患，怎麼解決？網上說的方案也有很多，老顧只介紹大廠採用的，比較成熟的方案。

MHA方案

MHA全稱Master High Availability，從名字上面就可以看出它的作用，就是解決主節點的高可用問題。

MHA目前在 MySQL 高可用方面是一個相對成熟的解決方案，它由日本人開發，是一套優秀的作為 MySQL高可用性環境下故障切換和主從提升的高可用軟體。MHA 能做到 0~30 秒之內自動完成資料庫的故障切換操作。

MHA 由兩部分組成：MHA Manager（管理節點）和 MHA Node（資料節點）

管理節點主要起到監控作用，如果發現主節點不可用，就發起主從切換和故障轉移。

目前MHA主要支援是一主多從的架構，要求至少要3個節點，一主二從。

那MHA在主節點掛掉後，是怎麼進行切換的？

1、主節點掛了，在從節點中重新選舉一個新備選主節點，原則是binlog最新最近更新的從節點作為新備選主節點。

2、在備選主節點和其他從節點之間同步差異中繼日誌（relay log）

3、應用從原來的主節點上儲存二進位制日誌

4、提升備選主節點為新主節點

5、遷移叢集其他從節點 作為 新主節點的 從節點。

上面介紹了是核心流程，其實MHA內部做了很多業務，核心思想就是儘可能的保證資料一致性，不讓資料丟失。雖然MHA已經做了很好，但有些場景還是不能避免。還有一個問題就是主節點把資料同步到從節點是有延時的，尤其在高併發情況下，同一刻主節點和從節點資料會不一致。

Mysql在這方面也進行很多優化，如半同步方式，在5.7版本又增加了after sync方式，確保資料一致，但多個從節點之間還是存在資料延時。

那有沒有一個方案能夠確保資料的強一致性？我們接著往下看。

PXC方案

PXC是percona公司的percona  xtraDB  cluster，簡稱PXC。它是基於Galera協議的高可用叢集方案。可以實現多個節點間的資料同步複製以及讀寫，並且可保障資料庫的服務高可用及資料強一致性。

PXC架構中Mysql無主從之分，都是相同的。而且每個節點都是能夠提供讀和寫，是不是很酷，那PXC是怎麼實現各個節點資料強一致性的呢？

上面是個時序圖，就是PXC執行的流程，小夥伴們是不是感覺很複雜，老顧可以教大家可以這樣理解：

其實就是一句話，PXC的原理其實在提交事務時，確保所有的節點事務都要成功提交，才返回成功；如果其中有一個不成功，就回滾資料，返回不成功，

正因為這樣的原理，就確保資料肯定是一致的，而且是實時一致；當然這樣就導致效能有損耗。PXC另一個好處就是每個節點都可以提供讀寫請求，不管寫在哪個節點，都能夠保證資料強一致性。

MHA與PXC

1、MHA主要寫入速度很快，但資料不是強一致性

2、PXC保證資料強一致性，但寫入速度慢

那有沒有取他們優點的方案呢？來一個終極方案。老顧告訴小夥伴們，其實很多方案不可能都是優點，沒有缺點，不可能很完美，最主要的是要知道在什麼場景下運用什麼方案。根據MHA 和 PXC方案的特點，我們可以結合自己的業務去決定怎麼使用它們？

PXC適合儲存高價值的資料，要求資料強一致性，如：賬戶，訂單，交易等等MHA適合儲存低價值的資料，不要求強一致性，如：許可權，通知，日誌，商品資料，購物車等等

現實情況，很多大廠都是結合使用的，我們看看2017年天貓雙11，資料庫峰值4200萬次/秒，支付峰值25.6萬次/秒；這個支付峰值已經創造了一個世界記錄（國人的驕傲）。

我們發現支付場景的峰值相對其他業務的峰值比較低，這個是因為支付場景肯定是要求資料強一致性的，只要涉及到錢，使用者都會很在意。

最終推薦方案

兩種方案的結合，因為PXC架構都可以寫，所以在入口處放一個HAProxy作負載均衡，客戶端只要訪問HAProxy的地址就行了，不需要知道每個PXC節點的地址。

在資料庫訪問中介軟體那邊肯定要進行業務封裝，在設計的時候要明確，哪些資料進入哪個叢集環境，當然做的好點，可以配置化（也沒有必要，因為業務其實是確定的）

總結

很多小夥伴們在網上喜歡問，哪個方案好，哪個方案不好，有沒有一個通吃天下的方案，這個是不現實的，很多方案的選擇是要結合相關業務場景的。

關於MHA和PXC很多細節，老顧這裡沒有介紹，網上介紹的也很多，可以自行查閱。

希望這篇文章可以開拓你的思維，謝謝！！！

關注我，還有更多技術乾貨分享~