RDS 5.7三節點企業版是阿裡自主研發，完全相容MySQL生态的全球級分布式強一緻的關系型資料庫。從2017年開始在集團大規模使用，目前不僅服務了天貓/淘寶核心交易系統，還在螞蟻，菜鳥，釘釘，盒馬，優酷，高德，口碑等阿裡子BU大量使用，這篇我們來看看ALISQL金融三節點的具體應用場景。
一.RDS 5.7三節點企業版的核心優勢
上篇我們介紹了RDS 5.7三節點企業版資料一緻性解決方案，這個章節我先對RDS 5.7三節點企業版的核心優勢做下簡單彙總。
1.資料強一緻能力
RDS 5.7三節點企業版在AliSQL的基礎上內建了X-Paxos。借助X-Paxos的分布式一緻性算法，RDS 5.7三節點企業版從功能層面可以徹底解決資料品質問題，讓RDS 5.7三節點企業版從AliSQL時代的資料一緻性問題中徹底走了出來，從借助生态解決一緻性問題，更新到産品内部一體化方式來徹底解決。
2.RDS 5.7三節點企業版的性能優化
我們都知道強一緻一定帶來性能的下降，我們來看在RDS 5.7三節點企業版上我們做了哪些優化，來提升吞吐和性能。
1).一體化的日志設計
RDS 5.7三節點企業版的Consensus日志是合并了原有的binlog和relay_log， 但是保留了原有的MySQL binlog的事務日志格式。一體化日志帶來的好處首先是減少一份日志的寫入；其次掃描日志可以做到順序IO，這個點尤其對Paxos算法下日志的檢索和擷取效率是一個提升。
2).異步事務送出
首先X-Paxos完全基于多線程實作，可以在單個分區Paxos中完全的使用多線程的能力，所有的任務都有通用的worker來運作，消除了CPU的瓶頸。在這個基礎上，我們在服務層對事務流程進行拆分（處理請求→等待同步→事務送出），不同階段由線程池的不同線程完成。借助X-Paxos的多線程模式以及服務層的異步化改造，系統吞吐有很大的提升。尤其在跨域或者跨國場景下，巨大的網絡延遲使得線程池成為一種瓶頸：實際運作中會發現線程池絕大部分線程在等待日志跨單元同步回包，服務端就沒有足夠的線程去處理客戶請求。
3).Batching &Pipelining
X-Paxos針對高延遲網絡做了大量的協定優化嘗試和測試，并結合學術界現有的理論成果通過合理的Batching和Pipelining，設計并實作了一整套自适應的針對高延遲高吞吐和低延遲高吞吐網絡的通信模式，極大的提升了X-Paxos的性能。Pipeling的引入，需要解決日志的亂序問題，特别是在異地場景下，window加大，加大了亂序的機率。X-Paxos實作了一個高效的亂序處理子產品，可以對底層日志實作屏蔽亂序問題，實作高效的亂序日志存儲。
如上幾個點的優化，保證了RDS 5.7三節點企業版在同城多機房部署或者跨域多單元部署時，寫入性能和單節點模式（非強一緻）無大幅度劣化。如上功能的提供以及性能優化讓RDS 5.7三節點企業版真正能解決一緻性問題，同時通過近兩年在集團的推廣使用也驗證了RDS 5.7三節點企業版的可靠性和完備性。
3.多種角色及動态變更
除了一緻性的解決外，RDS 5.7三節點企業版還借助了X-Paxos強大的生态功能，增加了RDS 5.7三節點企業版的靈活性，展現在如下幾個點上：
1).友好的管控操作：支援線上添加&删除節點，支援線上轉讓leader；
2).政策化多數派和權重化選主：可以讓業務根據自己的部署特點自行配置；
3).節點角色定制化：經典的multi-paxos實作中，一般每個節點都包含了Proposer/Accepter/Learner三種功能，每一個節點都是全功能節點。RDS 5.7三節點企業版支援三種功能的獨立配置，将Paxos算法中節點的三個功能進行了剝離和重組，形成了多種不同角色的節點。具體如下：
4).SDK模式:我們把learner角色封裝成一個SDK，通過SDK，可以快速實作RDS 5.7三節點企業版和下遊各系統的對接，閉環形成完整的生态。比如：基于訂閱者功能，我們可以實作日志的實時備份、下遊的增量實時訂閱消費等功能。如下是一個線上叢集的真實運作案例。
二.常見的RDS 5.7三節點企業版的部署模式
我們現在知道RDS 5.7三節點企業版不僅做了高性能的強一緻，而且能為業務提供靈活豐富的部署模式。下面我們來看下在阿裡應用的幾種部署模式。
1.同城跨機房模式
部署模式圖
特點
1).機房級别容災，資料零丢失，10秒級别的容災能力；
2).部署采用兩資料副本，一日志節點（無資料，同時最低配置）。相比主備方案成本增加很有限；
3).備份接入SDK後，RPO<1秒。 這個模式是集團最常用的模式，對該模式進行各種擴充，可以到下面幾種模式（擴充的模式都具備了備份RPO<1秒的能力）
2.跨域高性能模式
1).機房級别容災能力的基礎上，具備跨域接流能力。
2).高性能：該模式是在同城達到強同步，對于寫業務性能相對跨域強同步是有很大提升的。
3).模式擴充能力：在該模式下，華南region異常時，華南region的業務會讀站華北；
如果想要同城容災能力，可以在華南region再加一個learner節點，添加這個節點對業務寫性能無任何影響。 3.跨域強同步模式
1).真正的跨域強一緻能力：任意城市不可用，不影響叢集的可用性，資料零丢失。
2).靈活的切換政策：可設定同城節點，跨域節點的切換優先級。
3).靈活的伸縮能力：該部署模式可以在面臨大促等需求時，可以動态将跨域強同步模式切換到跨域高性能模式：在保證機房級别容災的基礎上，擷取更高性能。 業務應用實踐案例
我們看到阿裡内部常用的幾種部署模式後，接下來我們看下RDS 5.7三節點企業版結合具體業務的應用擴充案例。我們最常用的結構是同城跨機房部署模式，這種模式用最小成本給業務帶來了強一緻，剛開始隻在金融、結算等對一緻性要求極高的業務線落地，随着推廣和産品的完備，該部署模式是同城容災的預設部署模式。
在之前的單元化、區域化等項目中，單元之間同步都依賴DTS來完成。在有了RDS 5.7三節點企業版之後，鑒于RDS 5.7三節點企業版在跨單元的性能優化，對于跨域同步需求，RDS 5.7三節點企業版内部就可以直接完成。借助多角色能力，優酷通過在香港單元動态擴充一個Leaner角色的節點實作“優酷出海”；同時中心化單元架構也都演進了RDS 5.7三節點企業版的跨域高性能模式。接下來我們來介紹一個跨域高性能模式下的一個極緻優化案例。
1.交易庫存大促方案
交易庫存作為交易鍊路的核心系統之一，承載着淘寶、天貓、航旅、大麥等業務的庫存扣減。對阿裡單元化了解的同學基本都清楚，交易單元化是從買家次元進行的拆分，使得交易在多個單元都可以為買家提供服務。而庫存由于跟買家和賣家都相關，采用的是中心模式的單元化架構。是以在資料庫架構上選擇了RDS 5.7三節點企業版的跨域高性能模式。下面我們看下在面臨雙十一極限流量挑戰時，我們的應對政策。
1).一鍵切換級聯複制模式
我們先看下庫存的日常級聯模式，如下圖：
在這個模式下，leader需要給5個節點發日志，在性能壓測階段，我們發現leader的TPS到6W時，熱緩沖區鎖的争搶導緻出現性能瓶頸。單元同步改到中心follower節點後，leader節點的RT大幅下降。如下是大促級聯模式圖以及壓測結果對比。
2).弱一緻模式
通過該參數weak_consensus_mode可以打開RDS 5.7三節點企業版同步的弱一緻模式，打開後，事務送出無需再等待達成多數派。當然打開後，資料一緻性會回退到主備模式，我們目前就隻在大促開始高峰期開啟。高峰期過後，這個參數就會恢複。
3).熱點更新以及熱點更新下的同步性能優化
熱點更新原本就是資料庫的一個難題，受制于引擎内部的行鎖競争，性能吞吐一直很難提升上去。RDS 5.7三節點企業版面對跨域場景下的長傳網絡更加是雪上加霜，送出的時間變長，事務占據行鎖的時間也顯著增加。為了解決這個問題，RDS 5.7三節點企業版在原AliSQL的熱點功能上優化了複制，使得保證資料強一緻的情況下，熱點更新性能提升200倍。
如上圖所示，RDS 5.7三節點企業版針對熱點行更新的基本思路是合并多個事務對同一行的更新。為了讓批量的更新事務能夠同時進行送出，RDS 5.7三節點企業版增加了一種新的行鎖類型——熱點行鎖。熱點行鎖下，熱點更新的事務之間是相容的。 RDS 5.7三節點企業版為了保證資料的一緻性，對同一批的熱點更新事務日志打上特殊标志， RDS 5.7三節點企業版會根據這些标志将這一整批事務的日志組成一個單獨的網絡包進行叢集間的資料同步，保證這些事務是原子的送出/復原。除此之外為了提升日志回放的效率，RDS 5.7三節點企業版将每個批次事務中對于熱點行的更新日志也做了合并，保證了庫存單元和DTS的延遲。
經曆連續兩年雙十一的大考，高流量高性能驗證了RDS 5.7三節點企業版的穩定性和極緻性能。
2.菜鳥電子面單異地容災方案
在主備同步時代，我們隻需要關注主備資料在主庫當機時的一緻性問題。到了DTS鍊路的單元化架構時，我們的資料一緻性問題被放大很多：跨單元的資料一緻性如何保證？面對單元化架構的異地容災，HA應該如何切換？DTS的位點如何關聯？我們來看下菜鳥電子面單的異地容災場景下的解決方案。
菜鳥電子是菜鳥網絡聯合快遞公司向商家提供的一種物流面單服務，商家在ISV軟體提供商發貨時，會通過電子面單擷取物流包裹資訊，列印後傳遞快遞公司攬收派送。電子面單打單量巨大，而且服務可用性要求非常高（5個9），一旦服務異常，大量商家無法發貨，嚴重影響物流時效，甚至帶來社會影響。同時電子面單對資料一緻性要求很高：電子面單的一個大核心功能是給物流商提供唯一的面單序列号，這個序列号作用于物流的整個生命周期，而如果出現序列号錯亂可能會導緻包裹無法攬收，物流詳情錯亂等業務影響。綜上我們把這裡的業務需求轉換為技術要求：資料強一緻和跨域容災能力。同時從資源成本考慮，業務不僅是異地部署，是要達到雙活。
是以在資料庫層面我們采用了RDS 5.7三節點企業版跨域強同步模式，在這個模式下，應用層節點寫leader，leader寫入後強同步到異地follower節點，保證了多地域的資料強一緻；對于跨域寫leader這塊，業務通過定制化連接配接池、Batch SQL送出等技術，把異地網絡耗時降到最低，保證了異地雙活鍊路的服務可用性。應用讀服務采用讀本地政策。另外從成本考慮，華東Follower節點我們也調整為Log節點。具體的業務部署圖如下
接下來我們重點看下網絡耗時減小的優化方案：
1).事務專用連接配接池
系統原本使用的資料庫中間件對連接配接池的管理上使用的是auto_commit是true，這樣每次事務執行時，都會存在auto_commit設定以及複位帶來的DB互動。考慮到跨域網絡延遲加大，業務層面自行維護了一個事務專用連接配接池，讓這些連接配接的auto_commit屬性持續保持是false。同時在事務通路上，我們結合了特有的hint（COMMIT_ON_SUCCESSROLLBACK_ON_FAIL），減少單獨一次的commit或者rollback帶來的網絡互動。這樣在事務層面把網絡耗時減到最小。
2)事務内多條SQL請求批量合并
預設情況下，MySQL JDBC驅動不支援BATCH，當業務層發起多條SQL請求時，JDBC驅動會将所有語句拆散，串行發送到服務端執行。該種模式在跨地域寫的場景下，每一條SQL執行，都會帶來40ms跨城耗時疊加。考慮到該點，我們在業務層對JDBC驅動配置進行了調整，利用rewriteBatchedStatements + allowMultiQueries，最終将事務中所有多條寫SQL語句一次性批量發送到DB服務端執行，去除了原有串行執行的網絡開銷。
通過在業務層面的兩個優化，我們把原本270ms的跨域事務寫耗時降低到了70ms，與中心互動次數從原有6次降低到1次。
這樣我們在菜鳥電子面單業務上，結合RDS 5.7三節點企業版以及業務優化最終做到了：
1).容災演練:同城容災時，會根據我們的權重配置，優先切換到同城（華北）的follower節點。當華北地域有異常時，剩餘華南華東節點會重新選主，切主到華南follower，由于節點資料保持強一緻性同步，該部署架構下，切主無資料品質風險。實際演練資料是23s完成中心leader 切主到異地follower節點。
2).雙活性能方面:經過如上的應用層網絡耗時的優化，電子面單整體叢集采用華北中心-華南單元雙活分流，其中華南叢集承擔超過20%取号流量，由于啟用了雙活RT優化，華南單元取号接口RT穩定保持在90ms左右，與華北中心RT差距<30ms，系統成功率持續大于99%。
如上介紹了RDS 5.7三節點企業版在雙十一大促庫存場景下的極緻優化案例，以及菜鳥電子面單業務跨域強一緻、跨域容災架構下的極緻優化方案。這些案例都是極緻情況下的極緻優化，對于大部分業務來說，RDS 5.7三節點企業版 常見的部署模式完全可以适用。
綜述
該專題系列圍繞着“去IOE”後，阿裡巴巴資料庫在資料一緻性上的解決方案。在MySQL主備模式下，我們借助一些功能更新檔以及周邊生态的建設來盡量保證單機，主備叢集，單元化架構下的資料一緻性問題。到了RDS 5.7三節點企業版時代，我們借助他強大的一緻性功能以及極緻的性能優化，做到了完全為資料一緻性負責。同時借助RDS 5.7三節點企業版靈活的部署模式，讓阿裡的資料庫架構在RDS 5.7三節點企業版時代都有了新的更新。随着RDS 5.7三節點企業版成為金融三節點（5.7）産品正式上雲，期待可以為更多的使用者帶來更多的技術紅利。RDS 5.7三節點企業版作為一個新的資料庫産品，大家有任何問題，都歡迎通過
雲上資料庫專家服務聯系我們。