在高併發場景下，資料主從同步是必然的方式，除了資料庫主從同步外，還會涉及到分散式環境下的資料同步(文末有介紹~)。

今天分享資料庫主從同步解決方案。

資料主從同步的由來

網際網路的很多業務，特別是在高併發的場景下，基本都是讀遠遠大於寫，如果資料庫讀和寫的壓力都同在一臺主機上，這顯然不太合理。

於是，把一臺資料庫主機分為單獨的一臺寫主庫（主要負責寫操作），而把讀的資料庫壓力分配給讀的從庫，而且讀從庫可以變為多臺，這就是讀寫分離的典型場景如下：

為了進一步的降低資料庫端的壓力(高併發的瓶頸)，這個時候也會在業務層部署分散式快取叢集(redis、memcached)等，把讀的壓力轉移給應用伺服器端，其實與資料主從的設計是遵循同一個原則，降低後端資料庫的壓力。

問題：

讀寫分離提高了資源的利用效率的同時也引出了一個問題，就是由於延時（網路傳輸，操作）而引起的資料庫主從不一致的問題，以下會詳細談相關的資料一致性解決方案。

資料同步一致性解決方案

1.半同步複製

辦法就是等主從同步完成之後，等主庫上的寫請求再返回，這就是常說的“半同步複製”。

實現方案

mysql的半同步複製方案，下面我以mysql為例介紹。

MySQL半同步複製

MySQL的Replication預設是一個非同步複製的過程，從MySQL5.5開始，MySQL以外掛的形式支援半同步複製，我先談下非同步複製，這樣可以更好的理解半同步複製。

1）非同步複製

MySQL預設的複製是非同步的，主庫在執行完客戶端提交的事務後會立即將結果返給給客戶端，並不關心從庫是否已經接收並處理，這樣就會有一個問題，主如果crash掉了，此時主上已經提交的事務可能並沒有傳到從庫上。

2）半同步複製

介於非同步複製和全同步複製之間，主庫在執行完客戶端提交的事務後不是立刻返回給客戶端，而是等待至少一個從庫接收到並寫到relay log中才返回給客戶端。相對於非同步複製，半同步複製提高了資料的安全性，同時它也造成了一定程度的延遲，這個延遲最少是一個TCP/IP往返的時間。所以，半同步複製最好在低延時的網路中使用。

半同步複製原理：

• 事務在主庫寫完binlog後需要從庫返回一個已接受，才放回給客戶端
• mysql5.5版本以後，以外掛的形式存在，需要單獨安裝
• 確保事務提交後binlog至少傳輸到一個從庫
• 不保證從庫應用完成這個事務的binlog
• 效能有一定的降低
• 網路異常或從庫宕機，卡主庫，直到超時或從庫恢復

該方案優點：

利用資料庫原生功能，比較簡單

該方案缺點：

主庫的寫請求時延會增長，吞吐量會降低

2.資料庫中介軟體

流程：

1）所有的讀寫都走資料庫中介軟體，通常情況下，寫請求路由到主庫，讀請求路由到從庫

2）記錄所有路由到寫庫的key，在主從同步時間視窗內（假設是500ms），如果有讀請求訪問中介軟體，此時有可能從庫還是舊資料，就把這個key上的讀請求路由到主庫。

3）在主從同步時間過完後，對應key的讀請求繼續路由到從庫。

相關的中介軟體有：

1）canal:是阿里巴巴旗下的一款開源專案，純Java開發,基於資料庫增量日誌解析，提供增量資料訂閱&消費，目前主要支援了MySQL。

2）otter：也是阿里開源的一個分散式資料庫同步系統，尤其是在跨機房資料庫同步方面，有很強大的功能。它是基於資料庫增量日誌解析，實時將資料同步到本機房或跨機房的mysql/oracle資料庫。

兩者的區別在於：

otter目前嵌入式依賴canal，部署為同一個jvm，目前設計為不產生Relay Log。

otter目前允許自定義同步邏輯，解決各類需求。

該方案優點

能保證絕對一致

該方案缺點：

資料庫中介軟體的成本較高

3.快取記錄寫key法

寫流程：

1）如果key要發生寫操作，記錄在cache裡，並設定“經驗主從同步時間”的cache超時時間，例如500ms

2）然後修改主資料庫

讀流程：

1）先到快取裡檢視，對應key有沒有相關資料

2）有相關資料，說明快取命中，這個key剛發生過寫操作，此時需要將請求路由到主庫讀最新的資料。

3）如果快取沒有命中，說明這個key上近期沒有發生過寫操作，此時將請求路由到從庫，繼續讀寫分離。

該方案優點：

相對資料庫中介軟體，成本較低

該方案缺點：

為了保證“一致性”，引入了一個cache元件，並且讀寫資料庫時都多了快取操作。

以上就是資料庫主從同步一致性方案詳解，如果有興趣瞭解更加深入的分散式大資料分散式檔案系統和分散式資料庫的一致性，可以到優知學院官網檢視：分散式資料庫資料一致性的原理、與技術實現方案(文章)~

更多利用分散式快取、非同步訊息等方式解決高併發場景，具體的內容如下：