致歐家居股份有限公司是中國跨境電商行業裡的翹楚，產品先後進入西歐、北美、日本等超過 50 個國家和地區市場，總體客戶評價在各銷售渠道排名前列。目前已經成為亞馬遜歐洲第一大家居賣家，也是中國內陸最大的 B2C 跨境電商出口品牌之一。2021 年營收近 60 億，同比增長 100%。

隨著跨境業務的高速度發展，致歐對後端業務系統的承載能力要求不斷提高，特別是對系統的穩定性，連續可用，安全性等各方面有了更高的要求，對此我們特別邀請了致歐家居總架構師朱輝，從當前業務現狀出發，梳理出面臨的一些挑戰，以及相應的規劃，給大家講述致歐家居上線 OceanBase 的故事。

朱輝：第一代網際網路從業者，從微控制器到雲，從 CGI 到 MicroService，見證、參與著行業的發展。實現了一個個的從零到一的跨越，完成了一個又一個創新的專案。

業務的現狀

• 外購系統比較多，技術架構差異比較大。當前開發語言有 java、php、go，多個系統交織在一起，業務複雜度高；

• 資料庫型別較多。MySQL、sqlserver、mongodb、postgres，加上業務系統參差不齊，使日常運維管理工作比較繁雜，對運維人員要求高； 

• 部分業務系統對 MySQL 使用比較深入，對資料庫功能依賴高，使用了大量的儲存過程與觸發器，據不完全統計在其中一個業務庫中儲存過程多達 1200 多個，一個過程程式碼多達 6000 行。

• 資料庫運維管理成本高。目前資料庫例項分佈在不同平臺如 aws 歐洲、aws 北美、阿里雲香港、阿里雲歐洲以及自建 IDC 機房，不同地域的資料庫例項、架構、資源不盡相同；不同地域、不同時區的差異在無形中加大了運維管理的要求與成本；

• 資料庫例項以傳統單例項為主，不能橫向擴容，滿足持續的業務增長需求。

面臨的挑戰

基於以上現狀，致歐家居面臨的挑戰有：

• 業務推廣流量大、有高併發需求，當前資料庫基本上是單例項的傳統資料庫，隨著業務的增長並不能做橫向的擴容，活動推廣，秒殺場景下易導致業務系統癱瘓；

• 資料量快速增長，傳統資料庫單例項難支撐，需按需對儲存擴容；

• 業務高速發展，系統對資料庫可用性、安全性、可靠性，運維穩定要求增加，單例項資料庫 RTO 與 RPO 難以滿足業務發展需求；

• 業務平臺分佈全球，資料需要融合匯聚，以做分析決策，對資料庫要求有 HTAP 功能；

• 資訊系統國產化自主可控要求；

• 公司開源節流，降本增效要求。

為什麼選擇 OceanBase 

從實際情況出發，致歐家居對目前主流的分散式資料庫進行了對比了解，最後發現，無論是從資料庫的產品功能還是產品體系上，OceanBase 都比較完善，可以很好地解決當前業務架構中的痛點。

具有完善的資料庫功能與配套開發運維管理工具

• 優雅的核心架構；

• 相容 SQL 協議：同時相容 MySQL 與 Oracle，特別是相容儲存過程、觸發器、自定義函式，現有業務系統可以平滑的遷移，對業務系統無侵入；

• 儲存：自研分散式儲存引擎，資料壓縮比高，同比 MySQL 有 5～7 倍壓縮比；

• 資料副本：分為全能型(讀寫)、加密投票型副本、日誌型、只讀型，可根據不同業務效能與 SLA 要求選擇相應的架構；

• 分散式事務：讀寫分離，DML 操作記憶體，讀事務操作基線資料；

• 運維管理：豐富的效能檢視，四大產品家族集開發、部署、資料遷移以及自動化運維於一體化；

• 資料遷移：基於 OMS 工具，按圖索驥一站式遷移資料，集全量、增量、資料校驗、反向同步鏈路於一體。

效能適配

在效能上，我們基於OB進行相應的效能驗證，以查驗對應的效能是否能滿足業務的需求，以下是相關的基準測試情況：

• cpu:mem:disk=16c:100G memory:120G ssd

• 環境與版本資訊: 專有云部署 3.2.2版本

• 表數量：32

• 單表資料量：1kw

• 每個場景thread測試時間：5min

• 測試工具：sysbench

• 相關命令：sysbench --config-file=config oltp_point_select  --tables=32 --table_size=10000000 --threads=8 --db-ps-mode=disable --mysql-ignore-errors=6002,6004,4012,2013,4016 prepare

• 架構：同一機房三節點，三個資料節點，一個日誌型節點，具體如下

• 測試結果：

• OS 監控：

透過以上的部署架構可以看到，OceanBase 在副本的選擇上非常的靈活，可以根據不同的業務需求來選擇副本型別。對應的資料庫基測試 IO 都處於理想的狀態，相應的 TPS 與 QPS 都符合預期。

遇到的問題與解決方案

由於表數量不少，datax 的配置檔案是以表為單位進行配置的，在這裡我們 DIY 了一個指令碼，自動生成配置檔案，然後再批次執行遷移任務。

與此同時，反向同步也是一個全量的過程，這個過程我們提前測算好正向與回退的時間，以及業務的驗證時間，變更的時間視窗為：正向+反向+2倍驗證的時間。

Q2：對於遷移有資料的表，存在索引名與表名相同時報錯，如下表定義：

create table t_xxxxx(  `id` int unsigned not null auto_increament ,  `code` bigint(20),  ......);create index `code` on `t_xxxxx`(`code`);

這個問題在反饋之後的兩天內，產品就迅速解決了這個問題，效率很高。

收穫、規劃與期待

• 資料遷移過程中要可以使用 OMS 與 datax 搭配使用，可以快速解決 MySQL 模式下無主建表的遷移；

• 外購系統中存在很多設計不規範的地方，如表欄位、索引的命名；

• 對於表結構要儘可能的有主鍵設計，特別是一些核心表；

• 遷移到 OceanBase ，對於核心的大表需要認真的規劃，如是否要分割槽、與其他相關聯的表是否要考慮做表組；

接下來，我們計劃繼續使用 OMS 工具遷移其他業務系統到 OceanBase ，達到跨境多雲資料融合目標，如下圖所示：

• OceanBase 的核心功能進一步完善與加強，更加完美的相容 MySQL 語法，對於業務的適配更加友好。

• OMS 在資料的傳輸與轉換過程中能勝任更多的場景，如從 sqlserver、postgres 等其他資料庫遷移到 OceanBase ；支援基於列或是 SQL 的資料脫敏或轉換。