背景介紹
RDS 5.7三節點企業版是孵化于阿裡巴巴集團内部的高可用、強一緻，支援全球部署的資料庫産品。該産品從2017年在阿裡巴巴集團自有業務推廣，平穩支援多年雙十一。經過2年的内部打磨，該版本在2019年7月正式上線公有雲售賣。相比RDS 5.6三節點版本，我們對核心進行的全新的設計，特别是一緻性協定方面。
三節點企業版的核心是一緻性協定。在5.7的版本，我們把阿裡巴巴自研的一緻性協定庫X-Paxos內建到AliSQL中，在100%相容MySQL的基礎上，實作了資料庫的自動選主，日志同步，資料強一緻，線上配置變更等功能。X-Paxos采用了unique proposer的Multi-Paxos實作方案，同時又做了很多創新性的功能和性能優化，是一個更具生産環境實用意義的一緻性協定。
節點角色
熟悉Paxos論文的人都知道，整個Paxos算法中包含三種角色：Proposer、Accepter和Learner。在X-Paxos中，節點的角色分為四類：
整個一緻性協定的持久存儲分兩塊：日志和狀态機。日志代表了對狀态機的更新操作，狀态機存放了外部業務讀寫的實際資料。
Leader是叢集中唯一可讀寫的節點。它給叢集所有節點發送新寫入的日志，達成多數派後允許送出，并回放到本地的狀态機。衆所周知，标準的Paxos存在活鎖的問題（livelock），即兩個Proposer交替發起Prepare請求，導緻每一輪Prepare的Accept請求都失敗，提案編号不斷遞增，陷入死循環永遠達不成一緻。是以業界的最佳實踐是選取一個主Proposer，來保證算法的活性。另一方面，針對資料庫場景，隻允許主Proposer發起提案，簡化了事務的沖突處理，保證了高性能。這個主Proposer被稱之為Leader。
Follower是災備節點，用于收集Leader發送的日志，并負責把達成多數派的日志回放到狀态機。當Leader發生故障時，叢集中的剩餘節點會選一個新的Follower更新成Leader接受讀寫請求。
Logger是一種特殊類型的Follower，不對外提供服務。Logger做兩件事：存儲最新的日志用于Leader的多數派判定；選主階段行使投票權。Logger不回放狀态機，會定期清理老舊的日志，占用極少的計算和存儲資源。是以，基于Leader/Follower/Logger的部署方式，三節點相比雙節點高可用版，隻額外增加很少的成本。
Learner沒有投票權，不參加多數派的計算，僅從Leader同步已送出的日志，并回放到狀态機。在實際使用中，我們把Learner作為隻讀副本，用于應用層的讀寫分離。此外，X-Paxos支援Learner和Follower之間的節點變更，基于這個功能可以實作故障節點的遷移和替換。
叢集管理
三節點企業版支援豐富的叢集變更和配置管理功能，列舉如下：
- Leader節點主動切換
- 加減Learner節點
- Follower降級成Learner、Learner更新為Follower
- 修改節點的選舉權重
- 修改Learner節點的複制拓撲
- 修改日志發包的配置模式（Pipelining、Batching、壓縮、加密）
- 高性能異步模式
日志
首先回顧MySQL雙節點高可用版本的複制模式。其中Master節點負責寫入binary log，并送出事務。Slave節點通過IO線程從Master節點發起dump協定拉取binary log，并存儲到本地的relay log中。最後由Slave節點的SQL線程負責回放relay log。
雙節點複制模式可以用下圖表示：
一般情況下，Slave節點還需要開啟log-slave-updates來保證從庫也可以為下遊提供日志同步，是以Slave線程除了relay log，還會有一份備援的binary log。
三節點企業版創新性的整合了binary log和relay log，實作了統一的consensus log，節省了日志存儲的成本。當某個節點是Leader的時候，consensus log扮演了binary log的角色；同理當某個節點被切換成Follower/Learner時，consensus log扮演了relay log的角色。X-Paxos一緻性協定層接管consensus log的同步邏輯，同時提供對外的接口來實作日志寫入和狀态機回放。新的consensus log基于一緻性協定和State Machine Replication理論，保證了多個節點之間的資料一緻性。此外，三節點企業版日志的實作遵循了MySQL binary log的标準，可以無縫相容aliyun DTS、Canal等業内常用的binlog增量訂閱工具。
三節點複制模式如下圖所示：
狀态機
三節點企業版的狀态機實作改造了MySQL原有事務送出的流程。
MySQL組送出（Group Commit）相關的技術文章網上有很多，原有Group Commit分為三個階段：flush stage、sync stage、commit stage。對于Leader節點，三節點企業版修改了其中commit stage的實作方式。所有進入commit stage的事務會被統一推送到一個異步隊列中，進入quorum決議的判定階段，等待事務日志同步到多數節點上，滿足quorum條件的事務才允許commit。另外，Leader上consensus log的本地寫入和日志同步可以并行執行，保證了高性能。
對于Follower節點，SQL線程讀取consensus log，開始等待Leader的通知。Leader會定期同步給Follower每一條日志的送出狀态，達成多數派的日志會被分發給worker線程并行執行。
Learner節點相對Follower的邏輯更加簡單，一緻性協定保證了它不會接收到未送出的日志，SQL線程不用等待任何條件，隻需分發最新的日志給worker線程即可。此外，三節點企業版使用特殊版本的Xtrabackup進行執行個體備份和恢複。我們基于X-Paxos的snapshot接口改進了Xtrabackup，支援建立帶有一緻性位點的實體備份快照，可以十分快捷的孵化一個全新的Learner節點，并加入到叢集中提供讀能力的擴充。
部署模式
同城三副本
同城三副本是公有雲上預設的部署模式。比較傳統的雙機房主備高可用版，三節點在滿足高可用強一緻特性的基礎上，基本不增加存儲成本：
- 三節點單機房不可用場景下資料0丢失，秒級切換，主備有丢資料的風險；
- 三節點和主備都隻存儲兩份狀态機資料；三節點存儲三份consensus log日志，而主備版本常态化有兩份binary log和一份relay log，總量基本持平。
跨域五副本
對于跨域容災場景，我們推薦跨域五副本的架構。相比簡單的搭建跨域三副本，五副本有以下優勢：
- 和跨域三副本一樣有Region級别的容災能力，鍊路上僅有少量性能損耗；
- 通過增加一個Follower和Logger節點，實作單機房故障下的同城容災，對使用者端友好；
- 通過X-Paxos的選舉權重功能，可實作定制化的region切換順序。
總結
随着目前網際網路的發展，雲上客戶對資料安全越來越重視，大量行業對資料存儲有跨機房跨地域的需求。RDS 5.7三節點企業版是基于阿裡巴巴内部自研技術的沉澱，針對資料品質要求較高的使用者，在雲上推出的資料庫解決方案。此外，對于RDS 5.7高可用版的老使用者，也支援一鍵更新三節點。
購買方式：
相關閱讀：
- 内附大神PPT | 最大化資源管理技術紅利， 阿裡雲重磅釋出RDS MySQL專屬主機組服務！
- https://developer.aliyun.com/article/742236
- 阿裡雲RDS vs 自建MySQL，這篇評測終結你的選擇困難症!
- https://developer.aliyun.com/article/742189
- 同樣是365天，但RDS for MySQL的這一年也太高産了...
- https://developer.aliyun.com/article/742127