【分佈式系統遨遊】分佈式數據複製

今天咱們來討論分佈式數據複製。

爲何須要數據複製

咱們在上一篇文章中談到了分佈式數據的分片存儲技術，其核心在於將原數據劃分爲多個數據子集，而後將每一個子集分散到不一樣的集羣節點上存儲，以實現負載均衡。那麼，這裏實際上是有一個問題的。因爲每一個節點上面的數據徹底沒有交集，假設其中一個節點掛了，那麼這個節點上的數據就丟失了。因此，咱們須要一種技術方案，在數據分片的基礎上，實現分佈式集羣的高可用性與可靠性，這就是咱們今天要討論的分佈式數據複製技術。

數據複製是什麼

數據複製就是一種數據備份技術。好比如今有集羣節點1，那麼咱們會啓用節點2，將節點1上的數據拷貝到節點2上，這樣節點1與節點2上的數據徹底相同。當節點1掛了的時候，能夠當即啓用節點2，繼續對外提供數據存取服務，實現了分佈式存儲系統的自動容錯。

數據複製的幾種方案

要想節點2可以徹底代替節點1進行工做，那麼節點2必需要與節點1上的數據一致。可是這個一致性也要分強弱。咱們接下來回顧一下CAP理論。
P就是指在集羣中網絡出現故障的時候，集羣內的網絡就被隔離開了（分區），可是必須可以對外正常提供服務。因此，因爲分佈式系統中的網絡故障不可避免，P是必須知足的，不然就退化成了單機系統。另外一方面，這條原則就讓咱們必須將數據分散到多個物理節點上，才能在某一條網絡鏈路出現故障的時候，讓副本節點頂上來，對外繼續正常提供服務，這也就是咱們爲何要作數據冗餘備份與數據複製。

可是CAP理論又告訴咱們，只能知足CP（偏一致性）或者AP（偏可用性）。那麼，爲何CAP不能同時知足呢？假設咱們就要知足CP，各節點間實現強一致性。那麼，假設我對其中一個節點進行寫操做，那麼這個寫操做就會一直阻塞等待，直到將更新後的數據同步到另外一個節點上纔會返回寫操做成功。返回以後，才能夠進行後續的讀請求。這樣保證了不管讀哪一個節點，數據都是一致的。可是，因爲咱們在複製完成以前一直會阻塞，會致使寫操做等待時間較長，這樣就損失了一部分可用性。因此，CAP是不可能同時知足的。像支付這種場景可能會追求CP（一致性），而電商這種場景更追求AP（可用性）。
基於以上分析，就能夠引出咱們三種不一樣的數據複製方案：

• 同步複製技術，注重一致性；
• 異步複製技術，注重可用性；
• 半同步複製技術，介於前二者之間。

接下來咱們以數據庫主從同步爲例，逐一討論。

同步複製技術

同步複製技術保證的是各節點之間的數據強一致性，因此，像咱們剛纔說的那樣，在數據庫讀寫分離時，用戶更新數據的請求會打到主數據庫節點上。主數據庫必需要同步到備數據庫以後纔可給用戶返回，即若是主數據庫尚未同步到備數據庫，用戶的更新操做會一直阻塞。這種方式保證了數據的強一致性，但犧牲了系統的可用性，即CP。

這種方案適用於對數據一致性有嚴格要求的場合，好比金融、交易之類的場景。

異步複製技術

異步複製技術主要保證可用性，各節點之間容忍暫時的數據不一致，保證最終一致性便可。因此當用戶請求更新數據時，主數據庫處理完請求後可直接給用戶響應，而沒必要等待備數據庫完成同步，即備數據庫會異步進行數據的同步，用戶的更新操做不會由於備數據庫未完成數據同步而致使阻塞。這種方式保證了系統的可用性，但犧牲了數據的一致性，即AP。

MySQL 集羣默認的數據複製模式，採用的就是異步複製技術。咱們主要關注兩個關鍵的組件：binlog與relay log。
既然是異步，那麼咱們直接在主節點上執行完就能夠返回了，讓備數據庫獲取咱們的更新內容，本身去作同步就行了，不用那麼着急。因此，咱們須要找個地方記下來作了什麼操做，這裏binlog就派上用場了。MySQL會往binlog中寫入主數據庫執行的全部更新操做，以便備數據庫獲取更新信息。而後備數據庫專門啓動一個IO線程讀取binlog的內容，而後寫入本身的relay log中。備數據庫會有一個後臺線程按期檢查relay log的內容，一旦發現有更新，當即重放relay log，最終與主節點的數據達成一致：

這裏我再額外提一下relay log，網上不少文章都沒有說爲何要使用relay log。因爲relay log是在從節點那一側，那麼從節點就能夠在relay log上記錄當前同步的進度並作各類標記。就至關於把公共資源複製了一份據爲己有，我就能夠基於這份複製的東西隨心所欲了。而若是沒有relay log，直接去讀取並重放binlog的話，就無法實現了。此外，讀取binlog並直接重放bionlog這個過程，相比直接拷貝binlog的內容到relay log這種方案，多了一個重放這個步驟，這就要多佔用不少主從節點之間網絡鏈接的時間資源，致使性能降低。因此，這就是爲何要使用relay log。
異步複製技術大多應用在對用戶請求響應時延要求很高的場景。好比電商、秒殺這類場景。這時後臺的數據庫或緩存若是採用同步複製技術，用戶可能就會因服務響應速度慢而崩潰，最終致使用戶流失。所以這種場景最好採用異步複製技術，優先保證可用性。

半同步複製技術

半同步複製技術顧名思義，介於前兩種方案之間。知足了一部分可用性及一致性。半同步複製技術主要應用在一主多從場景中。主節點不用等待全部備節點同步完畢就即可以響應寫操做成功。也就是說，主節點能夠等待一部分備節點同步完成後，就能夠響應用戶寫操做執行成功。
而這裏基於要等待多少個節點響應成功纔算寫操做成功，有細分爲兩種方案：

• 主節點收到一個備節點同步成功，就返回寫操做成功；
• 主節點收到超過一半節點回複數據同步成功後，再給用戶響應寫操做成功。

這兩種方案相對而言，第一種更偏向可用性，第二種更偏向一致性。在MySQL一主多備的場景下，通常採用的是第一種半同步複製技術。而Zookeeper則採用了第二種半同步複製技術。
實際上，多數的分佈式存儲系統與中間件，能夠經過配置來選擇不一樣的數據複製技術。咱們根據咱們本身的業務場景，選擇合適的數據複製方案便可。

下期預告

【分佈式系統遨遊】分佈式緩存

關注咱們

歡迎對本系列文章感興趣的讀者訂閱咱們的公衆號，關注博主下次不迷路～