如今，在中國任意走進一家餐飲商戶，不論其規模大小，掃碼點餐、自助點餐機、商家點餐小程式等已經基本成為標配。隨著餐飲行業數智化持續加速推進，餐飲 SaaS 已經逐漸成為商戶們的“必選題”，二維火便是這“必選題”之一。
2007 年，二維火釋出餐飲管理系統 1.0，深耕餐飲 SaaS 領域十餘年，目前，二維火已經形成涵蓋智慧化找店、點餐、營銷、管理、供應鏈服務的全產品矩陣，服務商戶 49 萬餘家，服務範圍覆蓋 400 多個城市，註冊會員超 2 億。
餐飲 SaaS 有一個特點，中午、晚間點餐高峰期系統高併發，大量訂單的寫入和查詢對系統的抗壓能力要求很高。作為 Cobar 長期使用者之一，單點瓶頸的消除在過去對業務穩定發展有很大幫助，但伴隨著應用和高可用性上的限制，以及運維複雜度的增加，對業務未來的升級創新，二維火還是感受了到掣肘。近期，二維火開始選型滿足其業務長遠發展的分散式資料庫，本文由二維火運維總監三七攜手 OceanBase 解決方案架構師孫鵬 從“分庫分表”出發，為大家闡述二維火選型新資料庫（OceanBase）背後的考量。
分庫分表的誕生
21 世紀的第 1 個十年，網際網路產業蓬勃發展，面對網際網路海量資料儲存與處理的需求，在擴充套件性上存在瓶頸的傳統商用關係型資料庫越發顯得捉襟見肘。NoSQL 資料庫如 Redis、MongoDB 等的快速、可擴充套件特性在特定場景優勢明顯，可以作為關係型資料庫的有效補充，卻不能完全取代。
當硬體發展的速度已經跟不上業務需要，傳統商用關係型資料庫又面臨著高昂的 License 費用，頭部網際網路公司自然開啟新路徑探索。
分庫分表方案在時代的大背景下應運而生，化整為零，分而治之。在 Amoeba 的基礎之上，2009 年 Cobar 初版完成，開始在阿里巴巴集團內部使用；2011 年完成叢集化改造；2012 年 6 月，Cobar 開源。
Cobar 架構圖（圖片來源於網路）
Cobar 本質上是一個關係型資料庫的分散式處理系統，是提供關係型資料庫（MySQL）分散式服務的中介軟體。和很多使用者一樣，二維火當初選擇 Cobar 作為中介軟體構建業務系統主要出於以下考慮：
- 突破單點效能瓶頸
- 解決單例項連線數過多
- 可用性問題，Master 故障的發現和切換
- 使用開源 MySQL，避免高昂的軟硬體費用
“分庫分表”壯大背後的隱憂
21世紀第2個十年，由於人口紅利尚在，網際網路產業繼續高歌猛進，MySQL已經成為大多數網際網路公司建站的首選和事實標準，相應配套的分庫分表解決方案也如雨後春筍般不斷湧現，很多公司都研發了自己的分散式資料庫中介軟體，Cobar 進化為 MyCat，工作在客戶端的 Sharding-JDBC 也被很多使用者認可並採納。簡單列舉常見產品，如下圖所示：
分散式資料庫中介軟體常見產品羅列
上述遠非可用分庫分表方案的完整列表，但總結所有方案基本分為兩類：第一類，作為獨立程式執行的中介軟體，第二類，工作在客戶端的外掛。這兩類方案為解決單點瓶頸而生，但在實際使用中其實會給使用者產生各種煩惱，例如：
- 應用限制，很多隻支援簡單的SQL，複雜應用需改造
- 非 Sharding Key 查詢
- 分散式事務和資料一致性
- 不成熟的高可用
- 運維複雜
選型新資料庫背後的考量
21 世紀第 3 個十年，國內網際網路使用者數量基本見頂，疊加持續三年的黑天鵝事件影響，增量市場轉為存量市場，很多企業不約而同將“降本提效”提上日程。
在資料庫領域，分散式資料庫和雲資料庫進入百家爭鳴的時代，不論是從架構還是從設計上，以及從眾多使用者的實際使用情況上來看，均優於“分庫分表”。在這樣的形勢下，以“降本提效”為目標，二維火也開始了新資料庫的選型。
目前，國內市場上的分散式資料庫主要有兩種：分散式中介軟體再增強產品和原生分散式資料庫。考慮到使用 Cobar 的過往經歷，為了徹底擺脫分庫分表的束縛，二維火著重調研了後者，並最終選擇 OceanBase。總的來說，二維火最終選擇 OceanBase 的主要原因如下：
首先，原生支援多副本資料強一致，保障資料安全。 OceanBase 每個節點均支援讀寫，分割槽的資料副本根據規則設定在多個節點同步。同一個分割槽的多個副本基於 Paxos 一致性協議保證副本的強一致。主分割槽擁有資料最新版本，具備強一致性讀和寫能力，備分割槽具備弱一致性讀能力。
其次，大叢集多租戶模式在保留隔離能力的同時又能提高資源利用率，方便管理且降低運維成本。 OceanBase 採用原生多租戶設計，支援將多個傳統資料庫合入一個叢集，租戶間資料相互隔離，可設定各自資源佔用，並支援平滑擴充套件收縮。
▲OceanBase 多租戶
最後，OceanBase 儲存層基於 LSM-Tree 架構，寫入先進記憶體，磁碟上基線 SSTable 相對靜態，為資料編碼/壓縮的實際應用打下良好基礎。 透過在變長 16K 微塊上應用字典、RLE、差值、常量等編碼方式，行列混存，編碼後的資料進行 ZSTD 壓縮，可以大幅節約儲存空間，對海量資料場景非常友好。配合 Block/Row/BloomFilter 多級快取，降本提效雙管齊下。
一個典型的表訪問流程
成本顯著降低，歸檔效能提升
在決定和實踐之間有一項關鍵能力需求：出於對服務高可用性的堅持，避免不必要的停機，二維火需要整體的遷移切流方案面對基於 Cobar 的應用系統支援灰度切流和反向增量。
從業務上來看，有了這項保障，假設更換系統後出現任何短時間無法解決的問題，都可以切回源端，最大限度降低對業務的影響；
從技術上來講，這意味著當業務流量已經部分切流的情況下，遷移程式能夠區分在目標端上的業務增量和同步增量，並準確的把業務增量透過 Cobar 中介軟體層回寫至源端，以時刻保持兩邊的同步。
從 Cobar 遷移至 OceanBase
可惜的是，OMS（OceanBase Migration Service，OceanBase 資料遷移工具）一開始並不具備此項能力，我們只好等待。可喜的是，短短數月後再次溝通，OceanBase 團隊已經將此項功能開發、驗證、打磨完畢，產品迭代發展速度出乎我們的意料。
掃清了切流障礙，二維火選擇儲存量大、寫多讀少的歸檔庫作為試點遷移至 OceanBase，遷移/切流過程順利：對源端每個 MySQL 物理例項建立正向鏈路遷移/同步資料至目標端 OceanBase，同時建立一條 OceanBase 至源端中介軟體層的反向鏈路，OMS 的資料校驗功能也確保了資料的無損和一致。
在 OceanBase 側驗證各項業務操作後，應用伺服器透過滾動重啟的方式切換資料來源，實現業務無感線上切換。
歸檔庫切換 OceanBase 後，憑藉 OceanBase 的高階壓縮技術，所需儲存空間縮減至原有的 1/5，降本效果立竿見影；同時，得益於原生分散式架構，資料歸檔和歷史資訊查詢的效能也有了明顯提升。
從理論分析到切流驗證，整個過程一氣呵成，這給了二維火將變革向其他應用推動的信心和決心。目前，二維火正在將點餐、營銷、管理、供應鏈等餐飲服務進行數智化升級，以期為商家提供更高效、智慧的服務，助力商家成功。同時，我們也期望 OceanBase 公有云產品早日上線 binlog service 服務，讓現有業務系統的遷移免去適配的成本，為二維火的產業升級持續助力。