背景

在企業中,一般系統架構的瓶頸會出現在資料庫這一部分,mysql主從架構在很大程度上解決了這部分瓶頸,但是在mysql主從同步的架構也存在很多問題;比如:1.關於資料寫入部分(也就是主庫)往往很難做到擴充套件,雖然很多大公司在邏輯業務方面就進行對資料的拆分,比如商品庫存按照區域去拆分(一個區域走一個庫存也就是一個主庫,然後定時同步總的庫存),按照商品型別去劃分(一個型別的商品走一套資料庫),但是這對於很多中小型公司來說實現起來還是比較困難的; 2.主從同步一般都是一個主庫,一旦主庫出現問題,就有可能直接導致整個主從同步架構崩盤,雖然發現後也是可以慢慢恢復的,但是這個恢復時間對於很多公司來說是難以接受的

不過多主需要考慮自增長ID問題，這個需要特別設定配置檔案，比如雙主，可以使用奇偶，總之，主之間設定自增長ID相互不衝突就能完美解決自增長ID衝突問題。

主從同步複製原理

該過程分為三步：

第一步就是master記錄二進位制日誌（這些記錄叫做二進位制日誌事件，binary log events）。在每個事務更新資料完成之前，master在二日誌記錄這些改變。MySQL將事務序列的寫入二進位制日誌，即使事務中的語句都是交叉執行的。在事件寫入二進位制日誌完成後，master通知儲存引擎提交事務。

第二步就是slave將master的binary log拷貝到它自己的中繼日誌(relay log)。首先，slave開始一個工作執行緒——I/O執行緒。I/O執行緒在master上開啟一個普通的連線，然後開始binlog dump process。Binlog dump process從master的二進位制日誌中讀取事件，如果已經跟上master，它會睡眠並等待master產生新的事件。I/O執行緒將這些事件寫入中繼日誌。

第三步SQL slave thread處理該過程的最後一步，slave重複中繼日誌中的事件，將改變執行到自己的資料庫。SQL執行緒從中繼日誌讀取事件，更新slave的資料，使其與master中的資料一致。只要該執行緒與I/O執行緒保持一致，中繼日誌通常會位於OS的快取中，所以中繼日誌的開銷很小。

MySQL雙主（主主）架構思路如下

1.兩臺mysql都可讀寫，互為主備，預設只使用一臺（masterA）負責資料的寫入，另一臺（masterB）備用；

2.masterA是masterB的主庫，masterB又是masterA的主庫，它們互為主從；

3.兩臺主庫之間做高可用,可以採用keepalived等方案（使用VIP對外提供服務）；

4.所有提供服務的從伺服器與masterB進行主從同步（雙主多從）;

5.建議採用高可用策略的時候，masterA或masterB均不因宕機恢復後而搶佔VIP（非搶佔模式）；

       這樣做可以在一定程度上保證主庫的高可用,在一臺主庫down掉之後,可以在極短的時間內切換到另一臺主庫上(儘可能減少主庫宕機對業務造成的影響),減少了主從同步給線上主庫帶來的壓力;但是也有幾個不足的地方:

1、比如masterB可能會一直處於空閒狀態(其實完全可以讓它承擔一部分從庫的角色來負責一部分查詢請求的)

2、這樣真正提供服務的從庫要等masterB先同步完了資料後才能去masterB上去同步資料,這樣可能會造成一定程度的同步延遲時間的加長;

3、如果masterA一旦恢復正常,會不會導致資料寫入混亂(這個可以在keepalived中設定響應的規則,讓其不”奪權”;

架構簡易圖如下：