本文作者：胡煒，阿里雲資料庫資深技術專家
阿里雲RDS for MySQL企業版最大特點是採用了與社區版不同的複製技術，讓數據在不同的MySQL實例節點之間傳播。複製基於Paxos協議，能夠確保任意1/2的節點宕機或者故障都不會影響集群數據的一致性，讓MySQL服務擁有真正的RPO=0的能力，可以應對對數據安全性、一致性有高要求的應用場景。
企業版RDS for MySQL的核心複製技術是X-Paxos。MySQL官方的半同步複製也能夠在大部分場景下保證主備之間的數據一致。從實現來說X-Paxos 維護著多個節點的Paxos日誌狀態機以及數據狀態機，是一個遠複雜於MySQL半同步複製的複製技術，那在正常的運行狀態中，是否X-Paxos的複製就會比半同步更慢呢？首先我們回顧一下兩者的技術實現。
MySQL半同步複製的實現是建立在MySQL異步複製的基礎上的。在開啟半同步複製時，Master在返回用戶的提交之前會等待Slave的響應。當Slave超時時，半同步複製退化成異步複製。這也是為什么半同步無法確保100%用戶數據不丟失。
具體的流程如下圖：當用戶在Slave 伺服器上執行start slave命令之後，開始進行主從複製，Slave伺服器的IO線程會通過在master上已經授權的複製用戶權限請求連接master伺服器，並請求從binlog日誌文件或者是某個GTID之後的指定位置之後開始發送binlog日誌內容。Master伺服器接收到來自Slave伺服器的IO線程的請求後，Master Dump線程會根據Slave伺服器的IO線程請求的信息連續讀取指定binlog日誌文件指定位置之後的binlog event，逐個發送給Slave的IO線程。當Slave伺服器的IO線程獲取到Master發送的日誌後會將binlog日誌內容依次寫到Slave端自身的Relay Log文件，SQL線程會實時檢測本地Relay Log 中IO線程新增的日誌內容，然後及時把RelayLOG 文件中的內容解析成sql語句並應用到當前的資料庫中。
半同步的實現是讓Master在執行完客戶端事務提交之後不立刻返回給客戶端，而至少等待Slave接收到事務的日誌並且寫入到relay log 之後才返回給客戶端。因此能夠提高安全性，確保用戶已經提交的數據，至少存在於Master和一個Slave，確保單點故障不會讓用戶提交的事務丟失。RDS企業版的複製是一個純異步，流水線驅動的Paxos協議庫來驅動的，企業版在使用X-Paxos庫的時候使用binlog作為Paxos日誌，當集群中的多數派接收到事務日誌後返回客戶端提交，除此之外X-Paxos使用了高效的並行技術以及傳輸技術來保障複製的效率。X-Paxos自己管理集群實例，包含了自動選主以及日誌複製能力。企業版本的複製是默認啟動的，複製的流程和社區版本的MySQL也存在著一些區別。用戶在提交階段生成binlog之後， X-Paxos就會將其打包發往其他的節點。等到多數派的節點日誌寫入binlog後，客戶端會收到事務提交成功的請求。我們在相同的環境部署了RDS企業版以及社區的MySQL 5.7 ，實驗使用硬體均為8C32G， 兩個節點之間的網絡RTT為1ms。測試場景我們採用Sysbench的 insert 純寫，純寫場景非常考驗日誌同步的效率。下圖的對比結果橫軸代表並發請求數目，縱軸代表QPS，單位為萬。
為什麼會有這樣的差別呢？對比事務的響應時間，以及網絡帶寬，我們發現雖然X-Paxos的複製耗時略長一點，但是企業版在運行期間網絡帶寬使用是明顯高於社區版本半同步的。這說明企業版RDS的X-Paxos複製技術的並行度更好，這也就能解釋為什麼測試結果吞吐會有差別，而且這樣的優勢會隨著網絡RTT的增加而增加。接下來就介紹一下
RDS企業版的複製是怎麼做的。X-Paxos採用了全異步的事件驅動框架，日誌的產生、投遞、傳輸都是由一個統一的線程池來進行調度，並且通過多個IO線程來響應各種變動的事件，異步化的好處是能夠充分利用CPU，避免無謂的同步等待，換取最大的QPS吞吐。目前在單個分區Paxos中可以完全的使用多線程的能力，所有的任務都有通用的woker來運行，消除了CPU的瓶頸。依賴於服務層的多線程異步框架和異步網絡層，X-Paxos除了必要的協議串行點外，大部分操作都可以並發執行，並且部分協議串行點採用了無鎖設計，可以有效利用多線程能力。社區版MySQL的複製採用了單線程同步發送的方式傳遞Binlog。X-Paxos針對高延遲網絡做了大量的協議優化嘗試和測試，通過合理的Batching和Pipelining，設計並實現了一整套自適應的針對高延遲高吞吐和低延遲高吞吐網絡的通信模式，極大的提升了日誌傳輸的性能。
· Batching：X-Paxos將多個日誌合併成單個消息進行發送；Batching可以有效的降低消息粒度帶來的額外損耗，提升吞吐。但是過大Batching容易造成單請求的延遲過大，導致並發請求數過高，繼而影響了吞吐和請求延遲。X-Paxos有一套自適應的動態調整機制，決定batching的大小，提升吞吐。
· Pipelining：在上一個消息返回結果以前，並發的發送下一個消息到對應節點的機制，通過提高並發發送消息數量（Pipelining數量），可以有效的降低並發單請求延遲，同時在transmission delay小於propagationdelay的時候（高延遲高吞吐網絡），有效提升性能。Pipeling的引入，需要解決日誌的亂序問題，特別是在異地場景下，window加大，加大了亂序的概率。X-Paxos實現了一個高效的亂序處理模塊，可以對底層日誌實現屏蔽亂序問題，實現高效的亂序日誌存儲。在帶寬有限的情況下，對傳輸的日誌進行壓縮可以有效的節約傳輸帶寬提升吞吐，社區版本的MySQL是採用默認的序列化方式將binlog以字節流的方式傳輸到Slave端， X-Paxos可以對binlog進行可選擇性的壓縮。目前可以選擇的包括lz4和zstd壓縮算法，兩者都能夠在壓縮率以及壓縮解壓速率上有非常好的平衡，在測試中能夠有效的將傳輸量壓縮到5倍以上，而延遲上只有略微增加，這是CPU和帶寬之間的平衡，可以根據不同的網絡情況使用不同的壓縮技術。阿里雲RDS企業版更換了複製的方式之後
獲得了強大的一致性能力，並且在傳輸方面做了一系列的優化來確保複製的吞吐和性能，特別是在高延遲下，可以有效控制帶寬獲得儘可能大的吞吐。社區的Group Replication也在這條道路上不斷演進。社區版本的異步複製以及基於異步複製的半同步在傳輸速率上卻一直沒有太大的進展。如果用戶有跨機房跨AZ的容災部署需求時，傳統的半同步複製方式有時會成為系統吞吐的瓶頸，此時
RDS企業版可以成為一個更好的選擇。