轉載於http://www.cnblogs.com/mindwind/p/4973635.html

原生複製架構

MySQL 的原生複製架構原理如上圖所示。從庫的 I/O Thread 執行緒負責不斷讀取主庫的 binlog 日誌檔案並寫入本地的 Relay log 臨時快取。從庫的 SQL Thread 執行緒則不斷讀取 Relay log 重放事件入庫。整個過程看起來是比較簡單清晰的，但其中有幾個點對主從資料一致性有關鍵影響，我們下面逐一分析。

主從複製的場景下，產生資料不一致的現象有兩種：

1. 資料丟失
2. 資料重複

從庫的 I/O Thread 是通過網路讀取主庫的 binlog 的，若出現網路故障，有可能產生資料丟失。為避免網路故障導致的資料丟失，網路恢復後從庫重新連線上來需要知道從主庫 binlog 的哪個位置重新傳輸資料。從庫需要記住中斷髮生時 binlog 的位置，並從該斷點處重新讀取，這個斷點我們稱為從庫的重傳檢查點。一個可靠的重傳檢查點必須是在從庫讀到資料並寫入到本地 Relay log 持久化之後才可建立，否則都有丟失資料的可能。

由於主從複製過程的分散式特徵，需要保證複製過程的冪等性，也就是重複複製同一條資料最終不會產生重複的資料。防重策略是必須的，一般符合正規化特徵的資料庫表設計通過主鍵來防重，而無主鍵表資料可以通過所有欄位聯合唯一索引來防重。有了防重策略就可以任意回溯複製過程，而不必考慮從庫產生重複資料。

為了保證主從資料一致性，複製過程不僅要保證不丟失、不重複，還需要保證操作順序一致。binlog 的事件日誌反應了主庫併發事務的操作序列，最終這種序列也要原樣反應到從庫上。所以原生複製架構為了做到這點，採用了單執行緒模型的序列化操作。這也是沒辦法的，因為在資料庫層面是無法知道不同資料之間的因果和依賴關係，因此無法並行入庫。

原生的複製架構做到了無丟失、無重複和順序一致性，普通場景下基本可用，但也存在一些不足：

• 可監控性、可管理性相對較弱。
• 對於異構資料無能為力。
• 通用的單執行緒模型可能成為效能瓶頸，導致複製延時過高。
• 一對多場景下對主庫形成過大複製壓力，影響主庫可用性。

一些特殊場景下的資料庫複製分佈，使用原生複製架構則不一定合適，可能的場景有：

• 大型庫，資料量大，寫入量大，還需要跨地域、跨機房的複製，而且對複製延時長短比較敏感，比如大型電商的訂單、交易類資料庫。

所以我們才需要考慮針對特殊場景自定義複製架構，下面我們看一個自定義複製架構的概念原理圖。

自定義複製架構

如上，自定義複製架構參考原生架構模擬成一個MySQL從庫，它內部包括三個主要角色：

1. Pull Worker，作用類似於原生的 I/O Thread。
2. Buffer + Persistent Storage，作用類似於原生的 Relay log。
3. Load Worker，作用類似於原生的 SQL Thread。

由於是自定義程式實現則可以在無改造 MySQL 的前提下提供額外的功能，相對應用和 MySQL 都可以做到透明。相對原生複製架構的不足，自定義複製架構可以提供更好的複製過程監控和管理能力，並支援異構資料轉換等等。而對於需要跨地域、跨機房且延時敏感的大型庫複製，則可以通過適當的策略來加速複製過程。

比如前面提到的大型電商的訂單、交易類資料庫，一般都是分庫分表的。分庫分表後，不同庫表之間的資料其實在業務上是完全獨立的，是可以支援並行寫入的。所以我們看上圖為什麼畫了兩個 Load Worker，就是表達可以針對業務獨立的表進行並行寫入。一條資料的複製延時包括：

總時長 T = P + N + L; 其中 P 是 Pull Worker 處理時長，N 是網路傳輸時長, L 是 Load Worker 處理時長。

同一個庫的 binlog 是順序的不好並行拉取，傳輸過程的網路時長也是剛性的，唯一能加速的就是入庫處理。按業務獨立的不同表可以做到並行的多執行緒入庫操作，以縮短 L 的整體時長，如下圖所示。

總結

本文分析了 MySQL 基於 binlog 的主從複製原理，從資料一致性的角度考慮分散式網路環境下主從架構設計的關鍵要素。在分析了 MySQL 原生複製架構的基礎上給出了一個靈活性和可控性更高的自定義複製架構的高層設計。理解了主從複製架構如何保證資料一致性後，我們後面才可進一步考慮在雙寫主庫的場景如何做雙向複製同步並保證雙主庫的資料最終一致性問題。這個系列下一篇文章會專門分析這個問題。

參考