【沉澱】實例遷移、Insert和寫入性能——數倍，甚至數十倍提升，HybridDB for MySQL負責人王騫談自己經曆和收獲

技術人是怎樣的一群人？一千個人，或許有一千個答案。毋庸置疑的是，做技術是辛苦的。

有位大牛在《技術人的慰藉》一文中這麼描述到：“一個人，一台機器，相對無言，代碼紛飛，Bug無情。須夢裏挑燈，冥思苦想，肝血暗耗，板凳坐穿。世界繁華競逐，而你獨釣寒江，看盡千山暮雪，聽徹寒更雨歇。”

然而，再怎麼清苦，在王騫的眼中都是過眼雲煙。他的人生，隻關心一點——要做技術。隻要能夠做技術，他就是開心的，生活就是圓滿的。

在外人看來，這位性格頗為內向，看起來低調的技術人，卻做了一件很高調的事情——成功推動RDS分布式數據庫HybridDB for MySQL上線公測，並在2017年成功商業化。這個可以同時支持OLTP和OLAP，提供了10T到1P解決方案的數據庫，完善了阿裏雲RDS團隊的產品族，具備了向專業評測機構Gartner定義的數據庫魔力象限衝刺的能力。當前，HybridDB for MySQL在線上已經積累了600+DB機器，總數據庫規模3.5PB，日常流量3GB/S。

采訪中，王騫是那種一個問題，片言隻語就完事的人，這對訪談者來說有點不“太友好”——總有一種意猶未盡的感覺。從另一麵來看，也正是這種“不友好”，讓筆者發現王騫那種寥寥數語點出問題實質的能力，以及在解決問題上給別人的啟發。

雲棲社區第16期《沉澱》人物欄目，訪談的是阿裏雲數據庫高級技術專家王騫。我們一起看看這位早期在阿裏淘寶核心係統做數據庫，後續跟隨霸爺來到阿裏雲做數據庫的技術人，究竟有哪些沉澱。

王騫，花名“皓庭”，2011年畢業於四川大學。畢業後入職淘寶核心係統，參與數據庫內核和數據庫雲服務化等方麵的研發。

當時，他的工作主要是兩方麵： 一個是分析Innodb/Tokudb/Ndb Cluster三個存儲引擎的源碼，對比異同，找出分布式數據庫的選型。另外一個工作是將當時剛剛開源的Tokudb存儲引擎源碼，Build為一個淘寶服務器上可運行的版本，並服務於聚石塔曆史庫用戶。

Tokudb是一個壓縮率高，Insert性能強悍的事務存儲引擎。由於當時Tokudb源碼依賴很多，整套工具鏈都要重新搞，所以比較繁瑣。但好在王騫就是一個認真嚴謹的人，他會追著一個目標一直做下去。因此，工具鏈繁瑣對於他而言，並不是什麼事。

事實證明也的確如此，繁瑣對他而言什麼都不是。最終這個引擎成功上線，服務了一些數據量大、寫多讀少的用戶。

後來，王騫跟隨大團隊來到阿裏雲，從事分布式和數據庫相關的工作。

阿裏雲RDS（Relational Database Service）是一種穩定可靠、可彈性伸縮的在線數據庫服務。基於阿裏雲分布式文件係統和高性能存儲，RDS 支持 MySQL、SQLServer、PostgreSQL 和 PPAS引擎，並且提供了容災、備份、恢複、監控、遷移等方麵的全套解決方案，徹底解決數據庫運維的煩惱。

這款全能選手數據庫的研發工作中，就有王騫的身影。回顧研發過程，王騫表示，中間遇到很多困難，其中最典型的是解決大量遊戲用戶連接閃斷的問題。這是RDS團隊當時一個痛點，而為了解決這個問題，2014年春節前後，他們投入大量人力，通宵鑽研解決方案。

作為RDS提升產品穩定性的一個重要項目，王騫當時負責編寫一個分布式一致性緩存。這個緩存既要保證RDS管控係統與Proxy元數據間多級級聯的數據一致性，又要解決集群腦裂問題，還要在集群與外界斷連時有自治能力，複雜度頗高。

攻堅戰後，大家最終研發出新的防閃斷haproxy，避免在後端MySQL主備切換時影響用戶的前端連接。“RDS團隊在三周內就攻克了整個項目，年後發布上線也收獲了很好的口碑。”王騫幾句話，就把短時間攻破項目的驚心動魄一帶而過。而在這背後，分布式一致性緩存是怎麼解決的？腦裂問題是如何破解的？除此之外，還有哪些問題？

技術人的世界，非常簡單。王騫沒有做任何情緒鋪墊，而是直接告訴雲棲社區，他是如何解決一致性緩存問題的：“我設計了多級級聯的分布式一致性協議——第一級為支持分布式事務的三節點中心緩存，三個節點都可以接受服務，每一次變更都有一個遞增版本號，在多數派上提交後即可返回，這樣可以支持強一致；第二級為每鏈路服務Proxy的本地元數據緩存，每次中心緩存提交後，也會立即向proxy本地緩存同步，這個過程是最終一致的，多個proxy節點間可能存在短暫的不一致。”

至於腦裂，主要分為兩種，一種是以中心緩存腦裂，另外一種是Proxy節點腦裂。“中心緩存少數派節點出現腦裂時，可以在網絡恢複時自動同步最近的變更，追上後可以繼續參與提交。中心緩存多數派節點出現腦裂時，全局禁止變更服務，進入隻讀狀態。外部控製器與中心緩存之間腦裂時，以中心緩存的數據為主，中心緩存全部失效後，則會從外部控製器同步所有持久數據。Proxy節點出現腦裂而導致中心節點無法同步數據，中心緩存會定期向Proxy本地緩存持續同步，保證最終一致性。”

和筆者梳理完問題解決思路後，他也提及問題解決過程中一些記憶深刻的事情。

令王騫最難忘的事情，就是分布式一致性緩存的不變式證明和各種邊界測試。為了達到預期的設計，算法的每一塊關鍵實現都要進行覆蓋。而且要模擬各個場景，正交的測試Case，經過合並後仍然有60多個。這也就意味著，王騫需要利用各種方式，包括利用iptables控製網絡來模擬腦裂、強製破壞活動進程來構造非預期failover場景等……過程的艱辛，可想而知。王騫廢寢忘食測試完後，穩定性得到檢驗，項目也終於按期上線。

2016年，王騫帶領他的團隊開始進行阿裏雲分布式HTAP數據庫產品HybridDB for MySQL的研發工作。

HybridDB for MySQL是一款分布式HTAP數據庫產品，用戶無需維護複雜的外部組件進行性能擴展，因為在一個數據庫內，它同時支持OLTP和OLAP業務——支持在線擴容，提供MySQL的使用生態。

之所以開發這樣的數據庫，主要是為阿裏內部業務提供一個實時的高標準數據倉庫。比如擁有PB級的容量、支持高寫入能力，以及在線查詢和分析能力，能為集團內的多個業務提供大數據支撐。在起初，這個數據庫並不叫HybridDB for MySQL，而是命名為PetaData。對於為什麼改名，王騫解讀稱，這是因為PetaData 落地後，Gartner又提出了HTAP數據庫的概念。這和PetaData的方向十分契合——都是融合OLTP與OLAP。“為了體現混合能力和MySQL生態兩個方麵，產品就由PetaData改為了HybridDB for MySQL，以突出其特點。”

2017年，HybridDB for MySQL正式商業化。而在商業化後不久，它就為用戶提供了10T到1P的數據庫解決方案，並且在線上已經積累了600+DB機器，總數據規模達3.5PB，日常流量3GB/S……

看完這些靚麗的數據，不禁讓人好奇：這樣一款成功產品的背後，開發過程中都遇到哪些技術挑戰？

王騫告訴雲棲社區，開發中的困難集中在兩方麵。一方麵是存儲節點的遷移和副本重建問題。在HybridDB for MySQL的部分大用戶中，一個存儲節點數據量就高達1T+，入庫流量10MB/s，實例遷移遇到了很大的挑戰。另外一個問題是存儲引擎在多索引下的高insert問題。數據庫的存儲引擎為了事務化的維持多個索引間的一致性，需要同時檢查多個索引的數據內容，並與主表一致變更，這個過程會產生大量讀IO。

存儲節點的遷移和副本重建問題是如何解決的？王騫說，他設計了全新的流式遷移技術，並綜合考慮遷移過程中可能存在的各種導致磁盤空間占滿等異常狀況，從而最終解決了這個問題。言語之間看似輕巧，如果沒經曆過，你永遠都不會發現這件事的難度有多大。進一步追問王騫後，你會發現“全新”流式遷移技術背後是這樣的組合拳——源實例全量快照備份直接在主機間對傳、 全量快照傳輸時實時上傳Binlog日誌、使用並行binlog下載和MySQL並行複製來加速增量同步、使用萬兆網機器增加網絡帶寬。

整套方案下來，1T實例的遷移，由過去的近5天，大幅優化到4個小時。

解決存儲引擎在多索引下的高Insert問題，更像是在做一道證明題。 通過一係列複雜的理論論證和分析源碼，王騫發現Tokudb的代碼本身支持他們需要的特性，但是代碼中有一些Bug，導致無法直接使用。

通過解決Bug，最終在Tokudb上實現了某些場景下消除多索引讀IO的方案，並使得這些場景下帶多索引的Insert性能提升一倍以上，多索引表的寫入性能，由3000+提升到40000。

HybridDB for MySQL除了易用性和生態完善外，也有使用成本低。一位擁躉感謝HybridDB for MySQL幫他們公司節省了大筆IT開支：”老板很滿意。”

“對於大規格用戶，HybridDB for MySQL節點、售價比同規格的RDS實例要便宜三分之一左右。 ”在這個基礎上，還有設計上的考量，也能讓用戶減少開支。王騫解讀：“按照經驗數據來算，一份數據，在Innodb存儲引擎下會有數據膨脹的問題，通常會膨脹到1.5倍，而在HybridDB for MySQL的Tokudb存儲引擎下，則會被壓縮，通常壓縮比是3-15倍，這會令用戶的存儲成本大幅降低。 其次，用戶可以使用一份數據同時解決OLTP和OLAP的問題，無需分庫分表中間件、數據同步以及額外的分析數據庫。 ”

用戶使用成本得到大幅降低的背後，是產品存儲體係的領先。

第一代存儲體係，是基於SSD盤的對機存儲，成本較高，且機器損壞後隻能成對替換，典型用戶是早期的性能數據業務；第二代存儲體係，是基於混合磁盤的單機存儲，集中優化了成本和性能，利用塊存儲團隊提供的Bcache方案，基於混合存儲機器設計了低成本高性能的存儲體係，典型用戶是天象。

目前HybridDB for MySQL已經經曆了RDS的兩代存儲體係，現在正在進入第三代共享存儲體係階段。“最新的存儲體係，是基於RDS的共享存儲體係，消除了傳統的遷移問題，同時大幅度提升IO性能。”王騫道出領先的根本原因。

HybridDB for MySQL如此成功，那未來還打算怎麼做？

王騫分享三點：

1. 支持列存索引加強OLAP能力；
2. 支持分布式事務加強OLTP能力；
3. 支持共享存儲降低運維難度；
   

訪談中，和阿裏雲數據庫團隊的產品運營負責人曉哥有過幾次溝通。她告訴我，王騫工作非常認真，但就是太低調了，讓人覺得他性格比較內向。她提醒我，如果可以，一定要多聊幾次。

盡管王騫的確有點內向，但和王騫的多次接觸中，筆者發現，有一樣東西卻是“鋒芒畢露”的——做正確的事情。

為什麼是這樣？他緩緩道來：“計算機和互聯網行業發展太快，如果不做正確的事，那麼很容易被淘汰，專注、持續的去做，才能讓我們緊跟行業的變化，不斷迎合用戶的需求，站在行業前端。”

何謂正確的事，王騫是這麼定義的：

• 首先，要選對方向，確定所做的事情是在互聯網行業發展的方向上；
  
• 其次，要找到誌同道合的人一起做，一起發展，懂得分享；
  
• 最後，要堅持將這些事情不斷打磨到最好；
  

那落在一位技術Leader上，什麼是正確的事？王騫說，要極技術，也不技術。“從一行行的代碼，變成肉眼可見的服務，需要解決的遠遠不止是技術問題，任何一個環節的缺失，都有可能讓產品口碑受影響。”因此，在技術上，“我便不再糾結於某項高深但複雜的技術，而是傾向選擇實現、部署、運維都比較簡單的方案，畢竟減少旁支幹擾，才能集中精力做正確的事。”

這位曾經醉心於技術的互聯網從業者指出，技術問題，經過縝密的分析和論證後，最終都能有解決辦法或折中，最難的是一位技術Leader，如何做正確的事，實現技術的價值。

法國哲學家布萊斯·巴斯卡說過一句話：“把什麼放在第一位，是人們最難懂得的。”記住，無論任何都要做正確的事。