作為在網際網路耕耘多年的一線網際網路廠商，攜程在資料庫例項規模和資料規模都是行業標杆，那麼在引入分散式資料庫時有哪些考量和在業務實踐後效果如何？帶著這些問題我們專訪了
高階資料庫總監，攜程DBA負責人俞榕剛老師。
攜程作為在網際網路耕耘多年的一線網際網路廠商，本身的業務複雜性、資料量級、資料安全、嚴格事務 ACID 等對關係型資料庫提出了比較高的要求；同時技術團隊也持續保持著對關係型資料庫產品發展趨勢、技術演進的關注和研究熱情。
眾所周知，關係型資料庫從大規模應用以來基本經歷了三個階段：
● 基於小型機、高階儲存的單機或者主備模式關係型資料庫，典型代表如 Oracle、SQLserver 等，近年來也有基於 PC Server，使用開源資料庫核心的解決方案，如 aurora、polar DB 等；
● 基於分庫分表中介軟體的分散式模式，透過中介軟體代理眾多底層單機關係型資料庫，典型代表如 TDDL、DRDS、TDSQL 等；
● 雲原生分散式資料庫，透過原生分散式，解決多副本一致性，資料分割槽等複雜的分散式問題的解決方案；如 Google Spanner、TiDB、OceanBase 等。
作為二十年來一直在網際網路一線發展的企業，在發展早期和眾多公司一樣，透過使用高階硬體(小型機，共享儲存等)搭配 SQL Server 的解決方案，快速支撐了我們的業務發展。但伴隨著業務的發展和業務型別的增加，不同業務都對資料庫提出了不同的要求，不可避免出現了資料庫資源的爭搶現象；同時不斷沉積的海量資料使得我們的資料庫成本越來越高。
「MySQL 的不足」
在國內數字化轉型趨勢和以上因素的推動下，攜程在不同業務上逐步引入了 MySQL 搭配 PC Server 的解決方案，經過多年的努力完成了對 SQL Server 的替換。但是 MySQL 本身也有很多缺點，即需要在核心能力之外尋找方案解決，總結有如下幾點：
1. MySQL 的 online DDL 帶來的穩定性風險
2. 基於 binlog 複製的多節點資料一致性問題
4. 主備節點切換，機房搬遷等運維操作對業務的影響。
對於問題1，業內目前需要依賴外部工具使用複製，重新命名等方式去解決，同時帶來的延時（對於大表以周為單位），空間膨脹(至少120%變更表儲存空間)等問題。
對於問題2，業內幾乎無解，包括使用 MGR、binlog 複製方式也是經過驗證的隱患；所以我們所有的線上資料庫節點都是 RAID10 方式使用磁碟。但是無法解決機房級別的資料一致性問題。
對於問題3，即使使用分割槽表也無法解決只能使用單機的計算和儲存資源等限制；同時因為分庫分表方案眾所周知的問題，我們一直沒有大範圍鋪開的分庫分表方案。
對於問題4，我們開發統一運維平臺，在搬遷和切換的過程能夠做到各種 check 後，自動放行；但是因為 MySQL 資料複製原生缺陷我們無法真正做到業務無感，而且每次變更也還是會提心吊膽。
對於不同業務我們提供了標準的 MySQL 配置，但是不同業務的模式對資源的使用模式都不盡相同，包括但不限於重計算輕儲存，重儲存輕計算等，造成我們線上資源的使用率整體上偏低，卻不能簡單提升。
「OceanBase 的優勢」
綜合以上問題，攜程一直在跟進技術演進和產品趨勢，恰逢國產分散式資料庫崛起，OceanBase 驚豔地進入我們團隊的視線。在和 OceanBase 技術團隊交流和我們使用和測試後，我們認為 OceanBase 有以下優勢。
● 久經磨練，畢竟一款可以支撐螞蟻集團的業務體量，經歷十餘年雙十一考驗的產品本身就擁有強大的背書；
● TPCC 和 TPCH 成績的驚豔，曾幾何時在這些榜單都是耳熟能詳的國際產品，但是 OceanBase 的多次測試並取得優異的成績，更增強了我們的信心；
● 經過深思熟慮的產品實現，包括多租戶，類 LSM Tree 儲存引擎，高效編碼和壓縮，HATP 能力，真正可用的多機房部署能力和案例；
● 成熟的周邊配套產品，如統一管控平臺，資料遷移平臺等；
● 強大的技術團隊，方案設計能力和高效穩定的服務能力等；
以上優勢讓攜程和 OceanBase 開啟了合作共贏之路。
透過 OceanBase 的原生分散式能力，比較方便地解決了 MySQL 的隱患並帶來了不少額外的好處。
「如何解決線上 DDL 問題？」
線上 DDL 是困擾沒有運維過 MySQL 的技術人員的噩夢之一，當年攜程 IM 業務群組訊息表需要加一個狀態欄位，從穩定性考慮不得不新建一個表用於擴充這個欄位，從而引入了不必要的 join 查詢，往事歷歷在目，卻因為 OceanBase 的引入得到改觀；因為 OceanBase 的儲存引擎使用了類 LSM Tree 設計，表的 scheme 也支援多個版本，所以在 DDL 已經不是問題，秒級即可完成並且不會鎖表，可以放心的做此類操作。
對於增減索引這類操作，其實也不用擔心，簡單來說， OceanBase 的儲存機制可以理解為一個表在記憶體中和磁碟中都有一部分，在增減資料的時候，對於記憶體中的資料是實時生效，這部分的資料量不是很大，可以很快地完成並返回可使用，對於磁碟的部分資料，會有後臺任務進行處理，因為大部分的業務是對近實時的資料進行操作，後臺任務並不會對業務造成影響。
「OceanBase 單表資料量可以有多大？」
OceanBase 單表資料量可以有多大，其實這個問題還沒有準確的答案，因為攜程還沒有觸達這個上限。
以攜程 IM 業務為例，我們群組訊息表儲存兩個月資料佔用儲存空間800G 左右，基本觸達當前配置下的 MySQL 單表上線；同樣的資料遷移到 OceanBase 後資料量在200G 左右。
為什麼如此神奇，答案就在於 OceanBase 高效的編碼和壓縮機制，在資料被寫入磁碟之前，OceanBase 可以針對資料列使用字典等方式進行編碼，編碼後每個欄位佔用的資料量會大大降低，結合不激進的壓縮演算法就可以取得良好的空間友好性。實際測試下來不同業務的壓縮率在1/3到1/10之間；即使 OceanBase 使用三副本也可以保證儲存空間不增長，加之攜程在 MySQL 上其實也使用一主兩備或者 MGR，而且磁碟使用 raid10方式，OceanBase 即使在最低壓縮比情況下也可以節約近5/6的儲存空間。
而且因為在記憶體中儲存了編碼欄位，實際上在業務處理過程中，資料不需要解編碼，可以說透過高效的壓縮編碼，OceanBase 取得了成本與效能的雙贏。
更進一步，OceanBase 提供了原生的分割槽表解決方案，可以透過豐富的分割槽方式對資料進行組織。透過合理的編排資料分割槽的主分割槽(寫操作一定發生在主分割槽，讀操作可以根據業務進行選擇)，還可以更進一步地利用起多個副本所分佈在的機器資源提高資源利用率，在不增加資源配置的情況下，極大提高寫入效能的同時保證讀操作的效率。
「如何保證資料一致性？」
作為雲原生分散式資料庫，OceanBase 和大多數產品一樣使用多副本解決了資料安全問題，那麼這些副本之間的資料一致性怎麼保證？這裡 MySQL 面臨的最大難題在 OceanBase 這裡卻成為了最不需要擔心的問題。
OceanBase 使用最佳化的 paxos 協議結合物理日誌複製強保證多數派的資料一致性，也就是三副本情況下強保證至少兩個副本資料一致性，使用 OceanBase 保證了 RPO=0，實際測試下來RTO＜30s，滿足攜程金融業務的資料一致性的要求。
額外的，其實我們比較認同“世界上只有一個多副本一致性協議就是 paxos，其他協議均是變種”的說法。透過我們的技術調研，paxos 比較 raft 等變種協議上來說：
● 在故障恢復時選主速度更快，反應到資料庫上時，就是節點故障的業務恢復時間更短
● paxos 允許日誌空洞，這可以讓攜程更方便的參與到主選舉的過程中，更加合理的為業務編碼資源的使用
「OceanBase 主備切換怎麼做，安全嗎？」
使用了 OcenaBase 後其實已經不太關心主備問題，因為 OcenaBase 的 share nothing 的架構，每個副本之間都是對等節點，而且在任何時候 OceanBase 能夠保證多數派副本一致性，傳統意義上的主備切換其實就是對副本打個標誌而已，這就從根本上保證了主備切換變成了一個安全的操作。而且 OceanBase 還可以根據配置順序自動判斷當前系統狀態，如果遇到機器當機等情況，可以自動發現和切換到具備完整資料的其他副本上，保證服務的連續可用。
更進一步，OceanBase 在訪問層提供 Obproxy 元件自動路由資料庫訪問，結合我們原本已經具備的 DAL 元件(應用資料來源訪問控制層)，可以十分方便穩定地提供流量切換能力，真正做到對業務的無打擾或者少打擾。
透過以上 OceanBase 原生的能力，攜程幾乎從根本上解決了 MySQL 的隱患，還獲得了額外的收穫。
「資源池化，資料庫例項混部」
因為不同的業務模式對資料庫的使用方式不同，業務的高峰也不盡相同；在原有的基於 MySQL 例項的部署模式下，每個業務都需要按照業務要求的最高配置去匹配資源，實際執行下來，真正的平均資源利用率都不是很高，但是因為 MySQL 資料複製和切換效率和穩定性限制，無法方便的進行擴縮容，所以沒有很好的辦法提高資源利用率。
攜程透過配置一個較大的資源池給到 OceanBase，使用 OceanBase 提供的多租戶資源隔離能力，將原來多個業務使用的 MySQL 例項遷移到 OceanBase 的租戶中，從而實現一個叢集多個資料庫例項的混合部署模式。
● 透過對租戶配置不同的資源隔離，保證每個租戶擁有合適的資源配置；
● 根據業務高峰的不同時性，使用縱向的租戶資源擴縮容方式，實現秒級的資料庫例項資源擴縮容，在整體叢集資源使用不變的前提下，穩定的實現了多個業務的高峰承載能力。
● 如果有個別業務增長速度很快，還可以使用擴充套件資料庫例項使用的資源節點個數方式，快速地進行業務的橫向擴容。當然在業務橫向擴容時候會發生資料複製，OceanBase 還貼心地提供了資料複製對頻寬資源使用量的配置引數，保證資料複製或者遷移期間的服務穩定性，經過實測資料複製可以有效使用到伺服器頻寬80%左右。
● 更近一步可以透過增減節點的方式，方便地控制資料庫叢集整體的資源使用量；擴縮容操作都是線上操作且不要求擴縮容操作一定是對等擴縮容資源，這就保證了攜程對資源使用的靈活性。
「HTAP 能力提升業務響應速度」
OceanBase 目前提供的 HTAP 能力為攜程的業務開啟了新的可能性，在同一套資料庫叢集中，可以一邊進行線上業務的 TP 操作，一邊提供業務 Ad Hoc 的查詢能力，因為 AP 查詢就在資料所在的原地，資料都是新鮮的，對業務的服務能力要比經過 ETL 的資料時效性更強，同時因為沒有增加資料副本使得儲存成本也得到了有效控制，相當於買一送一的大份量滿足。
在 TP/AP 業務混合使用的場景下，OceanBase 也想在前邊提供不同業務的有效資源隔離和限制能力，不會因為 AP 的引入導致與 TP 業務發生資源爭搶，最終導致業務服務質量受損。
「關於運維管控」
攜程的資料庫規模整體來說還是比較大的，所以面向規模化運營執行了詳細的運維規則、流程，配合開發的一系列平臺形成了攜程的資料庫運維體系。恰巧 OceanBase 從支付寶起家開始，面向規模化運營的設計理念和攜程很契合；OceanBase 提供的統一運維監控平臺 OCP 可以將多套 OceanBase 叢集統一納管並提供了開發的 API。透過針對開發、測試，生產部署了不同的 OCP 很方便地管理各個環境的 OceanBase 叢集，並透過 API 快速便捷地將這些平臺和叢集納入到了原有的運維體系中。
「關於資料遷移」
對於任何一次資料庫的遷移我們都需要慎之又慎，必須保證資料的強一致性，因為資料是生命線。引入 OceanBase 也不例外，幸運的是 OceanBase 提供了好用穩定的資料遷移平臺 OMS。
透過使用 OMS 可以很容易並且是有保證的在資料遷移過程中做到以下能力：
1. 全量遷移，可以將 MySQL 中的 scheme，資料前量遷移到 OceanBase 的 MySQL 模式的租戶中，並且在遷移完成後會進行全量的資料校驗，針對每一條差異都會給出提示和修改 SQL。同時 OMS 遷移過程中會充分發揮 OceanBase 資料寫入的併發能力並根據 OceanBase 的記憶體狀態進行自動流控，保證了遷移過程的穩定性。
2. 增量遷移，在全量遷移發起前，OMS 就會將 MySQL 的 binlog 拉取到本地，並在全量遷移，全量校驗完成後將這些日誌進行重放，保證了全量遷移過程中的增量資料不丟失，與此同時還會進行增量資料校驗保證增量遷移的資料一致性。
3. 反向遷移，在保證增量遷移完成，資料一致的前提下，當業務將讀寫切換到使用 OceanBase 後，OMS 還可以將 OceanBase 中的增量資料反向遷移到 MySQL 中，保證在資料並行期間的可遷回，不得不說這是一個貼心的設計。
4. 資料同步，OMS 提供了將 OceanBase 中的資料同步到 kafka 等訊息佇列中能力，為後續的大資料分析，機器學習提供資料。更可以作為一種邏輯備份手段提供一定的資料安全性保證。
「透過 OceanBase 的使用，攜程獲得哪些收益？」
透過 OceanBase 的引入和業務實踐，解決了長期以來使用 MySQL 困擾攜程的 online DDL、資料一致性、大表效能、主備切換等問題。在提供更加穩定、高效的服務能力的同時，降低了資料庫系統整體的擁有成本，並且提高了資源利用率。
同時 OceanBase 本身是個開放的系統架構，無論是 Observer(資料庫核心)，OCP(叢集管控平臺)，OMS(叢集遷移工具) 還是 OB Agent(管理節點)，Obproxy(輕量級資料路由代理) 都提供方便的介面或者標準 SQL 介面，我們可以將 OceanBase 的監控和告警體系接入到我們現有的監控體系中；透過管控使用 API 的方式接入，快速而方便的將 OceanBase 的資源、叢集、租戶、資料庫等多個層級等管控能力介入到當前的管控平臺中，使攜程可以統一的管理所有的資料庫產品，這些開放架構帶來的便利性很好的保護了技術投資，也讓技術同學以更加熟悉和順手的方式使用。
大家都知道在軟體的世界裡沒有銀彈，使用 OceanBase 也不是一蹴而就的，首先需要理解 OceanBase 的設計理念和架構設計，每個功能特性也需要對其優劣勢瞭然於心，才能夠最大程度的揚長避短，這對技術同學提出更高的要求；同時，OceanBase 還沒有做到完全的資料庫自治，還需要很大程度的人工參與，最主要的集中在表結構資料、索引設計和查詢最佳化上。不過這對技術同學也是好事，在理解資料庫技術的基礎上還需要分散式系統的知識儲備，推動技術同學更加貼近業務，理解業務模式之後才能更好地進行資料庫設計和最佳化。這些都在一定意義上推動了技術同學的知識廣度和深度。
“Talk is cheap，show me code”，意思是在軟體的世界裡如果怕手髒，那麼可能終究不會得到真正的理解；即使對 OceanBase 的特性和攜程自身業務模式都有了很好的掌控，但這些都是先驗的經驗，如何才能真正的做到完全瞭然於心，離不開真實的後驗結論，畢竟不能使用線上業務直接進行驗證，針對於此，攜程和 OceanBase 的技術同學共建了以下專案：
1. 業務 SQL 重放系統，基於攜程業務和資料庫的 trace 系統，已將全量的業務 SQL 重放到 OceanBase 進行業務適應性驗證；並透過流量複製，擴充套件重放倍數等手段進行業務壓力驗證，保證 OceanBase 能夠真正滿足業務而又不影響業務。
2. SQL trace 系統，攜程的業務 trace 在 SQL 層的 trace 只有一條 trace 記錄，但是資料庫的具體執行層面並沒有明確的分層 trace，加之 OceanBase 分散式資料庫和資料路由的特性，得到完整 SQL trace 找到真正的效能瓶頸並不容易，透過雙方共建實現 SQL trace 系統我們可以將每條 SQL 的執行過程視覺化，進而找到真正的瓶頸點為後續最佳化提供資料支撐。
3. 統一日誌分析系統，對於任何一個分散式系統，日誌的統一分析都是需要的，OceanBase 這種分散式資料庫的日誌分析，對於保證服務穩定性是很重要的，透過識別和串聯關鍵日誌資訊能夠做到及早發現問題和預警，同時透過日誌聯動分析也能更好地理解分散式系統的執行過程。
透過以上的系統共建，攜程更加明確 OceanBase 系統對於業務的適用性，也更加清晰的瞭解分散式系統的執行過程，無論對技術同學的能力增長，還是對業務 SLA 的保證都有明顯的幫助。
同時也清晰的認知：攜程可以在 OceanBase 引入和實踐中做的更多，也需要做的更多，在這裡還有個 Tips，就是多和 OceanBase 的架構師交流和合作，把他們對於 OceanBase 的理解和長期的實踐更清晰的帶給攜程，一起合作可以少走很多彎路，避免故障。
目前，攜程團隊已經全員透過
OBCA，正在向全員透過
OBCP
進發，在這個過程裡大家對分散式、雲原生和資料庫的理解能力越來越強；相信透過不斷地學習、實踐、共創，團隊中的
OBCE
也會越來越多。也希望攜程和
OceanBase
共建的專案儘快盡穩的在攜程落地，更好更快地識別業務適應性和調優能力，可以更加踏實和更有信心地進行業務遷移。同時也希望能夠有越來越多的技術人員深入掌握
OceanBase，使 OceanBase
的生態越來越豐富。
獨行快，眾行遠。希望能夠有越來越多的實際案例分享，在相互借鑑和學習中使用國產雲原生資料庫併為我們的業務創造更高價值，也讓我們擁有更多的能力，具備更高的價值。
OceanBase 架構師韓冰 (花名：真難) ：
作為有二十多年技術積澱的頭部網際網路企業，攜程 DBA 團隊具備深厚的技術底蘊，對於資料庫、分散式系統都有很深刻的造詣；在合作的過程中攜程的技術同學很快的掌握了 OceanBase 的使用姿勢，結合攜程早已構建並持續發展的資料庫運維管控體系和平臺工具，快速的將 OceanBase 提供的企業級服務能力進行了整合和融合，很快就將 OceanBase 融合到研發、測試和生產各個環境中。
在和攜程同學的合作學習中也深入到業務體系內，對業務特點有所掌握，
大家一起根據業務特性設計了資料庫的適應使用姿勢和針對性的設定，為業務的平滑遷移和資料庫的效能提升提供了快速支援。在這個過程裡深刻的感覺作為原廠的架構師一定要和我們的使用者緊密合作和相互學習，只有這樣才能各自發揮優勢，儘快的掌握業務特性和使用者運維體系，同時也能更好的把 OceanBase 的設計理念、功能特性、使用姿勢更好的帶到合作的環境裡，更快、更好、更高效地獲得業務價值。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/69909943/viewspace-2854050/，如需轉載，請註明出處，否則將追究法律責任。
