瞭解更多PolarDB-X 內容：
https://developer.aliyun.com/topic/polardbx_release
一、DN 高可用方案
在 PolarDB-X 的系統結構中，DN 元件負責資料儲存。 一個 DN 節點是 一個 MySQL 例項。
為了資料安全，我們需要多副本，一個邏輯例項是由多個 DN 節點組成的叢集。
為了業務連續，我們需要高可用，當部分機器或網路故障後叢集依然能夠持續提供服務。
這些能力都需要 DN 節點自閉環完成，如果再引入第三方元件來管理，那麼第三方元件的高可用又將是新的問題。
單機 MySQL，或者其他資料庫，常用的高可用方案有以下幾種：
第一種是經典的一主一從結構，基於 KeepAlive 進行 HA 管理；
第二種具有更高的可靠性，可以一主多從，用更復雜的節點管理器協調系統的執行；
另外還有 MySQL 社群的多主複製，有基於共享儲存的部署模式等。
以上解決方案都有其各自適合的應用場景，但在設計上，需要考慮的問題是類似地，那就是：
理論上 CAP 中的分割槽可用性和資料一致性如何取捨？
工程上實現的複雜度、穩定性以及高可用對效能帶來的損耗有多少？
PolarDB-X 的 DN 儲存叢集採用了強一致方案，叢集透過 X-Paxos 一致性協議進行資料複製。其特點是：
1) 在有 2n+1 節點的叢集中可容忍最多 N 個節點故障；
2) 節點間資料強一致，對應用而言，RPO=0 內建了一致性協議；
3) 隱藏了複雜的節點管理邏輯。
所以，此方案的核心是一致性協議的使用。
二、X-Paxos 協議
X-Paxos 是 Paxos 協議的具體實現，基於多數派理論保證資料一致性，其理論基礎是經典的 Paxos 論文。
當協議正常運轉時，叢集中有一個 Leader 節點，其他為 Follower 節點。業務請求從 Leader 進入，Leader 將請求轉化為一條增量日誌並將日誌廣播到所有 Follower；等多數節點確認收到日誌後，Leader 將日誌應用到狀態機，返回業務響應。過程中只要多數節點健康，協議就能正常執行，且能夠保證叢集資料的強一致。另外，在協議模型中還有 learner 角色，它不參與多數派決策，只是叢集資料的訂閱者。
協議的關鍵演算法有兩部分，首先是選主，選主是一個共識的過程，保證叢集中同時只有一個 Leader 並且 Leader 已擁有達成多數派的所有日誌；其次，日誌複製，即上圖中的運轉過程。
Paxos 是分散式協議，是訊息或事件驅動的非同步處理模型。X-Paxos 測試協議元件有四個模組：網路層提供基礎的非同步網路通訊框架；演算法模組實現協議的業務邏輯，包括選主、日誌複製、源資料管理等；服務層是排程中心，負責響應定時器和網路事件，驅動演算法模組的運轉；日誌處理本屬於演算法範疇，但 X-Paxos 實現時將日誌處理邏輯抽象出通用介面，在演算法模組呼叫介面，使日誌的具體實現可以在日誌模組完成，並且可以單獨最佳化。
MySQL 是多引擎架構，事務提交分為兩階段，第一階段為引擎 Prepare， 第二階段進入 Binlog Ordered Commit。
Ordered Commit 為分組提交，又分為三個過程：Flush 將 Binlog 內容寫到 Binlog 檔案，Sync 將 Binlog 檔案內容持久化，Commit 是引擎提交。
引入一致性協議後，Leader節點上，在 Binlog 的 Flush 和 Sync 過程中將 Binlog 內容同時廣播到所有 Follower。多數派達成後，Leader 再發起最後的引擎 Commit ，以保證資料的強一致。
因為叢集中只有 Leader 提供服務，所以 Leader 的狀態對系統可用性至關重要。
Leader 任期內，所有 Follower 都不再發起選主請求，也不投票其他節點的選主請求。但是任期過後，如果 Follower 發現 Leader 已經異常，將重新發起選主；如果 Leader 發現自己和多數 Follower 的通訊異常，將自動降級，發起選主請求。
大部分情況下，叢集各節點的狀態都正常，Leader節點的主動心跳會保持他的 Leader 地位，叢集不會發生 HA 。
預設情況下，叢集內所有節點都公平選主。當希望某些節點優先對外提供服務，可以對這些節點賦予更高的選主權重。權重高的節點當選 Leader 的機率大，但這是弱限制，不保證絕對按權重選主。因為選主最基本的原則還是節點需要擁有叢集中已經達成共識的所有資料，這是絕對限制。
DN 叢集節點間同步的資料是 Binlog ，當新主被選出後，需要完成兩個步驟才能對外提供讀寫服務：一是將日誌同步給其他落後的 Follower 節點，二是將本節點 Binlog 應用到最新位點。如果需要應用的 Binlog 很多， Leader 將遲遲無法對外提供服務，從而影響系統可用性。此時 Leader 會探測其他 Follower 節點，如果發現更合適的，則會將 Leader 角色讓出。
定義叢集是否可用，最終還要看當前 Leader 能否夠提供業務服務。有時候從協議層面看，叢集是健康的，但是 Leader 節點的業務服務異常，比如磁碟滿，則此時叢集不可用。因此 Follower 節點會定期向 Leader 發起反向心跳，用於檢測 Leader 的業務服務是否正常，如果不正常則重新選主。
四、DN部署和最佳化
上圖為最常用的部署模式，三個節點參與叢集決策，一個或多個 Learner 作為訂閱者提供只讀服務。此處 Logger 不是一種新角色，在協議層面，它就是 Follower ，但它不回放 Binlog ，僅保留 Binlog ，用於整個叢集資料的強一致，能夠減少一份 MySQL 例項的資料空間，降低儲存成本。
同城 3 副本部署模式實現了三個可用區各一個節點，兩個實體節點， 一個Logger 節點，相比傳統的主備模式，基本不增加儲存成本，但是可以實現資料的強一致。
跨城 5 副本模式下，有了更多節點後，可以實現單 Region 不可用的容災，同時配合權重選主可以定製 Region 的切換順序。
以上就是是關於PolarDB-X 高可用儲存服務的整體介紹。