昨天談了高併發場景的鎖：MySQL最全鎖與Java最全併發鎖。

今天接著聊：高併發場景下的資料庫同步的3種解決方案

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

01

資料主從同步的由來

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

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

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

問題：

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

02

資料庫半同步複製

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

實現方案

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

MySQL半同步複製

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

1）非同步複製

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

2）半同步複製

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

半同步複製原理：

• 事務在主庫寫完binlog後需要從庫返回一個已接受，才放回給客戶端

• mysql5.5版本以後，以外掛的形式存在，需要單獨安裝

• 確保事務提交後binlog至少傳輸到一個從庫

• 不保證從庫應用完成這個事務的binlog

• 效能有一定的降低

• 網路異常或從庫當機，卡主庫，直到超時或從庫恢復

該方案優點：

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

該方案缺點：

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

03

資料庫中介軟體同步

流程：

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

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

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

該方案優點：

能保證一致

該方案缺點：

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

04

快取記錄寫key同步

寫流程：

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

2）然後修改主資料庫

讀流程：

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

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

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

該方案優點：

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

該方案缺點：

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