百丽时尚集团是中国一家大型时尚鞋服集团，在中国 300 余个城市拥有直营门店超 9,000 家。建立了以消费者为中心的垂直一体化业务模式，覆盖从时尚潮流研究、商品企划、设计研发、生产制造、商品管理、DTC 零售及客户运营的全价值链，且每个步骤运用数字化技术，并将持续加强科技投入。
目前，零售、电商以及私域流量等业务线涉及在线订单和商品调度等，业务系统的技术架构使用 MySQL+MyCAT 的分库分表的架构，并使用 orchestrator 作为高可用的管理中间件。由于 MyCAT 架构下存在不支持分布式事务、分片业务调整困难和可扩展性差等问题，因此开始考虑使用分布式数据库。自 2023 年初测试 OceanBase 以来，发现其在分布式事务、分布式查询优化、水平可扩展性和周边工具生态方面表现优异，能够精准解决我们之前的痛点并且减少运维难度和成本。本文分享百丽测试和使用 OceanBase4.2 版本的感受。
MyCAT 使用痛点及解决方案
1. 聚合性能不稳定。
百丽时尚此前使用 MyCAT+MySQL 的分库分表架构，MyCAT 作为分布式中间件在聚合查询场景的性能，尤其在多个分片的数据聚合方面的性能容易抖动。使用 OceanBase 后，其作为原生分布式数据库从根本上避免了这类问题。例如，在我们生产环境的一些真实查询场景中，MySQL 需要 10 分钟以上，在 OceanBase 只需要 1 分钟左右，性能提升了 10 倍左右。
2. 数据分片调整困难。
在一些日常运维的过程中，我们会有业务要调整，而 MySQL 的分库分表架构调整起来非常困难。一方面会涉及数据的重分布，另一方面是 DBA 实操的复杂度较高且非常繁重。但是如果在 OceanBase 中，我们只需要调整表分区，OceanBase 会自动对分区做重分布操作，操作非常简洁、讯速，极大地减少了 DBA 的整体工作量。
3. 水平扩容较差。
集中式数据库的水平扩容无法满足不断增长的数据处理需求，而在 OceanBase 中，我们可以根据业务的实际需求和实际情况，有选择性的做水平扩容或垂直扩容，非常灵活。比如可以水平做租户资源，或者在集群级别添加 OBServer 节点；再比如扩容磁盘，我们数据盘的使用率较高，对磁盘扩容后，数据文件也会自动扩展。
原生分布式数据库方案的特点
从集中式数据库替换为分布式数据库，从 MySQL 分库分表架构替换为 OceanBase 单机分布式一体化架构，也让我们对新型分布式数据库的特点有了更加深入的理解，具体而言包括以下五点。
1. 原生分布式事务的支持：通过 2PC 协议，保障事务一致性。
众所周知 MyCAT 不支持分布式事务，在一些极端场景下可能出现事务问题，比如 1PC 阶段这个事务成功了，但在 2PC 阶段事务失败了。OceanBase 的高可用选举和日志同步协议基于 Paxos 一致性协议，任何决策的达成均需要多数派节点达成一致，实现了原生支持分布式事务，保证事务的一致性。
2. 数据复制和冗余。
在 MySQL 中，需要部署一些主从节点来增加它的数据冗余，提高数据高可用，但这样做会增加一些运维成本。那么在 OceanBase 中是如何实现的呢？为了提高数据的可用性和容错性，分布式数据库通常采用数据复制和冗余策略。数据复制可以将数据副本存储在多个节点上，以防单点故障。例如在一个 3 节点的 OceanBase 集群中，数据有三个副本，每个 OBServer 存放一份，每个 OBServer 内都有一份完整的数据。保证单节点宕机的数据可靠性，实现 RPO=0。
3. 数据一致性和同步。
分布式数据库需要确保数据在不同节点间的同步和一致性。常用的方法包括分布式事务和数据复制机制，以保证数据的一致性和可靠性。我们使用 MyCAT 的时候，其实每个分片的数据是不一致的，此时无法保证数据一致性。而在 OceanBase 中，主从副本之间通过基于 Multi-Paxos 的分布式共识协议实现了副本之间数据的一致性。
4. 分布式查询优化。
由于数据存储在多个节点上，分布式数据库需要进行查询优化和查询路由，以最大程度地减少数据传输和查询延迟。关系数据表的数据以分区形式存放在系统的各个节点上，OceanBase 数据库的优化器会自动根据查询和数据的物理分布生成分布式执行计划。当单个查询的访问数据不在同一个节点上时，需要通过数据重分布的方式，相关数据执行分发到相同的节点进行计算，通过并发执行以提高执行效率。比如 auto DOP 会自动加一些并行。对于 AP 场景的业务来说，可以提高执行性能。
5. 高可用性和容错性。
分布式数据库通常具有高可用性和容错性，即使某个节点发生故障，系统仍然可以继续提供服务。OceanBase 每个节点都有一个数据的副本，在某一些节点发生故障的时候，它会自动做副本的切换。当主副本所在节点发生故障时，一个从副本会被选举为新的主副本并继续提供服务。反观我们使用的 MyCAT，需要借助像 australia 这样的中间件，带来了额外的运维成本。
OceanBase 4.x 使用体验
最后分享一下关于我们目前在使用 OceanBase V4.2_CE 版本的一些体验感受。
第一，在 OceanBase 4.x 版本中，底层引入了日志流，解决了我们之前在体验 3.x 版本节点分区数有最大限制的痛点。
OceanBase 早期版本的架构体系里以分区为基本单元进行操作，当系统内的分区数量达到一定程度后，以分区为单元的操作的消耗也随之增大，因此，单节点支持的分区数量受到限制，单节点上涉及跨分区的数据修改也需要两阶段提交协议来保证事务的原子性等问题。4.x 版本引入日志流之后，我们的某一些分区域都采用同一个日志流，减少 Paxos 组的设计，使每一个 OBServer 的分区数可以极大提高。
第二，OceanBase 提供的工具极大地降低了运维复杂度。
1. 部署方式非常便捷，包括 OCP 的图形化部署、OBD 的白屏化部署等，极大地降低了部署和运维难度。
2. 在一些常用的运维场景，比如 OBServer 上下线、备份恢复等操作均可使用图形化界面管理，不需要手动操作和编写脚本，或者在平台开发对应的逻辑。而且 OCP 的功能非常完善，基本考虑到了日常运维中的方方面面。例如，我们业务上有部分信息集成需求，OCP 提供了非常丰富的 API 接口，我们能够想到的所有操作都可以通过这样的 API 接口完成，并与现有的运维体系对接。
3. OMS 的迁移平滑。最近把我们的数据库管理平台从 MySQL 迁移到了 OceanBase，整个链路从结构迁移、全量和增量数据迁移，到全量校验，再到反向增量迁移，都非常平滑，极大地降低了 DBA 在数据迁移过程中的工作量。
