導語

今天微信在微信朋友圈發表了其在MySQL領域實現的一套高可用、強一致的叢集方案，頓時朋友圈刷屏，都在嘖嘖稱讚。

有些人轉發是用來Mark一下，留著後面細細品嚐，有些人應該是看過了，說是高質量的開源，而還有一些人，說是有Galera或者group replication的味道。

在我知道這事兒之後，心裡很高興，覺得太強大了，想必是一個非常好的方案，首先要感謝微信團隊，在開源的路上又帶了一個好頭。

在看完之後，我心裡面是忐忑的，因為目前所能看到的實現架構或者支援的功能與朋友圈轉發的架勢來看有很大的出入，所以關於微信的這個開源，我問了一下我周邊的朋友，我說為啥這個這麼火？

我自己覺得有兩方面的原因：

• 一是微信開源這個動作本身，微信在國內的影響力太大了。
• 二是這個MySQL解決方案，MySQL太需要靠譜的高可用和一致性解決方案了，目前來看，還無出Galera其右者。

騰訊最近在這方面做了很多工作，開源了不少產品，這是值得慶賀的，這是圈內的福利，圈內的良心，如果非常火，這是有道理的，這是圈內的正能量，我一直希望有更多的公司或者個人，能開源更多的好產品，一起進步一起成長。

我花了一個下午的時間認真研究了一下PhxSQL，優點已經在別的文章裡面都說得很多了，我就不再贅述了。

從技術方案的角度來看，我來說說在研究或者將來計劃使用PhxSQL的話，有什麼需要注意的地方。

時間比較倉促，也許有理解不對的地方，也請大家支招。現在還沒來得及看程式碼，以後如果有機會繼續深入研究的話，可以在後續文章中加以說明。

我覺得大家在研究的時候，要注意以下幾個部分：

1、 架構很複雜，部署一套需要很多模組

這個是很明確的，圖1中可以看到phxSQL的架構，原本一套叢集只有MySQL三個節點，現在加入了兩個新的服務：Phxbinlogsvr、Phxsqlproxy。

很明顯，模組越多，整個叢集的故障率就越高，不可靠性就越高，部署這麼一套叢集需要多久？

需要考慮入手門檻。

模組多了，機器壓力及相應成本就增加了，同時DBA需要運維的物件就多了，壓力變大了，這都是需要考慮的問題。

2. 究其根本，還是主從複製機制，擺脫不了這種機制下的弊端。

有些評論說到了，其實現架構有Galera或者group replication

3. 單點寫入，不支援多點寫入

接著上面說，Galera或者group replication，最大的革命是支援了多點寫入，這個特性我認為是最大的最有意義的特點，因為目前在MySQL主從複製的方案中，我們所做的高一致性的工作，都是因為不能雙寫（單點寫入）所導致的，而支援了多點寫入即可實現對應用程式零影響的去運維了，而PhxSQL的多點寫入從架構圖1中可以看出，支援的多點寫入是通過中間層來轉發的，中間層Phxsqlproxy還是找到了寫節點，將寫入打到Master上面，這完全不是一個概念，如果我想主動切的，還是要把當前的Master設定為Readonly，然後找到新的Master取消Readonly，然後繼續寫入，那這樣勢必影響了業務。所以主從複製的模式先天性的不支援多點寫入。

4. 除了不需要回滾這個特點之外，與半同步無異

從宣傳文章中的圖2.1來看，這個圖所示的是我們平常所使用的半同步的示意圖，這是我們每個人都熟悉的，而我們可以看看PhxSQL的圖2.2。很明顯可以看得出，這個有點像5.7中的等待多點節點ACK的半同步了，但這裡等待的是Phxbinlogsvr返回的ACK，當然使用了Paxos協議的情況下，Phxbinlogsvr會向其它幾個節點複製Binlog，但叢集中只有3個節點的情況下，必須要等其它2個節點的ACK，不然不能超過半數，那麼此時和3個節點的半同步相比，效能似乎也沒什麼太大的區別。所以從這個圖中可以看到，實際上實現的架構就是半同步。另外，宣傳文章中說到了，PhxSQL可以保證的是從庫節點不回滾，這個說法我是支援的，半同步確實有時候是需要回滾的，PhxSQL解決了這個問題，解決方案是，針對Master，可能還是存在回滾資料的可能性的，但對於Slave，只需要補資料即可。但我的疑問是用這麼複雜的架構來解決這個回滾的問題，有多大產出比？

2. 究其根本，還是主從複製機制，擺脫不了這種機制下的弊端。

有些評論說到了，其實現架構有Galera或者group replication的味道，在我研究之後，這兩者之間相去甚遠，說白了，PhxSQL還是主從架構，只是將原來的Binlog從主節點複製到從節點的架構，修改為從主節點，複製到Phxbinlogsvr叢集，然後MySQL從節點再從Phxbinlogsvr中拉取，這樣的實現方式，增加了中間一層服務，勢必資料複製的延遲時間就會有所增加，主從延遲之後，還如何能做到對使用者無影響的隨意切換呢？或者說，如果當前正在主從延遲（司空見慣了），那自動切換程式如何選擇？等待？還是強制切換？這種情況下，要麼犧牲一致性，要麼犧牲可用性，很難做到像Galera那樣的兩全。

3. 單點寫入，不支援多點寫入

接著上面說，Galera或者group replication，最大的革命是支援了多點寫入，這個特性我認為是最大的最有意義的特點，因為目前在MySQL主從複製的方案中，我們所做的高一致性的工作，都是因為不能雙寫（單點寫入）所導致的，而支援了多點寫入即可實現對應用程式零影響的去運維了，而PhxSQL的多點寫入從架構圖1中可以看出，支援的多點寫入是通過中間層來轉發的，中間層Phxsqlproxy還是找到了寫節點，將寫入打到Master上面，這完全不是一個概念，如果我想主動切的，還是要把當前的Master設定為Readonly，然後找到新的Master取消Readonly，然後繼續寫入，那這樣勢必影響了業務。所以主從複製的模式先天性的不支援多點寫入。

4. 除了不需要回滾這個特點之外，與半同步無異

從宣傳文章中的圖2.1來看，這個圖所示的是我們平常所使用的半同步的示意圖，這是我們每個人都熟悉的，而我們可以看看PhxSQL的圖2.2。很明顯可以看得出，這個有點像5.7中的等待多點節點ACK的半同步了，但這裡等待的是Phxbinlogsvr返回的ACK，當然使用了Paxos協議的情況下，Phxbinlogsvr會向其它幾個節點複製Binlog，但叢集中只有3個節點的情況下，必須要等其它2個節點的ACK，不然不能超過半數，那麼此時和3個節點的半同步相比，效能似乎也沒什麼太大的區別。所以從這個圖中可以看到，實際上實現的架構就是半同步。另外，宣傳文章中說到了，PhxSQL可以保證的是從庫節點不回滾，這個說法我是支援的，半同步確實有時候是需要回滾的，PhxSQL解決了這個問題，解決方案是，針對Master，可能還是存在回滾資料的可能性的，但對於Slave，只需要補資料即可。但我的疑問是用這麼複雜的架構來解決這個回滾的問題，有多大產出比？

5. Binlog儲存到Phxbinlogsvr後，如何實現並行應用。

這個算一個問題，在MySQL5.6中，至少是可以並行複製的，或者5.7的話，更好的並行複製，而在PhxSQL中，因為中間插入一個Phxbinlogsvr，那從Phxbinlogsvr到MySQL的應用，是如何支援並行的，是像原生的把Phxbinlogsvr做為一個主庫，向MySQL從節點Send，讓MySQL用原生的複製？還是自己做了新的開發？

6. 監控由誰來做？

上面已經說過，這麼一個複雜的架構，每個模組本身的存活及健壯性如何保證，也就是它們的監控程式如何來做，監控程式是否可以做到公佈式的監控？或者這個監控就是相互監控？這也算一個問題吧，因為監控是叢集健壯性必不可少的一部分。

7. 和中間層加半同步的區別

最後一點，如果捨棄半同步的資料回滾（假設可以接受），那如果和一箇中間層加上半同步的實現方案相比，優勢在哪裡？

作者：王竹峰

文章出處：鹽味