886
AliSQL 引領開源技術變革之路
首屆阿裏巴巴中間件技術峰會上，阿裏巴巴數據庫資深專家何登成帶來“AliSQL 引領開源技術變革之路”的演講，本文從回顧AliSQL發展史開始談起，接著分析了X-KV接口的好處，最後著重分享了X-Cluster——AliSQL集群解決方案。
以下是精彩內容整理：
AliSQL發展曆史簡要回顧
為了去IOE，從2010年我們選擇Alibaba的MySQL分支AliSQL。
我們為什麼發展一個MySQL分支呢？最主要的思考還是在於生態，當我們去選擇開源數據庫時，我們會發現MySQL的整個生態、社區對於其它數據庫來說是龐大的。我們發展MySQL開源分支是因為開源數據庫在Alibaba體量下還是會碰到許多問題，比如性能、功能和可運維性，我們都作了相應優化。
在2010～2016期間，我們做了100+ 項的優化，包括bug 修複、功能增強、性能突破和可運維性的增強，目前為止，ALiSQL很多的新功能都被吸收到了開源數據庫中。
圖為AliSQL精簡架構。我們在各個核心模塊都做了改進，比如Binlog、Read View等等。
功能和可運維增強也有很多改進，我們不僅僅是在使用，而是真正做了很多創新，這些創新我們也會回饋給社區。
X-KV：高性能K-V接口
X-KV是AliSQL高性能K-V接口，InnoDB Memcached Plugin的擴展。
為什麼需要X-KV？左圖是比較經典的部署，有前端的用戶請求、數據庫，數據庫擴展性能時會在數據庫和應用層之間加cache，訪問頻率比較高的放到緩存和內存中，用緩存區域查詢問題是目前通用的解決方案，但它不一定是最好的。那麼，我們如何保證數據和緩存的數據一致性呢？我們探索從KV接口直接訪問存儲引擎中的數據，這樣可以繞過MySQL Server層的很多複雜邏輯，比如Parse、Optimize、Execute和數據的轉換、投影等。
X-KV的具體優化如下：
- 我們將Data Type支持能力豐富了，不光支持Float/Double、Integer、Decimal，還包括DateTime、Char/Varchar、Custom Format。
- 用KV訪問數據支持的接口比較有限，我們在功能上也做了增強，比如Multi get from multi tables，Non-unique index，composite indexes & prefix search，能夠覆蓋更多的場景。
- X-KV新協議。InnoDB Memcached Plugin存在一些問題，通過指定delimiter來區分每一列，delimiter如何選擇？NULL和空值無法區分，NULL = 空。
X-KV新協議將以上問題解決了，我們將返回的Field=Meta Info + Data,加Meta Info來描述返回數據，Meta Info有Version|Count|Length1|Length2|Length3…
- 可運維性優化。官方設計不考慮太多運維性，導致InnoDB Memcached Plugin存在一些問題，比如表結構變更後，如何使得KV接口能夠無縫的切換到新的schema， 原有的plugin uninstall ->install 方式對業務有較大影響。X-KV通過擴充Container表，支持了在線的KV配置變更，通過版本號來控製新舊版本的schema配置並自動重新加載。
- 性能優化。
0
我們模擬阿裏的交易數據庫上的Query請求做了驗證，相對於走SQL，我們提升了5倍左右的性能。
X-Cluster：AliSQL集群解決方案
為什麼做X-Cluster呢？
1. 首先是數據一致性的問題。傳統的數據庫都是主備的異步複製，異步複製帶來的是數據質量問題；官方為了解決問題，提出半同步複製，但半同步複製過段時間會降級。所以它們都很難百分百保證數據質量。
2. 持續高可用問題。當我們搭建完MySQL主備後，主備本身不會做切換，不會做高可用，真正的高可用是在主備之外使用一個外部組件，比如基於zookeeper的HA來提供高可用功能。
3. 區域化/全球化部署問題。過去幾年我們分享最多的是異地雙活和異地多活，我們要做到真正多城市多活高可用，需要集群能耗跨城市部署，跨國際部署。
4. 上下遊生態聯動。我們的數據庫不僅僅作數據存取，下遊還要給其他係統作消費。
能不能用一種技術嚐試解決掉這些問題呢？這是我們做X-Cluster的初衷。
我們的設計目標是：
- 一體化架構：運維友好
- 極致性能：同城三副本相對於單機性能下降在10%以內
- 可異地部署：異地部署，延時增加，但是保持高吞吐
- 穩定性：網絡抖動高容忍性
- 兼容性：對原有生態100%兼容
我們交付出一個AliSQL集群化的解決方案，將分布式一致性協議Paxos引入到AliSQL上，我們可以去組件一個AliSQL真正的集群，通過Paxos實現日誌的強同步，實現自動化選主。
X-Cluster核心組件X-Paxos，X-Paxos就是高性能分布式一致性算法。
X-Cluster核心技術
Batching & Pipelining
如何實現再有網絡延時，尤其有異地網絡延時、長延時、短延時以及不同網絡條件下怎麼樣去做高性能真正與單機性能幾乎持平？我們使用了Batching&Pipelining。
Pipelining是當一批往follower發送時，follower返回之前能不能把下一批在leader上已經完成的事務再發出去，這樣就會同時有多批事務從leader等待follower達成多數派，這就是所謂的Pipelining。原來Batching時，是一次隻能發一批，等應答後再發下一批，每一批至少會有一個網絡的RTT，Pipelining好處是在第一批沒有應答前就可以發送第二批···
引入Pipelining就會帶來亂序，導致日誌空洞，會出現亂序接收。Paxos可以作亂序確認，亂序確認的好處是，如果有日誌空洞，任意兩個副本達成多數派，都認為事務提交成功。每一個follower上都有空洞，但是將兩個follower拚在一起，它是一個完整的日誌流。
Locality Aware Content Distribution
有了Paxos之後，多少副本都可以。為了解決Leader出口網絡，降低跨Region長傳鏈路帶寬，我們在跨Region時使follower可以連在follower上，用級聯的方式去複製。
日誌實現
還有我們做了一體化日誌：插件式X-Paxos的日誌，歸一化的ConsensusLog代替Binlog和RelayLog，全局統一的Log Index。
Asynchronously Commit
我們還將工作線程和提交線程異步化，工作線程隻負責處理事務提交之外的用戶請求，在用戶發送提交請求後，工作線程將事務推入提交等待隊列後就繼續處理下一個用戶請求。而提交等待隊列的中的事務由另外一批線程來負責處理，這樣能夠充分解放工作線程，減少線程的等待，提高高延時下的吞吐性能。
X-Cluster: vs MySQL Group Replication
我們與MySQL Group Replication對比，做了簡單的性能測試。可以看出，INSERT同城比官方好兩倍性能，延時要小很多；30ms 網絡延時的部署下，我們仍舊能夠達到五萬多，延時隻有官方的三分之一，性能是五倍。
X-Cluster生態
我們麵臨的問題很多，比如備份、日誌訂閱、隻讀節點等，所以我們要超越數據一致性和持續可用，Paxos關聯的東西有很多。
持續備份
原有MySQL備份邏輯是：定期備份Binlog文件；RPO一般比較大，例如：大於5分鍾；備份跟MySQL的數據一致性保障困難。
X-Cluster可以解決備份的一些不便之處：備份節點作為X-Cluster的一個Learner節點，實時推送X-Cluster上達成多數派的日誌；RPO < 1秒；由於備份的一定是達成多數派的日誌，因此無數據一致性問題。
自動化高可用
原有MySQL高可用方案外部組件依賴：ADHA、ZK。而X-Cluster自動化高可用，Client、Server一體化，Client也是數據庫一個learner節點，它需要消費成員變更日誌，成員變更日誌達成多數派後推給learner節點，Driver就會知道主備發生切換，可以直接連新leader，沒有外部組件依賴，達到自動化高可用。
自動化增量日誌消費
原有MySQL下遊日誌消費準實時消費MySQL產生的日誌，問題之一是數據一致性；問題之二是數據庫主備切換與下遊消費端的聯動。
X-Cluster自動化增量日誌消費，日誌消費節點作為X-Cluster的Learner節點，隻消費達成多數派的日誌，保證數據一致性；X-Cluster自動選主，新Leader自動向日誌消費節點推送新日誌，徹底解決聯動問題。
區域化/全球化部署
- 按需增加Learner節點：增加讀能力，但是不會帶來強同步開銷
- 按需增加Log節點：Log節點隻有日誌，沒有數據；Log節點可參與選主，但是沒有新增存儲開銷。低成本節點；3節點X-Cluster = 2節點MySQL主備。
- 權重化體係：可以指定節點選主權重，控製每個節點的選主優先級。
X-Cluster實戰總結
一路走來，我們並不是一帆風順，也踩過很多坑，比如：
- 異常處理：硬件異常，網絡異常：Leader Stickiness
- Batching & Pipelining：極大事務，極小事務，不同網絡時延下的Batching/Pipelining策略，網絡異常情況下的Batching/Pipelining策略
- 全球化部署下的優化：權重體係、熱點帶來的影響
最後更新：2017-08-13 22:20:48