--- title: 跨境电商数据融合实践｜OceanBase 助力致欧家居打造分布式跨境电商 description: 致欧家居股份有限公司是中国跨境电商行业里的翘楚，产品先后进入西欧、北美、日本等超过 50 个国家和地区市场，总体客户评价在各销售渠道排名前列。目前已经成为亚马逊欧洲第一大家居卖家，也是中国内陆最大的 B2C 跨境电商出口品牌之一。2021 年营收近 80 亿，同比增长 100%。随着跨境业务的高速度发展，致欧对后端业务系统的承载能力要求不断提高，特别是对系统的稳定性，连续可用，安全性等各方面有了更 image: https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*OSPzQ6GUQF4AAAAAQHAAAAgAeiGDAQ/original --- 切换语言 - 中文站 - 简体中文 - International - English - 日本站 - 日本語 [AI](https://www.oceanbase.com/obi) 咨询热线 # 跨境电商数据融合实践｜OceanBase 助力致欧家居打造分布式跨境电商 2024年03月17日 ![](https://help-static-aliyun-doc.aliyuncs.com/assets/img/zh-CN/8641489461/p429626.png) 致欧家居股份有限公司是中国跨境电商行业里的翘楚，产品先后进入西欧、北美、日本等超过 50 个国家和地区市场，总体客户评价在各销售渠道排名前列。目前已经成为亚马逊欧洲第一大家居卖家，也是中国内陆最大的 B2C 跨境电商出口品牌之一。2021 年营收近 80 亿，同比增长 100%。 随着跨境业务的高速度发展，致欧对后端业务系统的承载能力要求不断提高，特别是对系统的稳定性，连续可用，安全性等各方面有了更高的要求，对此我们特别邀请了致欧家居总架构师朱辉，从当前业务现状出发，梳理出面临的一些挑战，以及相应的规划，给大家讲述致欧家居上线 OceanBase 的故事。 **说明** 朱辉：第一代互联网从业者，从单片机到云，从 CGI 到 MicroService，见证、参与着行业的发展。实现了一个个的从零到一的跨越，完成了一个又一个创新的项目。 ![](https://help-static-aliyun-doc.aliyuncs.com/assets/img/zh-CN/8641489461/p429627.png) **业务的现状** - 外购系统比较多，技术架构差异比较大。当前开发语言有 java、php、go，多个系统交织在一起，业务复杂度高； - 数据库类型较多。MySQL、sqlserver、mongodb、postgres，加上业务系统参差不齐，使日常运维管理工作比较繁杂，对运维人员要求高； - 部分业务系统对 MySQL 使用比较深入，对数据库功能依赖高，使用了大量的存储过程与触发器，据不完全统计在其中一个业务库中存储过程多达 1200 多个，一个过程代码多达 6000 行。 - 数据库运维管理成本高。目前数据库实例分布在不同平台如 aws 欧洲、aws 北美、阿里云香港、阿里云欧洲以及自建 IDC 机房，不同地域的数据库实例、架构、资源不尽相同；不同地域、不同时区的差异在无形中加大了运维管理的要求与成本； - 数据库实例以传统单实例为主，不能横向扩容，满足持续的业务增长需求。 ![](https://help-static-aliyun-doc.aliyuncs.com/assets/img/zh-CN/8641489461/p429628.png) **面临的挑战** 基于以上现状，致欧家居面临的挑战有： - 业务推广流量大、有高并发需求，当前数据库基本上是单实例的传统数据库，随着业务的增长并不能做横向的扩容，活动推广，秒杀场景下易导致业务系统瘫痪； - 数据量快速增长，传统数据库单实例难支撑，需按需对存储扩容； - 业务高速发展，系统对数据库可用性、安全性、可靠性，运维稳定要求增加，单实例数据库 RTO 与 RPO 难以满足业务发展需求； - 业务平台分布全球，数据需要融合汇聚，以做分析决策，对数据库要求有 HTAP 功能； - 信息系统自研技术可靠要求； - 公司开源节流，降本增效要求。 ![](https://help-static-aliyun-doc.aliyuncs.com/assets/img/zh-CN/8641489461/p429629.png) **为什么选择 OceanBase** 从实际情况出发，致欧家居对目前主流的分布式数据库进行了对比了解，最后发现，无论是从数据库的产品功能还是产品体系上，OceanBase 都比较完善，可以很好地解决当前业务架构中的痛点。 具有完善的数据库功能与配套开发运维管理工具 ![](https://help-static-aliyun-doc.aliyuncs.com/assets/img/zh-CN/8641489461/p429630.png) - 优雅的内核架构； ① 基于 paxos 协议同步数据，节点之间使用 Paxos 复制数据要比 Raft 更优 ② 多租户管理模式，可以很好的对系统资源按租户隔离，各租户之间可以各自指定 leader 节点，可以充分的利用各节点的 CPU 与 IO 隔离 ③ 分区与表组功能可以按需设计，减少分布式事务 - 兼容 SQL 协议：同时兼容 MySQL 与 Oracle，特别是兼容存储过程、触发器、自定义函数，现有业务系统可以平滑的迁移，对业务系统无侵入； - 存储：自研分布式存储引擎，数据压缩比高，同比 MySQL 有 5～7 倍压缩比； - 数据副本：分为全能型(读写)、加密投票型副本、日志型、只读型，可根据不同业务性能与 SLA 要求选择相应的架构； - 分布式事务：读写分离，DML 操作内存，读事务操作基线数据； - 运维管理：丰富的性能视图，四大产品家族集开发、部署、数据迁移以及自动化运维于一体化； - 数据迁移：基于 OMS 工具，按图索骥一站式迁移数据，集全量、增量、数据校验、反向同步链路于一体。 ![](https://help-static-aliyun-doc.aliyuncs.com/assets/img/zh-CN/8641489461/p429631.png) 性能适配 在性能上，我们基于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 - 架构：同一机房三节点，三个数据节点，一个日志型节点，具体如下 ![](https://help-static-aliyun-doc.aliyuncs.com/assets/img/zh-CN/8641489461/p429632.png) - 测试结果： ![](https://help-static-aliyun-doc.aliyuncs.com/assets/img/zh-CN/8641489461/p429633.png) ![](https://help-static-aliyun-doc.aliyuncs.com/assets/img/zh-CN/8641489461/p429634.png) ![](https://help-static-aliyun-doc.aliyuncs.com/assets/img/zh-CN/8641489461/p429635.png) ![](https://help-static-aliyun-doc.aliyuncs.com/assets/img/zh-CN/8641489461/p429636.png) ![](https://help-static-aliyun-doc.aliyuncs.com/assets/img/zh-CN/8641489461/p429637.png) - OS 监控： ![](https://help-static-aliyun-doc.aliyuncs.com/assets/img/zh-CN/8641489461/p429638.png) ![](https://help-static-aliyun-doc.aliyuncs.com/assets/img/zh-CN/8641489461/p429639.png) ![](https://help-static-aliyun-doc.aliyuncs.com/assets/img/zh-CN/8641489461/p429640.png) 通过以上的部署架构可以看到，OceanBase 在副本的选择上非常的灵活，可以根据不同的业务需求来选择副本类型。对应的数据库基测试 IO 都处于理想的状态，相应的 TPS 与 QPS 都符合预期。 ![](https://help-static-aliyun-doc.aliyuncs.com/assets/img/zh-CN/8641489461/p429641.png) **遇到的问题与解决方案** 我们在从 MySQL 实例迁移到 OceanBase 的过程遇到了不少问题，这些问题虽然给我们带来了不少麻烦，但是在 OceanBase 研发的技术支持下，都得到了很好的解决，下面列举几个比较典型的问题。 **Q1：在 MySQL 模式下，对没有主键或唯一键的表迁移，OMS 不支持。** 这个问题在 OMS 产品文档中有明确说明。由于我们的不少系统是外购来的，有不少表就存在有主键与唯一键这样的问题，且部分表的数据量还不小。 要如何解决这个问题呢，在我们与 OceanBase 产研同事的沟通中了解到，对于这种无主键或是唯一键的表，在 Oracle 模式下，对于这种表是可以支持的，其原因是由于 OMS 自动帮忙加了一个隐藏的主键，在正式切换上线时删除，而在 MySQL 模式下，在全量迁移完之后，增量数据同步时性能会非常差，对于大表甚至于没法做，对于这类表，目前只能通过类似左 datax 的数据传输工具来处理。 关于 datax+OMS 的解决方案—— 表结构迁移：手动导出导入处理 数据迁移：使用 datax 做全量数据迁移 数据校验: OMS 支持单独选数据校验这一步 增量数据同步：这一步做不了 回退：使用 datax+OMS 反向同步 由于表数量不少，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 不支持，OceanBase 的临时解决方案是通过改索引名的方式来解决，最终的解决方案则是通过 OMS 产品功能研发支持。 这个问题在反馈之后的两天内，产品就迅速解决了这个问题，效率很高。 **Q3：存储过程不支持 GET DIAGNOSTICS CONDITION 语法。** 在我们的一个应用系统中，使用了大量的存储过程，其中有不少过程使用了 GET DIAGNOSTICS CONDITION 语法来获取 MySQL 执行过程的异常捕获。 经查验后发现内核不支持 GET DIAGNOSTICS CONDITION 异常捕获，若从业务侧出发来解决的话，300 多个存储过程中，有 200 多个过程用到了这个语法，代码量改动很大，所以最根本的解决方案是从内核上功能支持。 由于 OceanBase 内核对存储过程不支持异常的捕获处理，需要在内核上做功能改进，经过一个多月的研发，产品功能研发完成，业务代码无须做相应的调整，基本上可以做到平滑迁移。 ![](https://help-static-aliyun-doc.aliyuncs.com/assets/img/zh-CN/8641489461/p429642.png) **收获、规划与期待** 虽然在数据迁移、运维管理上，OMS 与 OCP 带来了很大的便利，但是，我们在实际过程中也遇到了不少的问题，特别是一些产品功能上还存在一些缺陷。这些问题在 OceanBase 工程师与研发团队的支持下，第一时间得到了响应，并对产品的不足之处及时进行了跟进与处理，最终得到了很好的解决，这种山穷水复疑无路，柳暗花明又一村的感觉，让致欧家居认识、收获了基于 OceanBase 的应用与实践心得： - 数据迁移过程中要可以使用 OMS 与 datax 搭配使用，可以快速解决 MySQL 模式下无主建表的迁移； - 外购系统中存在很多设计不规范的地方，如表字段、索引的命名； - 对于表结构要尽可能的有主键设计，特别是一些核心表； - 迁移到 OceanBase ，对于核心的大表需要认真的规划，如是否要分区、与其他相关联的表是否要考虑做表组； 接下来，我们计划继续使用 OMS 工具迁移其他业务系统到 OceanBase ，达到跨境多云数据融合目标，如下图所示： ![](https://help-static-aliyun-doc.aliyuncs.com/assets/img/zh-CN/8641489461/p429643.png) 在以上基础上，同时基于 OceanBase 的 HTAP 能力构建实时的分析业务平台。 ![](https://help-static-aliyun-doc.aliyuncs.com/assets/img/zh-CN/8641489461/p429644.png) 当然，经此一役，我们更加坚信 OceanBase 在100%自研的道路上，能更好的发挥自主研发的优势，碰到问题一定可以快速解决，哪怕是内核级的问题，对此我们也热切期待，OceanBase 在产品与功能上更上一层楼： - OceanBase 的内核功能进一步完善与加强，更加完美的兼容 MySQL 语法，对于业务的适配更加友好。 - OMS 在数据的传输与转换过程中能胜任更多的场景，如从 sqlserver、postgres 等其他数据库迁移到 OceanBase ；支持基于列或是 SQL 的数据脱敏或转换。 **后记（架构师感悟）** **OceanBase 架构师何志勇** 致欧科技，作为跨境电商的翘楚，在面临业务爆发式增长，后端 IT 系统和运维带来极大挑战的背景下，毅然绝然的对当前系统与架构进行了改造、变革。在短短的两个月里，迁移了 6 个业务系统到 OceanBase。 虽然很大一定程度上得益于 OceanBase 提供的 OMS 迁移工具，但主要还是依靠致欧科技研发、运维团队的协作，以及 OceanBase 产品的研发力量的共同努力与支持。无论是在迁移前的测试验证，兼容适配，还是在最后的正式上线切割，都保持着认真负责，积极响应，一丝不苟的态度，最后在大家精诚合作的努力下，不断攻克一个个困难险阻，确保在设定的时间内，把多个业务系统迁移到 OceanBase。在这段时间时，与大家一起合作的每一天都是仰拾俯取，收获成长。 诚然，现在我们阶段性的取得了一定的成绩，但是雄关漫道真如铁，而今迈步从头越。致欧未来的规划与展望给了我们前行的压力与动力。期待在产研同学的支持下，OceanBase 能更好地赋能致欧，以及其他像致欧这样的企业，同时也期待，致欧能借助 OceanBase，构建全球跨区域的数据融合管理，为自己的跨境分布式电商业务提供稳健的系统支撑，为出海企业提供可复制的成功案例。 [上一篇 ：意出望外的一次相遇｜利楚初探 O...](https://www.oceanbase.com/news/hs803y) [下一篇 ：OceanBase 在证券行业基...](https://www.oceanbase.com/news/dkm6ui) 热门推荐 - [MySQL能力全开放，OceanBase 社区版 4.0 正式上线](https://www.oceanbase.com/news/apsaradb-rds-for-mysql-v4-0-was-officially-released-making-mysql) 2022年11月04日 - [OceanBase获奖！蚂蚁集团第三次入选世界互联网领先科技成果](https://www.oceanbase.com/news/oceanbase-wins-the-prize-ant-group-was-selected-as-the) 2022年11月11日 - [7.07 亿 TPC-C 背后的技术突破，OceanBase 研究成果入选 VLDB](https://www.oceanbase.com/news/in-0-707-billion-the-technical-breakthrough-behind-the-tpc-c-was) 2022年09月28日