怪獸充電作為共享充電寶第一股，業務增長迅速，以至于業務架構不停地增加組件。在驗證 OceanBase 可以簡化架構并帶來更大的業務價值后，首次嘗試在歷史庫中使用 OceanBase 替代 MySQL，存儲成本降低 71%。本文為怪獸充電運維架構部王霖對本次數據升級的經驗總結、思考。

2017 年，“共享經濟”成為年度熱詞，彼時共享單車 ofo 正紅極一時，共享充電寶也正在市場擴散。就在這一年，怪獸充電成立，并后來者居上于 2021 年在納斯達克上市。早在三年前怪獸充電的累計注冊用戶超 2 億，到今年第二季度，注冊用戶數已經到了 3.625 億，日均單量達 190 萬筆。

持續涌入的用戶帶來了業務的快速增長，業務系統架構逐漸變得復雜。目前采用的是混合云架構，由于系統中微服務和數據組件較多，因此我們開發了維護云+IDC、覆蓋基礎設施/中間件/微服務的 DevOps 平臺 Hydra 進行統一維護管理。下表是目前我們用到的數據庫。

在我看來，使用新技術通常有兩種路徑，一種是當前技術無法滿足需求進而尋求解決方案，另一種是新技術能夠提供更高的效率，帶來更大的價值。

而我們屬于后者，之所以會替換現有數據庫方案，源于 OceanBase 的技術分享。當我們聽完產品特性和技術方案的介紹后，認為 OceanBase 是對怪獸充電現有架構和業務比較有利的工具，但也存在一些疑慮。

其一，面向 C 端用戶的業務尤其是關鍵業務，在數據庫選型時需要更加嚴苛的考慮，避免切換數據庫帶來的任何潛在風險；

其二，對于 IDC 中的用戶而言使用開源產品是更合適的，但以過往使用開源產品的經驗來說，來自社區的支持力度較小；

其三，我們對 OceanBase 的底層語言 C++ 不是很熟悉，擔心上手門檻較高。

在深入了解 OceanBase 產品及社區后，上述疑慮都打消了。OceanBase 有很活躍的用戶答疑群、社區論壇，能夠及時解答用戶提出的問題。此外，社區會舉辦豐富的線上、線下交流活動，對于開源用戶的支持力度讓我們對 OceanBase 建立了信心，所以我們決定試試。

在 IDC 中部署 OceanBase 后，我們對比了 OceanBase 與 MySQL 的使用效果，對怪獸充電的業務情況而言，OceanBase 的優勢主要有以下兩方面。

第一，可擴展性強。OceanBase 既可以垂直擴容，也可以水平擴容，擴縮容快速、透明、方便，而 MySQL 水平擴容的方式是分庫分表，維護成本相對更高。

第二，節省存儲資源損耗。此前部署 MySQL 時，我們制定了統一的物理機標準，采購相同標準的 CPU 和內存，在此基礎上做虛擬化及資源的分配。為此我們還自研了一個調度系統，目的是跟不同的 CPU 內存和磁盤的比例做調配，盡量減少資源損耗。由于 IDC 的容量并不大，導致存儲碎片化嚴重：比如創建的某個數據庫存儲用量比較大源，而 CPU 內存占用卻很少，這時候雖然物理機上 CPU、內存使用率低但因為磁盤空間已被占用而無法分配新的數據庫實例，造成極大的資源浪費。我們對單數據庫 OceanBase 和 MySQL 的數據占用：

如果部署單實例，數據占用對比是 1:6.8；如果部署 OceanBase 三副本，MySQL 做主從的話，數據占用對比為 1:4.6。可見，OceanBase 在存儲方面的優勢顯著，可以顯著降低我們 IDC 的存儲用量。

此外，在我們測試性能時，發現了 OceanBase 的另一個特點。在低并發情況下，OceanBase 4.0 版本的性能比 MySQL 5.7 低 ，而在高并發環境下，OceanBase 4.0 表現的性能優于 MySQL 5.7。

綜合上述測試情況和優劣勢分析，我們部署了OceanBase 4.0，接下來介紹當前應用情況。

怪獸充電的訂單業務主要是充電寶，其特點是客單價較低、單量大，下圖是訂單業務使用的數據庫情況。

從圖中可以看到，訂單業務涉及的數據庫包含三部分。

• 實時數據庫支持用戶下單，涉及高并發場景。為了提升高并發能力，我們按照用戶分了 8 個庫，并使用 ShardingSphere JDBC 接入遷移服務。

• ElasticSearch 集群是為滿足后臺多字段的聯合查詢需求。在業務數據量不斷擴大的情況下，后臺查詢若是用實時庫查詢，其索引無法覆蓋所有的查詢場景，由此引入 ElasticSearch 集群。遷移服務也寫入 ElasticSearch 集群，通過 Binlog 訂閱實時數據庫的數據。

• 歷史數據庫在使用 MySQL 時采用分庫分表方案，它的特點就是更新的需求很少。每天會有一個實時的任務，去把實時數據庫中的歷史數據定時寫入歷史數據庫。歷史庫的數據量較大，從 8 個庫分到 64 個庫（schema），放到 8 個實例中，總體數據量約 9.6TB，單庫中最大的表數據超過 2 億行。

基于訂單業務的數據庫情況，我們決定第一步將歷史數據庫遷移至 OceanBase，降低存儲成本與運維成本。原因是：其一，歷史庫的數據量級龐大，OceanBase 的優勢之一就是降存儲成本；其二，從 MySQL 的 64 個庫到 OceanBase 單庫，運維與維護成本會極大降低；其三，歷史庫讀寫場景較少，涉及少量精確的查詢，且不影響用戶下單，遷移的風險較小。

第一步，我們在 IDC 部署 OceanBase 集群。OBCluster 分了三個 zone 和三個server，分別部署在三組機架中；單主機規格為 40 核 128G，考慮到日常讀寫量和存儲成本，我們僅僅在日志盤上使用了 SSD，數據盤使用的是機械硬盤。由于 OBProxy 是無狀態服務，因此通過 Helm 被部署在 K8S 集群里。

第二步，使用 OMS 同步數據。首先我們使用 OMS 同步 64 個數據庫到 OceanBase，這里面存在一個多庫匯聚到一個庫的問題，那么，我們需要建 64 個數據同步對象嗎？其實不用，OMS 的配置遷移對象的匹配規則能力，使分庫分表的數據源遷移到 OceanBase 變得非常簡單高效，對于我們 8 個數據庫實例共 64 個庫，建 8 個同步對象就行了，通過簡單的配置可以實現每個實例上多個庫的數據匯聚同一個 OceanBase 庫。

為了確認 OceanBase 的穩定性，我們服務會保持一段時間的雙寫，等驗證完會完全切換到 OceanBase 上。

接入 OceanBase 后，我們的存儲成本節約了 71%，總的存儲量從原來的 9.62TB*2（9.62 為單 MySQL 實例，考慮主從高可用部署所以乘以 2）到現在的 5.6 TB（三副本的總存儲量），短期之內我們不用再考慮數據庫擴容的問題了。

另外，我們在遷移過程中也遇到一些問題，可供大家參考。

第一，OBServer 與 Dell Raid 高速緩存兼容性問題：Dell Raid 卡高速緩存配置中，寫策略為默認“回寫”，改為“直寫“后恢復；

a. 有租戶 clog 滿，擴容之后也會一直上漲；

b. 租戶無法正常合并；

c. OBServer 啟動日志中有大量關鍵字為"ret=\-4070"的 WARN 報錯，有個關鍵信息"failed to fetch and submit single log"，就是合并時無法讀取日志，已經可以定位到 OBServer 合并場景中，有 I/O 操作不成功；

d. 后續定位到 Dell 陣列卡高速緩存配置中，寫策略為默認的“回寫”時，會引發單測復現問題，改為“直寫“后恢復，相關問題也已經反饋 Dell。

第二，機械盤部署問題：在 OceanBase 實例上做壓測時，因為磁盤性能不佳，導致日志流同步出現落后，進一步觸發副本 rebuild。OceanBase 社區表示后續會優化一下對機械盤的兼容性。

目前訂單業務的歷史數據庫遷移已完成，正式用于生產環境。經測試驗證，在查詢場景下 OceanBase 同樣有著優秀的性能表現。接下來我們考慮將查詢場景也遷移至 OceanBase，包括服務后臺查詢和報表查詢。

• 服務后臺查詢：服務后臺查詢和上文提到的訂單后臺查詢類似，用 MySQL 做相關的 OLTP 的操作，數據通過 Binglog 訂閱同步寫入Elasticsearch，整體成本較高，包括 MySQL 和 Elasticsearch 存儲的重疊、中間鏈路數據同步服務的支撐等。因此，后續計劃通過 OceanBase 替代 MySQL + Elasticsearch 的架構。

• 報表查詢：報表查詢當前的現狀是，數據存儲在 MySQL，遇到一些數據聚合量比較大的 SQL 查詢時非常慢，影響系統穩定性。因為涉及一些 OLAP 的場景，考慮到 OceanBase 會比 MySQL 更合適，接下來會部署 OceanBase 對應的規格，并做流量回放比對驗證。

在使用 OceanBase 的過程中，也讓我們對其產生了一些功能上的期望，主要包括以下四點。

第一，期望 OMS 支持 MySQL 到 Rocket MQ 的數據遷移。在 IDC 側，數據遷移的場景包括兩部分。一部分是 MySQL 到 MySQL 的數據同步使用某其他國產數據庫開源的 DM 工具，包括全量同步和增量同步；另一部分是從 MySQL 到 Rocket MQ 的數據同步使用 canal。我們調研了OceanBase 的 OMS，雖然使用體驗不錯，但發現社區版不支持數據從 MySQL 同步到 Rocket MQ。因此，我們希望能否將 OMS 開源，以共建的方式補全功能。這樣一來，我們就可以將整體的遷移框架統一到 OMS 中。

第二，監控告警，以方便接入開源的監控告警體系。我們希望相關的組件能夠提供 metrics 指標，以便接入我們內部的監控告警，同時提供一些 Grafana 面板，提供建議的告警表達式。

第三，問題排查更加智能化。當前，我們依賴 OCP 中比較完善監控指標和專家知識，而我們希望這部分變成自動化工具，包括自動分析、自動提供解決方案或工具等。

第四，開源或開放流量回放工具。