【沉澱】HybridDB for MySQL負責人王騫談自己經歷和收穫

摘要： 在外人看來，這位性格頗為內向，看起來低調的技術人，卻做了一件很高調的事情——成功推動RDS分散式資料庫HybridDB for MySQL上線公測，並在2017年成功商業化。這個可以同時支持OLTP和OLAP，提供了10T到1P解決方案的資料庫，完善了阿里雲RDS團隊的產品族，具備了向專業評測機構Gartner定義的資料庫魔力象限衝刺的能力。

《沉澱》是雲棲社區展示專家風采的人物欄目。它呈現每個專家獨一無二的人生經歷、認識和感悟的同時，也能幫助你沉澱技術，收穫對技術和人生的判斷。我們的想法是：「若你想精進為一個很厲害的人，不妨細細品味這些技術牛人背後的沉澱。」如果你想了解這些雲棲專家更多分享時，請點擊雲棲專家頻道，當然我們也歡迎你往前走一步，成為我們的雲棲專家（https://yq.aliyun.com/expert），與技術大牛一起「煮酒論英雄」。

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

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

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

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

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

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

入坑資料庫

王騫表示，技術問題經過縝密的分析和論證後，最終都能有解決辦法或折中，最難的是一位技術Leader，如何做正確的事，實現技術的價值

王騫，花名「皓庭」，2011年畢業於四川大學。畢業後入職淘寶核心系統，參與資料庫內核和資料庫雲服務化等方面的研發。

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

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

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

後來，王騫跟隨大團隊來到阿里雲，從事分散式和資料庫相關的工作。

RDS錘鍊

阿里雲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場景等……過程的艱辛，可想而知。王騫廢寢忘食測試完後，穩定性得到檢驗，項目也終於按期上線。

實例的遷移、Insert性能和寫入性能——數倍，甚至數十倍的提升

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，如何做正確的事，實現技術的價值。

法國哲學家布萊斯·巴斯卡說過一句話：「把什麼放在第一位，是人們最難懂得的。」記住，無論任何都要做正確的事（本期接受訪談的雲棲專家/皓庭；文/我是主題曲哥哥）。

• 《沉澱》第十五期：【[沉澱]記錄電商時代下的技術人：訪談阿里高級技術專家玄宗，我的十年阿里路】 「不斷突破昨日的想法，與其讓別人革命，不如自己革自己的命；獲得成長最快的方式，每年立下的目標都需要改變上一年固有的思維和想法，創造出新的思路。」談及阿里十年最大的沉澱，玄宗說，堅持你所相信的，相信你所堅持的。
• 《沉澱》第十四期：【[沉澱]一張表的設計優化節省了兩百萬，客戶不斷盛譽……，這背後他究竟做對了什麼？——記訪談阿里雲汪建明】聊到對技術的理解，他說，不論是技術人，還是技術型公司，都需要對技術的執著追求、對任何問題死磕到底的工匠精神，戒驕戒躁；以技術解放生產力問題，用技術提高生產率，優化產品質量。

• 《沉澱》第十三期：【[沉澱]訪談阿里孫偉光：多行善事莫問前程的他，將計算集群的CPU利用率從30%提升到70%+】做事情不能單單盯著KPI，不是KPI的事情不做。

作者：【沉澱】

原文鏈接

更多技術乾貨敬請關注云棲社區知乎機構號：阿里云云棲社區 - 知乎