關於MySQL Group Replication

前兩天，聽了公司DBA老大的分享，也是首次接觸到了MGR這個架構，其對MGR的大力推崇，讓做爲業務開發人員的我也對其產生了興趣，至此，用同事「老司機」的話說，是時候學習一波了。

1、CAP與MySQL

談MGR以前，先要熟悉一下CAP與MySQL的關係。當前MySQL的master-slave架構，取AP舍C，嗯嗯，DBA們的PPT就是這樣告訴俺們的。

C：（consistency）一致性，以前在同事分享時，你們一塊兒討論過什麼叫一致性，後來能讓你們比較認同的解釋是：「違背了預約的一致性約束，就是違背了一致性」，這話看起來跟沒說似的，可是其強調了一個很重要的點，即「約束條件」。例如，一張表的某個字段在現實世界中是惟一unique的，只是在建表的時候沒指定unique key，而後某一天出了故障，插入了兩條相同字段的record，這種狀況，也應該算是違背了一致性的。只是通常在分佈式系統的背景下，你們默認的理解都將其限定在不一樣節點的value是否一致這個更窄的概念上，以方便討論。

A：（availability）可用性，指全部的讀寫請求，在有限的時間內都能得到響應。我理解的A，應該是指一個request到達server以後，server可以在有限的時間內，發出一個response。不能把client-server當作整個系統，client發出的一個request根本就沒到達server，天然不會有response。你把人家機房的光纜挖斷了，而後挑戰人家系統的可用性，這就蛋疼了。換個例子，好比server的CPU飆到最高了，這時候來一個request，server直接不處理，給丟了，這纔是系統可用性應該考慮的範疇。

P：（partition-tolerance）分區容忍性，這個一直是個很容易讓人困惑的概念，我比較認同的一個解釋是：「在網絡分區的狀況下，被分隔的節點仍能正常對外服務」。就是說，因爲網絡的因素，將本來聯通的分佈式系統，分隔成彼此沒法通訊的一個個子集了，這時候這個單獨的子集可以繼續對外提供服務。

我的理解：

1. 對於CAP別較真，網上一搜，衆說紛紜，去扣CAP的概念、證實(至於那個反證的證實，着實蛋疼)都沒意義，還容易瘋。就是一個在設計系統的時候的參考，核心指導做用是說在設計的時候，別去追求完美，實事求是，具體問題具體分析，get這一點就足以了。

2. 在CAP中，沒有舍誰取誰的，都是權衡罷了。這世間之事吧，就歷來沒有非此即彼。

接下來就以CAP的角度說說MySQL的master-slave架構：

所謂master-slave架構，就是由master負責寫，slave負責讀，而後將master的binlog不斷的發送到slave執行，使整個DB集羣達到一致。先來講P，master與slave節點失聯以後，木有關係，master仍是負責client發過來的寫請求，slave仍是負責讀請求，你們各司其職，也就實現了P，同時，因爲master的數據沒法同步給slave了，也就天然沒法保證C了。還有就是哪怕在網絡很是健康的狀況，master與slave存在的延遲，也使整個集集羣沒法實現強一致。既然存在問題，也就必然存在着問題的解決之道，接下來就來講說MGR。

2、MySQL group replication

在默認狀況下，MySQL的複製（replication）策略是異步（asynchronous）複製，以下圖：

圖有點毛病，通常是在事務commit以後，纔將binlog發送到slave，但問題是同樣的，就是C太弱了，master將binlog發送出去以後，就無論了。要是slave沒收到，那系統天然就不一致了，既然C太弱了，就能夠想辦法來保障C，好比採起半同步（semi-synchronous）的策略：

也即master等每個slave ACK以後，再提交事務，告訴client此次的更新成功了。如此，就保證commit以後，slave確定收到binlog了，天然也就提高了C。但問題也就隨之而來了，即性能降低了，每一條變動SQL的性能降低帶動系統QPS的降低，從而影響了A。此外，當集羣中新增節點時，會讓系統性能降低。看，問題又來了，那何如平衡C與A呢？MGR就提供了一個解決思路，先看看引入MGR以後，系統大概變成了什麼樣子：

如圖，一個明顯的變化就是系統再也不區分master與slave了，每一個節點都是master，均可以進行寫，而後使用一致性算法來實現整個集羣的對外一致性。其寫過程大概變成了下面醬紫：

也就是在一個節點寫完以後，使用一致性協議使整個集羣達到一致，而後就能夠返回了。指的注意的是，整個集羣達到一致，可不是說每一個節點都ACK了。經過一致性協議，要比等每一個slave都ACK更快，還能讓整個DB集羣實現多節點寫入，對於DB集羣的性能來講，天然會有不小的性能提高。根據MySQL官方文檔，MGR有兩種模式：

single-primary mode：只有主節點負責寫，集羣可以自動選舉主節點

multi-primary mode：全部節點都接受寫

貼一下MySQL對於group replication的文檔和其性能測評：

文檔：https://dev.mysql.com/doc/refman/5.7/en/group-replication.html

性能對比：http://mysqlhighavailability.com/performance-evaluation-mysql-5-7-group-replication/

3、一致性協議

MGR使用了paxos協議來實現集羣的一致性。先貼一個分佈式系統一致性問題的演示動畫：

http://thesecretlivesofdata.com/raft/

協議挺複雜的，咱不就介紹了，明確兩個點就得了：

1. 在paxos算法中，過半數的節點贊成變量v = 2了，就叫達成一致了

2. 在沒一輪寫入以後，經過節點之間相互通訊、投票，趨於實現達成一致