> 導語：面對業務多元、資料海量、資料庫種類多樣、多雲架構複雜等痛點，該如何制定既能解決問題又能降本增效的資料庫升級方案？作業幫作為實踐者，從四方面分享其資料庫選型過程與思考。以下為作業幫DBA劉強在DTCC大會中的講述。
>
> 嘉賓介紹：劉強，作業幫高階DBA。多年資料庫運維經驗，要負責MySQL、Redis、TiDB和 OceanBase 等不同資料庫的使用與探索，資料庫管理平臺的開發工作。重點工作方向是分散式資料庫在公司內部的推廣和使用；配合業務部門進行需求測試以及方案落地。

## 作業幫資料庫生態痛點及選型訴求

今天主要和大家分享作業幫在升級資料庫方案時的選型思考，以及對 OceanBase 的嘗試初體驗。

大家都知道，作業幫作為線上教育的領軍品牌之一，旗下有多款教育軟體產品與硬體產品，而且每個產品背後的業務都有不同的特性和訴求。在這個背景下，我們的資料庫狀態呈現出五個特點。

![Image](https://img.alicdn.com/imgextra/i3/O1CN01OeU8Rc1DfL3InQ4p4_!!6000000000243-2-tps-920-404.png)

### 資料庫種類多樣

為了更好地承接各類業務需求，作業幫使用不同的資料庫產品來支撐不同的業務。目前使用的資料庫主要有MySQL+Orch、Redis-Cluster、MongoDB、Elasticsearch、TiDB和 OceanBase。

### 業務需求多元

經過幾年的沉澱，目前我們公司的線上教育相關軟硬體業務線較多, 資料庫的使用場景也越來越細分化，對資料處理的靈活性和高效性都提出了更多的要求。比如 MongoDB的Schema Design特性，對第三方資訊的獲取、Json格式文件儲存提供了非常靈活高效的存取方式，再比如Elasticsearch在業務日誌的儲存分析、在大資料的快速聚合分析、基礎運維指標的採集監控等場景都有明顯優勢。

### 多雲架構複雜

作業幫是一個多雲架構，在雲原生的大背景下，作業幫使用阿里雲、騰訊雲、百度雲三雲架構。業務流量主要分佈在騰訊雲上，其次是阿里雲和百度雲。

我們選擇多雲的主要原因是保證業務的連續性，避免因雲廠商的設施故障導致線上業務的中斷；另外一個比較重要的原因是可以結合每個雲廠商特有的優勢，更好的為業務賦能。

同時這種多雲環境對資料庫的高可用架構提出了更高要求。

### 海量資料儲存

相信很多MySQL使用者都會遇到單機儲存瓶頸帶來的困擾，通常，解決辦法要麼是定期清理資料，要麼分庫分表，這都會給業務人員和DBA人員增加額外的工作。作業幫也不例外，解決單機儲存問題是我們使用分散式資料庫最基本的需求。

### 運維管理智慧

很多公司會針對不同資料庫來開發自己的運維管理平臺，以提升對資料庫管理的敏捷性和可靠性。而完善的運維管理平臺對DBA人員來說，意味著一項複雜且週期較長的工作。

總結來說，業務場景的技術需求和企業降本增效的訴求驅動我們進行資料庫方案的替換和升級，我們把目標瞄準在分散式資料庫領域。

- 業務場景的技術需求：

1. 作業幫有很多業務不需要分庫分表的設計模式，這樣可以減少對業務程式碼的侵入，也可以減輕DBA的壓力。

2. 承接複雜的查詢操作，有時業務會查詢一些掃描量較大的資料，也會經常去執行輕量級的OLAP型別的 SQL，而使用MySQL時總會出現響應不及時、跑不出資料的情況。

3. 探索多雲架構下資料庫叢集的解決方案。

4. 對歷史資料的歸檔。

- 降本增效的訴求：從資料儲存的角度進行壓縮，或對主機的CPU和記憶體進行更高效的利用。

![Image](https://img.alicdn.com/imgextra/i3/O1CN01jWbiMi1tOaQSs99UY_!!6000000005892-2-tps-904-496.png)

## OceanBase與TiDB的測試對比

在很早之前，我們就對 OceanBase 有所耳聞，但僅停留在“一款完全自主研發的優秀的資料庫”這樣的印象中。在 OceanBase 開源後，我們開始關注它並對它進行深入瞭解。

就在11月3日，OceanBase 社群版 4.0 釋出，我們立即對 OceanBase 4.0做了進一步的調研和測試。結果，我們發現 OceanBase 主要有以下幾個特點：

- 彈性擴縮容：能夠很好地解決作業幫最基本的單機儲存瓶頸問題。

- 資料壓縮比、多租戶模式：這兩個特效能夠幫助作業幫真正做到降本增效，尤其是OceanBase 4.0支援對CPU進行超賣分配，可以使我們更充分地利用硬體資源。

- OLTP 效能高：我們只進行了最基本的sysbench壓測，效能超出了我們的意料，在高併發情況下，SQL的響應耗時依然維持較低的水平。

![Image](https://img.alicdn.com/imgextra/i3/O1CN01bFmjaG1GL8QXmam3d_!!6000000000605-2-tps-904-406.png)

- 
  業務相容性：如果想從MySQL切換至 OceanBase，與 MySQL 5.7.24相容性的對比是很重要的一點，我們測試了 OceanBase 4.0後，發現相容性很高。

- 管理易用性：我們使用的資料庫如MySQL、Redis等，都需要自己開發管理平臺。OceanBase 的 OCP管理平臺由於其功能完善，且使用方便，對我們DBA人員來說能解放很大一部分生產力，因此有較大的吸引力。

由於我們的部分業務使用TiDB作支撐，因此，在測試 OceanBase 的過程中，我們也對二者進行了橫向對比，資料如下。

![Image](https://img.alicdn.com/imgextra/i3/O1CN01bQc17n1bKm2xRqu9Y_!!6000000003447-2-tps-904-384.png)

我們在資料寫入後對比發現：

- OceanBase 在儲存效率方面相較於TiDB節省了35%以上的磁碟空間。

- 在相容性上，TiDB與 OceanBase 的表現都很好，相較而言，TiDB涉及的業務改造較少，但主鍵操作受限，OceanBase 則可能涉及將表改成分割槽表的成本投入。

- 在運維管理方面，TiDB的監控比較完善，OceanBase 的優勢在於其運維管理平臺（OCP）易於使用，可以極大地減少DBA的開發管理工作。

- 關於資料同步元件，TiDB的DM相對來說比較完善，在我們的業務中使用較多，OceanBase的OMS在我們的測試中表現也比較亮眼，但對於我們的業務場景來說，還有一些功能需要進一步完善。

- 我們也關注到TiDB不支援多租戶模式和多副本型別，而 OceanBase 對多租戶模式的支援可以幫助我們高效利用資源，而且，OceanBase 還支援只讀副本和日誌副本。

- 另外，我們也很看重DDL的響應，OceanBase 和TiDB在加欄位方面都是秒級響應，在加索引或修改一些欄位型別的情況下，可能會涉及資料的複製，但並不阻塞讀寫。

## OceanBase 方案實現資源隔離與快速響應

基於以上的調研和測試結果，我們選擇使用 OceanBase 承接一些離線資料查詢需求。

作業幫的業務人員經常需要連線MySQL來查詢線上資料，時常會有一些慢SQL導致線上存庫所在的主機效能抖動，影響線上業務。我們將MySQL透過工具同步到 OceanBase 後，將業務查詢平臺的入口資料來源改成 OceanBase，同時對同步工具進行監控。如果發現了中斷，或者有比較大的延遲，我們也會將這個查詢的入口切換回 MySQL。

下圖是使用 OceanBase 後的架構，該架構實現了資源隔離，極大地減少了對線上資料庫不必要的影響。同時，在使用MySQL時一些耗時較長或對線上影響較大的SQL，在 OceanBase 中都能快速響應。後續，我們會將作業幫內部對統計分析類業務逐漸遷移到 OceanBase 中。

![Image](https://img.alicdn.com/imgextra/i2/O1CN01YchEVL23Tl3eGarJU_!!6000000007257-2-tps-920-374.png)

## 期待 OceanBase 解決作業幫多雲環境的四個問題

我在文章開頭提到，作業幫採用的是多雲環境，如下圖所示，三個機房之間有機房專線，業務流量分佈不均勻，主要的業務流量都在騰訊雲，阿里雲和百度雲會分佈層級節點。作業幫的業務部署流量是實現單元閉環，每個機房都部署業務，這個業務只訪問本機房內部的資料庫入口節點（業務訪問路徑是App -> Proxy->MySQL）。

![Image](https://img.alicdn.com/imgextra/i3/O1CN01WL5BML1n7Hlp9kp7d_!!6000000005042-2-tps-686-448.png)

這個多雲架構存在四個問題。

**第一個問題，** 在專線抖動的情況下，當阿里雲的業務節點需要向master進行寫資料的時候，會出現寫入失敗的情況。我們的基本訴求是業務節點在阿里雲內能夠實現只讀，這樣可以儘可能地減少對業務的影響。

**第二個問題，** 專線故障。當騰訊雲和阿里雲之間出現了專線故障且長時間不可恢復，此時在保證高可用不會誤切主的前提下，通知業務將阿里雲的業務流量排程到騰訊雲, 等專線恢復後再將架構復原。

**第三個問題，** 機房級別的故障。機房級別的故障分為主機房不可用和主機房可用兩種情況，如果主機房可用，而主機房和其他兩個機房都實現了網路隔離，我們會優先將業務流量切換到騰訊雲，這樣能保證絕大部分流量不用進行切換處理。

**第四個問題，** 基礎機房不可用，導致騰訊雲整個系統故障。此時我們會進行資料庫層面的切換，將主節點切換到阿里雲或百度雲，再將騰訊雲的業務流量切換到新的叢集主節點中。

基於我們的業務流量分佈特點和架構情況，當前高可用架構的主要痛點在於如何保證其穩定性並在極端網路情況下不發生腦裂。同時，基於MySQL的雙活架構，實現難度也較大。

那麼，OceanBase 是否能給我們帶來更好的解決方案？

OceanBase 不需要額外的高可用管理元件，使用Paxos協議能更好地保證高可用架構的穩定性，且避免了腦裂的情況。

在我們同城三機房的背景下，我們使用三zone五副本的方式部署一套叢集，能夠滿足絕大部分業務需求。同時，在單雲化改造方面提供了較為完善的解決方案。

![Image](https://img.alicdn.com/imgextra/i1/O1CN01HMt7lz1UA3SxxtStJ_!!6000000002476-2-tps-904-444.png)

假如我們按照使用者的某個維度進行資料分片，一個機房一個分片表，透過leader的排程功能將leader副本排程到本機房內，每個機房的業務單雲在本機房實現流量閉環讀寫。

除此之外，據 OceanBase 的工程師透露，OceanBase 的主備叢集的的功能將會在 OceanBase 開源4.1版本中釋出，這讓我們非常期待。因為該架構的主要優勢在於可以進行異地機房的資料容災，且備叢集只需要單個副本，架構易於管理且成本低。

![Image](https://img.alicdn.com/imgextra/i3/O1CN01HT13eq1xvnbxf3cLQ_!!6000000006506-2-tps-904-540.png)

## 寫在最後

**基於 OceanBase 的種種優勢，比如高效的資源利用、靈活地副本排程、穩定地高可用架構等，我們將陸續在公司內部進行推廣，並連同業務嘗試單元化方案的改造和落地。**

另外，OceanBase 企業版的一些優秀特性如透明加密，我們也會持續關注並在適當的時機推進商業化服務的合作。

作業幫：探索多雲架構下的資料庫叢集解決方案

相關文章