mysql資料庫從誕生以來就以其簡單、易用、開源為其主打特點，成為不少開發者首選的資料庫系統。阿裡在2008年開始提出"去ioe"的口号，其中，使用大量的mysql，配合業務的改造替代原有的商業版oracle系統。自此集團邁入了mysql資料庫的時代。根據阿裡交易型應用的特點，以及雙十一這樣業界罕有的需求推動下，我們在官方的mysql基礎上增加了非常多實用的功能、性能更新檔，打造了alisql這個業界響當當的mysql分支品牌。
時間很快走到2014年，随着業務高速的增長，同城主備alisql部署的方式已經無法滿足阿裡對可擴充的部署、國際化、以及容災方面的需求。“異地多活”成為了公司應用的新标準。“異地多活”也給底層的資料庫提出了新的容災要求。傳統的master-slave架構下，主備如果不使用強同步模式就會存在資料丢失的可能，然而強同步下一旦有節點異常則整體不可服務。而且這套架構下需要ha工具來進行選主的仲裁和控制。
過去阿裡巴巴的dba們開發了高效可靠的ha以及一整套工具和流程來做主備切換後資料和日志的校驗和訂正。然而我們相信技術的發展能帶來更大的運維便利性以及更好的使用者體驗。以google spanner以及amazon aruora 為代表的newsql系統為資料庫的資料一緻性給出了與以往不同的思路：基于一緻性協定搭建分布式的多副本資料庫。
本文字數近萬字，建議對資料庫感興趣的童鞋收藏細看。
alisqlx-cluster 介紹
alisql x-cluster（本文中簡稱x-cluster）是阿裡巴巴資料庫團隊推出的相容mysql 5.7，提供資料強一緻功能，支援全球部署的分布式資料庫叢集産品。
說到alisql x-cluster就不能不提其分布式核心，一緻性協定。
x-paxos是阿裡巴巴自主研發的一緻性協定庫，目标是填補市面上高性能、易接入的一緻性協定庫的空白。而市面上已開源的一緻性協定實作，包括etcd以及其他廠商等都存在或性能不夠，或功能上無法滿足複雜的現實應用場景需求的問題。
有了x-paxos，可基于它打造一套強一緻的分布式系統，x-cluster是第一個接入x-paxos生态的重要産品，利用了x-paxos實作了自動選主，日志同步，叢集内資料強一緻，線上叢集配置變更等功能。同時x-cluster基于mysql生态，相容最新版本的mysql 5.7，內建了alisql過去的各種功能增強。 mysql的使用者可以零成本遷移到x-cluster上。
整體架構
先來看一下x-cluster的基本架構：
上圖展示的是一個部署三個執行個體的cluster叢集。x-cluster是一個單點寫入，多點可讀的叢集系統。在同一時刻，整個叢集中至多會有一個leader節點來承擔資料寫入的任務。相比多點寫入，單點寫入不需要處理資料集沖突的問題，可以達到更好的性能與吞吐率。
x-cluster 的每個執行個體都是一個單程序的系統，x-paxos被深度整合到了資料庫核心之中，替換了原有的複制子產品。叢集節點之間的增量資料同步完全是通過x-paxos來自驅動，如何複制，從哪個點回放不再需要運維人員或者外部工具來介入。 x-cluster為了追求最高的性能，利用mysql的binlog進行深度改造和定制來作為x-paxos的consensus日志，實作了一系列的x-paxos日志接口，賦予x-paxos直接操縱mysql日志的能力。
為了保證叢集資料的一緻性以及全球部署的能力，在事務送出、日志複制回放以及恢複上x-cluster都進行了重新設計。
事務送出、複制流程
x-cluster的複制流程是基于x-paxos驅動consensus日志進行複制。
leader節點在事務prepare階段會将事務産生的日志收集起來，傳遞給x-paxos協定層後進入等待。x-paxos協定層會将consensus日志高效地轉發給叢集内其他節點。當日志在超過叢集半數執行個體上落盤後 x-paxos會通知事務可以進入送出步驟。否則如果期間發生leader變更，期間prepare的事務會根據paxos日志的狀态進行相應的復原操作。相比原生mysql，日志傳輸采用了多線程、異步化、batching、pipelining等優化手段，特别是在長傳鍊路的場景中，效率提升明顯。
follower節點也使用x-paxos進行日志的管理操作，為提升接收效率，收到leader傳遞過來的日志以後将日志内容append到consensus log末尾，leader會異步的将達成多數派的日志的消息發送給follower，follower的協調者線程會負責讀取達成多數派的日志并加以解析，并傳遞給各個回放工作線程進行并發的資料更新。 follower的并發回放可以有多種方式，包括按照leader上的group commit次元或者是按照表級别的次元，未來會引入最新的writeset方式來精确控制最大并發。
failover
x-cluster 隻要半數以上的節點存活就能保證叢集正常對外服務。是以當少數的follower節點故障時并不影響叢集的服務能力。當leader節點故障時會自動觸發叢集的重新選主流程。選主流程由x-paxos驅動，在paxos協定的基礎上，結合優先級推選出新的leader節點。
對于x-cluster而言，failover_time = election_time+ apply_timeelection_time代表協定選主的時間，一般在10s左右， apply_time是資料應用日志的時間，取決于回放的速度，優秀的并行回放算法能把應用日志的時間控制在10s之内。
相對來說之下leader節點故障是一個相對複雜的場景，故障包括了執行個體崩潰、伺服器當機、網絡隔離等等。
如上圖所示，一個三節點的x-cluster叢集，左邊的case是原leader a節點當機，是以b節點和c節點會在較長的時間内收不到leader的心跳，是以在一個選舉逾時周期後，b節點開始嘗試推選自己為leader，并且c節點同意，那麼b成為新的主節點，恢複服務能力。
右邊的case 是原leader a節點發生網絡分區，此時在選舉逾時後，bc兩個節點的行為和之間的case類似。 a節點由于無法将心跳和日志發送給bc兩個節點在逾時後會降級，然後不斷嘗試選自己為主，但是因為沒有其他節點的同意，達不成多數派，一直都不會成功。當網絡分區恢複後，a收到b節點的心跳，觸發leader stickness機制，a自動加回叢集。
alisqlx-cluster的優化特性
x-cluster擁有一系列的新功能和特性，以滿足不同類型的應用對于功能和性能上的需求。
跨地域部署
x-cluster的一個顯著功能就是能夠支援跨地域部署，在跨域的情況下也能保證叢集資料強一緻，擁有城市級容災的能力。即使某個城市的機房全部當機，隻要保證叢集多數派節點存活，所有的資料都不會丢失。依賴x-paxos以及資料庫核心中異步化工作線程的改造，在數十毫秒的網絡rtt（round trip time）下，x-cluster依然有非常高的吞吐性能。擁有了跨地域部署的能力,x-cluster的部署方式是非常靈活的。業務可以根據實際的業務情況以及不同的容災級别需求，選擇同機房容災，機房容災，城市容災部署，并且可以在不同的容災級别之間靈活切換。
叢集的動态配置和選舉
x-cluster支援線上叢集配置變更。包括：
增加節點下線節點
修改節點類型為一緻性節點或者是隻讀節點
修改節點優先級
修改叢集的leader
修改隻讀節點複制源
所有的上述修改配置的過程線上進行，不會阻塞業務的正常運作，叢集配置的變化也會嚴格按照paxos協定進行，記錄日志并且對應的推動狀态機變更，并且有完善的恢複機制。保證最終叢集内配置達成一緻，不會因為叢集配置變更過程中的異常導緻腦裂或者其他配置出現終态不一緻的問題。
x-cluster叢集的節點從功能上看有兩個類型，包括參與選主與多數派協定的一緻性協定節點還有隻讀節點。一緻性協定節點是x-cluster的基礎。目前一個x-cluster叢集支援至少1個一緻性節點，至多99個一緻性節點。隻讀節點可以無限擴充。使用者可以從一開始的單節點叢集開始，後續不斷根據需求擴充不同類型的節點。
優先級
應用往往對于容災後新主節點是有要求的，在原先的主節點意外當機後，新主如若落在了一個低規格的節點，那麼對于應用來說是很難接受的服務降級。 x-cluster 支援同一個叢集中的節點擁有不同的優先級，使用者可以根據實際的部署需要，在配置叢集時為每個執行個體節點設定優先級。
優先級功能主要包括以下兩方面：
權重化選主
政策化多數派
權重化選主代表選主的順序權重。隻要在選舉的時候沒有網絡隔離，選舉leader的順序會按照叢集存活節點的權重順序進行。權重越高的節點，就有更大的優先級被選為leader。我們實作了兩段式的選舉時間，第一階段是叢集内統一的租約時間，而二階段是根據權重來決定，權重越大的節點時間越短，也就是會越早發起自選舉。除此之外，還有一重權重檢測機制來保證權重優先級，節點上任時會廣播檢測一遍所有能夠聯通的叢集内節點，如果發現權重更高的節點會主動發起一次leader transfer将leader角色過繼過去。
權重化選主在跨地域部署的場景下尤其重要。跨地域的部署業務和資料庫之間的通路延時會非常敏感，如果leader節點随機的切換到了另一個地域的機房可能會導緻應用大規模的通路異地執行個體，大幅增加用戶端的響應時間。權重化選主可以完美解決此問題。按照應用的部署需求進行動态設定，非常靈活。
政策化多數派是指在事務送出日志同步過程中，哪些節點必須要日志複制完成。複制優先級分為兩檔，強複制和弱複制。标準的paxos隻要超過半數的節點同步日志即可推進狀态機，但是由于每個連接配接會自動配置設定路由的問題，可能在跨region的通路中rtt時間會有誤差。
那麼為了縮短網絡/節點故障後按照選主優先級重新選主并繼續服務的時間間隔，我們可以配置在規定日志複制到多數節點的基礎上必須還要複制到了所有強複制的節點才可以推進狀态機并傳回用戶端事務送出成功的響應。這是一個類max protection模式的設計，如果檢測到強一緻節點當機，可選擇适當的降級。
低成本副本管理
在x-cluster中，副本按照是否有資料狀态機分為普通型(normal)，日志型(log)兩類。普通型擁有全部的功能；日志型隻擁有日志不包含資料。如果日志型節點還是一個參與paxos投票的一緻性節點，那麼它隻有投票權，沒有被選舉權。
之是以要建立不同的類型的副本，還是出于應用需求以及成本控制的考慮。相比傳統的兩節點主備複制，x-cluster的正常同城部署方式是三節點。
日志型副本是作為降低部署成本的一種選擇。日志型副本隻存儲日志，不需要存儲資料，也不需要回放日志更新資料。是以無論是存儲還是cpu的開銷，日志型副本相比普通副本都有很大的優勢。在實際應用規劃中，非常适合來當作容災型的節點部署。
隻讀節點管理
如上圖所示，x-cluster叢集中的隻讀節點可以從任何一個一緻性節點複制日志，這不僅是考慮到如果所有節點的日志都從leader節點複制會對leader節點造成過大的網絡和io瓶頸，而且由于跨區域部署下不同地域的資料狀态機可能會有延時，設定了讀寫分離的使用者在特定的場景下需要有特定的隻讀狀态延時的要求。但是這時的問題就是如果某個一緻性節點發生了當機，那麼和它建立複制關系的隻讀節點應該如何進行災備關聯？
作為一個自運維的資料庫服務，x-cluster自然要解決好這個問題。x-cluster定義了learner source group。每個group是一個隻讀節點的容災單元。當group内某個一緻性節點發生意外狀況（當機或者網絡隔離）叢集會根據group的配置，将挂載在故障節點下的隻讀節點配置到group中另外一個正常工作的節點下進行資料同步。
高性能日志
mysql系統在開啟主備複制的情況下除了會記錄binlog之外，在備庫上還會記錄一份relaylog。即從庫通過指定對應主庫的binlog位置去同步一份二進制日志寫入relaylog，供複制線程讀取和回放。在x-cluster中，隻使用一份日志進行節點間的同步，利用x-paxos的插件式日志子產品的特性，每個節點有一份consensus日志。
這樣既友善了對consensus日志的管理，也降低了日志存儲以及讀寫的開銷。 consensus log擁有append，get，truncate以及purge等基本接口，它的控制權完整地交給了x-paxos，由x-paxos進行控制。除此之外，x-cluster為consensus log設計了日志索引和日志緩存、預讀機制，極大的提升了日志子產品的性能保證一緻性協定運作的高效性。
異步化事務送出
傳統的mysql都是 one thread per connection的工作模式，在引入線程池後是以一個線程池孵化一定數量的工作線程，每個線程負責處理一次query的解析、優化、修改資料、送出、回網絡包等等。叢集需要跨地域部署下，一次事務的送出由于需要在叢集之間同步事務日志，受限于網絡的rtt的限制，會達到數十毫秒的級别，那麼對于一個普通的寫事務來說，大量的時間會耗費在同步節點日志等待事務送出的過程。
在大壓力下，很快資料庫内部的工作線程會耗盡，吞吐達到瓶頸。如果一味的放大資料庫内部的工作線程數目，那麼線程上下文的代價會大幅增加。如果将整個事務的送出異步化，将工作線程從等待x-paxos日志同步中解放出來，去處理新的連接配接請求，在大負載下可以擁有更高的處理能力。
異步化改造的說明示意如下圖所示：
x-cluster的異步化送出核心思想是将每個事務的請求分成兩個階段，送出之前一個階段，送出和回包一個階段。兩個階段都可以由不同的工作線程來完成。為了完成異步化的改造，x-cluster增加了等待同步隊列和等待送出隊列，用于存儲處于不同階段的事務。前者隊列中的事務是等待paxos多數派日志同步的事務，後者是等待送出的事務。當使用者發起commit/rollback/xa_prepare時，處理使用者連接配接的線程池worker産生事務日志并将事務上下文存儲到等待同步的隊列中。等待同步隊列的消費由少量數目的worker線程來完成，其餘工作線程可以直接參與其他任務的處理。事務等待多數派完成後會被推入等待送出隊列。這個隊列裡的事務都是可以被立即送出的。所有的worker線程發現該隊列裡有事務，就可以順道取出來執行送出操作。
這樣一來，系統中隻有少數的線程在等待日志同步操作，其餘的線程可以充分利用cpu處理用戶端的請求。 x-cluster以這樣的思路為指導原則，結合mysql的group commit邏輯，将原有需要等待的操作全部異步化，讓worker線程可以去執行新的請求響應。在測試中，異步化改造在同城部署的場景中相比同步送出有10%的吞吐率提升，跨區域的部署後有幾倍的吞吐提升。
熱點更新
熱點更新原本就是資料庫的一個難題，受制于行鎖競争，性能吞吐一直很難提升上去。x-cluster面對跨域場景下的長傳網絡更加是雪上加霜，送出的時間變長，事務占據行鎖的時間也顯著增加。
為了解決此問題，x-cluster在單機版alisql的熱點功能之上優化了複制，使得在保證資料強一緻的情況下，熱點更新性能提升200倍。
如上圖所示，x-cluster針對熱點行更新的基本思路是合并多個事務對同一行的更新。為了讓批量的更新事務能夠同時進行送出，x-cluster增加了一種新的行鎖類型——熱點行鎖。熱點行鎖下，熱點更新的事務之間是相容的。 x-cluster為了保證資料的一緻性，對同一批的熱點更新事務日志打上特殊标志， x-paxos會根據這些标志将這一整批事務的日志組成一個單獨的網絡包進行叢集間的資料同步，保證這些事務是原子的送出/復原。除此之外為了提升日志回放的效率，x-cluster将每個批次事務中對于熱點行的更新日志也做了合并。
一體化的用戶端和服務端
x-cluster有完整的client-server生态。是以整個系統不需要外部元件的介入，能夠自封閉的成為一個生态閉環。作為用戶端的x-driver能夠訂閱server端發生的一切改變，進而進行自動尋主，執行個體清單動态維護等功能。用戶端的中繼資料就儲存在x-cluster服務内部。相比外置的中繼資料中心，這套自封閉體系能夠以最快的時間擷取到準确的叢集變化。降低叢集變更對使用者的感覺程度。
優化的備份以及資料訂閱體系
基于強大的x-paxos體系，日志備份以及資料訂閱系統都能夠以日志訂閱者的方式接入進來。由于有了x-paxos的全局唯一位點支援，這些訂閱系統的failover不再會有難以找到準确位點的困擾。而且由于x-paxos是流式的推送日志消息，是以資料的實時性也能大幅改進。
alisqlx-cluster 實戰部署方案
x-cluster最為經典的兩個部署方案是同城3副本，兩份資料一份日志。以及跨地域5副本，四份資料一份日志。分别用于滿足機房級容災和城市級容災需求。這裡的副本概念指的都是一緻性節點的部署，隻讀節點部署不影響容災能力。這兩類經典的部署方案都是考慮了可用性以及成本之間的權衡，以較小的代價換來目标的容災能力。
x-cluster的同城部署三副本能夠友善的實作零資料丢失的執行個體容災以及機房級容災。相比主備方式，額外增加了一個日志節點，換取強一緻以及可用性。
三地五執行個體（四資料、五日志）能夠保證城市級容災，如圖所示，任何一個城市的節點全部當機都不會影響到叢集可用性，5個節點中至少還有3個節點是能夠正常運作的。在日常運作中，5節點在每次事務送出的時候必定需要将日志同步到3個節點，是以必然會出現一次跨域的網絡同步，這也就是長傳鍊路網絡場景，x-cluster對于慢網絡的優化正是應對類似這樣的需求。
alisqlx-cluster 性能表現
我們使用了三節點部署的方式，分别在同域三機房、跨域三機房的網絡環境下進行了測試。測試工具使用标準的sysbench的 insert/oltp， insert測試下，并且每個事務中隻包含一條插入語句，屬于密集的小事務場景，而相反的oltp是讀寫大事務。針對熱點環境，測試的場景是改造update_non_index ，使更新同一行資料。隻讀場景不在本次測試的範疇内，原因是隻讀不涉及到節點的日志、資料同步，是以可以認為隻讀測試對于x-cluster這樣的分布式系統是沒有意義的。所有的測試，資料量為10張表，每張表20萬條記錄。
作為對比，我們使用了最新的開源單機版mysql 5.7.19 以及該版本下的group replication。group replication在測試中關閉限流。
測試機均是64core 256g記憶體 pcie ssd。
測試同域下的叢集，insert我們使用300并發線程、 oltp使用400并發線程，熱點更新使用300并發線程。
在同一個域下，x-cluster的吞吐和響應時間表現都是非常出色的，甚至略好于單機版本的mysql 5.7.19。相比group replication，在本次測試的壓力下，insert case x-cluster有超過一倍的吞吐以及55%左右的響應時間，oltp case x-cluster 有超過5%的吞吐以及接近70%的響應時間表現。
測試跨域下的叢集需要大量的連接配接來保證吞吐，是以insert使用2000并發線程，oltp使用700并發線程，熱點更新使用2500并發線程。
當叢集部署在不同域時，x-cluster和group replication相比同域的部署下吞吐都有下降，響應時間收到實體網絡延遲的影響也有顯著提高，然而在insert case下，x-cluster仍然可以領先group replication 5倍，響應時間隻有gr的四分之一。oltp case下，x-cluster 的吞吐領先group replication接近4倍，響應時間隻有三分之一。
熱點更新是x-cluster的一大亮點功能，根據測試結果，無論是同域還是跨域部署， x-cluster的吞吐和響應時間表現都要遠遠超過單機mysql和groupreplication。
alisqlx-cluster正确性保障
分布式系統的測試是非常複雜的，因為沒有人能夠通過窮舉來羅列所有可能出現的情況。簡單的接口測試和性能回歸也隻能覆寫一小部分場景，無法來衡量一個分布式系統版本的品質。隻有日複一日的測試以及線上系統的正常運作能夠真正地說明分布式系統的魯棒性。
x-cluster最大的挑戰就是保證其基于分布式一緻性協定實作的正确性。經過實踐證明，灰盒測試時最有效的手段。x-cluster內建了x-paxos，x-paxos項目本身有一系列的測試架構用于發現和回歸。除此之外x-cluster基于tc、systemtap等工具建構了多種多樣模拟網絡異常、執行個體當機、i/o異常的環境。在這套環境下網絡分區、丢包、各種io異常，各種執行個體當機可以随機組合。同時使用benchmark工具對每個節點施加大壓力的讀寫，定期的去校驗叢集中不同節點的資料以及日志的一緻性。一緻性相關所有的操作都會記錄在x-cluster專門的日志中，友善追溯叢集節點間的互動行為。資料和日志的最終一緻性校驗交由外部系統來完成。
阿裡内部有專門的分片校驗系統可以做x-cluster不同節點的全量資料校驗。 consensus日志解析工具可以快速解析日志内容進行比對。這套測試環境幫助我們發現了非常多的系統bug。包括執行個體恢複的bug，網絡異常導緻的bug等等。我們認為一個穩定的版本的标準是一定需要通過這個場景長時間的測試并各種表現符合預期。
除了資料和日志的最終一緻性，對于資料的線性一緻，事務隔離性，我們引入了jepsen工具。jepsen幫助了大量分布式系統發現了分布式協定和實作的正确性問題。我們為x-cluster專門構造了一系列的測試用例來盡可能覆寫各種異常場景，來發現系統在隔離性和一緻性上的問題。
alisqlx-cluster與同類的對比
alisql x-cluster不是第一個基于mysql的強一緻叢集方案，然而是最适合阿裡這樣體量的公司的資料庫解決方案。對比下面這些同類産品：
galera
galara是mariadb支援的mysql叢集版本，支援強同步，支援多點寫入，支援自動的叢集配置以及節點failover，支援行級别的并行複制，支援原生的mysql用戶端。在這套架構下，slave不會有延時，任意節點讀到的都是一緻資料，不會有事務資料丢失，讀寫可擴充。
galera的叢集通信是用了一種基于單令牌環的totem多點傳播協定。為了能支援多點寫入，主機在收到寫請求後，會原子廣播到組内所有的機器，由它們各自的事務管理層來決定是送出或者復原。多點傳播由于是p2p的通信，随着節點數增加，延時會放大，響應時間會變慢，并且隻适用于低延時的區域網路。除此之外多點傳播還有一個問題，如果組内的某台機器當機，多點傳播會逾時，在踢掉fail的機器重新确定組内成員關系之前，整個叢集不可服務。
galera 采用了專門的檔案gcache進行增量狀态複制，gcache不做任何他用，是以gcache本身需要 額外的計算和存儲代價進行維護
groupreplication
group replication是mysql 官方出品的叢集方案。group replication多少是借鑒了galera的思想，同樣支援多主多點寫入。group replication實作了一個x-com的通信層，其新版本中已經使用了paxos算法。目前一個gr叢集中最多可以有9個節點，響應延時相對穩定，在節點同步日志層面， gr使用binlog，相比galera更加的通用。
group replication的協定層複制是xcom，且在複制中強依賴gtid。在測試中的性能表現，特别是跨域部署下還達不到需求，目前的版本中也仍然有大量的bug在修複，完全可用于生産環境還有待後續版本的穩定性和性能提升。
總結
x-cluster是針對資料品質要求較高的使用者推出的全新的資料庫解決方案。x-cluster不僅能夠享受到開源社群帶來的紅利，其中涉及一緻性的關鍵的技術也能夠做到完全的自主、可控，能夠針對業務的需求進行靈活的變更。未來 x-cluster會在此基礎上做更多的優化，例如支援多分片的paxos，多節點提供強一緻讀等功能。随着x-paxos和alisql的不斷進化，x-cluster也給大家會帶來更多的驚喜。
來源：阿裡技術
<a href="http://mp.weixin.qq.com/s/4lz7my6cs4-vjq1qghqxzg">原文連結</a>