分享：作业帮在多云环境下的高可用双活架构优化实践

欢迎访问 OceanBase 官网获取更多信息：https://www.oceanbase.com/

本文来自 OceanBase 社区分享，仅限交流探讨。作者介绍：刘强，就职于作业帮基础架构 DBA 团队，负责分布式数据库的探索和使用，协同研发团队在公司内部推进分布式数据库在业务上的落地。

在作业帮刚上线OceanBase 4.0 时，我分享过作业帮的业务架构痛点。目前，作业帮是多云架构（阿里云、百度云、腾讯云），并同时使用 MySQL、Redis-Cluster、MongoDB、Elastisearch、TiDB 、OceanBase 这几款数据库。出于高可用和降本需求，我们决定将更多 MySQL 业务场景用 OceanBase 代替，本文将和大家分享具体原因，以及 OceanBase 4.0 与 MySQL5.7 的对比数据。

高可用双活架构方案升级需求

由于作业帮业务的多样性和复杂性，我们对于分布式数据库的使用需求主要基于以下几个方面。

第一，在海量数据的情况下希望减少分库分表的复杂度，并解决单机存储瓶颈。

第二，对 I/O 密集型的 SQL 及 CPU 密集型的 SQL 来说，我们希望能够提高响应速度，减少它在 MySQL 中对线上业务的影响。

第三，每个业务内部都需要业务人员频繁查询、录取线上数据，并有相应的报表服务以供上级 Leader 查看，而且大数据部门也会有报表需求接入线上数据，这对于线上 MySQL 来说难以支撑，在数据归档及汇总的情况下，也缺乏良好方案。

第四，由于 MySQL 的特性限制，我们需要基于一个外部的高可用组件来实现 MySQL 的高可用架构，在多云环境下，网络环境相对复杂，这对高可用的稳定性提出了更高要求。如果部分业务的请求链路长或复杂，跨云访问会使业务相应耗时增加，影响用户体验。

因此，我们需要探索良好的双活架构方案，初步方案是基于 MySQL ，并引入 DTS 来实现双活架构。这种架构的复杂性及引入过程中 DTS 的异常或中断，对于数据的一致性有很大的挑战。同时在使用公有云的情况下，也希望能够最大程度降低硬件的使用成本。

出于高可用和降本需求，我们决定将更多 MySQL 的业务场景替换为 OceanBase，并对 OceanBase 和 MySQL5.7 进行了多方面的对比。

OceanBase 4.0 对比 MySQL5.7

1、性能对比

我们使用 32C64GB 的硬件规格分别对 OceanBase 和 MySQL 进行性能、CPU 使用率、磁盘空间占用的测试。

首先，从图 1 可见，OceanBase 性能明显超过 MySQL。

图 1 OceanBase 和 MySQL 的性能对比

其次，从图 2 得知，在相同的并发环境下，OceanBase 的 CPU 使用率比 MySQL 低至少一倍以上。

图 2 OceanBase 和 MySQL 的 CPU 使用率对比

另外，由于 OceanBase 数据压缩及编码的技术相较于 MySQL，能够节约 2/3 以上的磁盘空间，因此，综合上述三方面的对比结果，我们认为 OceanBase 能为作业帮的降本增效提供极大帮助。

在性能方面，我们还测试了 DDL 的执行速度。对于耗时较长的 DDL，MySQL 会有补充延时问题，需要我们引用额外的审核工具来控制它的延迟，而 OceanBase 不存在延时问题。对于执行速度，MySQL 和 OceanBase 相差不大，这让我们更加期待 OceanBase 4.1 的数据旁路导入功能，可以将 DDL 的执行速度大幅提升。不过，我们也发现了一些语法兼容性的问题，例如，OceanBase 对主键的操作语法不支持多个 DDL 合并执行，只能各自单独执行。

2、架构对比

除了降本增效的需求，高可用也是我们在探索双活架构中最看重的一方面。相较于 MySQL ，OceanBase 的高可用是有延伸的，不需要额外的高可用组件，这有利于解决数据不一致的问题。再加上 OceanBase 的日志具备多副本特性，能够支持在多机房或多城市灵活部署。OceanBase 还便于作业帮实现一些单元化的需求，我们可以将业务单元内的 Leader 数据调度在某一个机房内，实现业务访问的流量闭环，减少跨域读写。

3、字符集对比

最后，我们测试了字符集的支持程度。作业帮成立十年，我们使用 MySQL 的场景和字符集种类都比较多。OceanBase 4.0 当前支持图 3 中显示的几种字符集，在 4.1 版本中增加了对拉丁字符的支持。后续我们也希望 OceanBase 能够扩展字符集及校验集的支持种类。

图 3 OceanBase 4.0 支持的字符集

以上就是作业帮对 OceanBase 和 MySQL 的主要对比数据。在将更多业务场景切换至 OceanBase 的过程中，我们发现，在高可用双活架构方案之外， OceanBase 4.0 的 HTAP 和资源隔离能力也为我们带来许多意外之喜。

低成本与低延时，更好地降本增效

OceanBase 是一个具备 HTAP 能力的原生分布式数据库，如何理解 HTAP？引用 OceanBase CTO 的一句话：HTAP 就是在高性能 OLTP 数据库的基础上扩展 OLAP 的能力，能很好支持实时分析。

在作业帮的业务场景中，我们 感受到 HTAP 的两大显著优势：低成本和低延时。

• 低成本 ：我们希望一套系统能同时支持 OLTP 场景和 OLAP 场景，相比两套系统拥有更高的性价比。

• 低延时 ：省去了繁琐费时的 ETL 过程，降低延时，更好支持实时分析。

我们知道，在一套系统同时实现 OLTP 和 OLAP 的能力，其中一项挑战是资源隔离，使业务之间互不影响。这便是 OceanBase 带给我们惊喜的地方。

对于核心业务来说，我们希望能够使用物理资源管理，比如行存副本服务 OLTP，列存副本服务 OLAP，这两种业务是不共享物理资源的，可以 做到绝对的隔离 。 OceanBase 可以增加额外的只读副本，再通过配置 OBProxy 的 proxy_idc_name 实现读写分离。

图 4 为 OceanBase 的物理资源隔离方案，基于只读副本，再增加逻辑机房的情况下，在 OBProxy 中配置逻辑机房的位置。所有 OLAP 的 只读流量都会录入只读副本中，避免与 OLTP 副争抢资源。

图 4 OceanBase 的物理资源隔离方案

对于成本敏感的逻辑资源隔离，OceanBase 在同一租户内就可能实现 OLAP 和 OLTP 的物理资源共享，进而实现资源隔离。

对于逻辑隔离来说，首先 OceanBase 定义了一个大查询，默认将执行时间超过 5 秒的请求判定为大查询，当大查询和短查询同时争抢 CPU 时，大查询会被降低优先级，待 CPU 资源充足时再被挂起，我们可以设置 Large_query_worker_percentage 在同一租户内，大查询最多可以占用 30%的用户线程数。在这种情况下，我们可以有效隔离大查询对 OLTP 业务的影响，优先保证了 OLTP 业务的执行。

我们使用了一些线上业务数据和 SQL 来对比 MySQL 和 OceanBase。在作业帮的业务场景中，一个大业务部门的报表需要多级 Leader 甚至上百人频繁查看，因此，即使是 OLAP 类型的业务，QPS 也可以达到几十甚至上百。我们使用了 60 个并发去压测较复杂的 SQL，通过图 5 可以看出，OceanBase 比 MySQL 最起码快了一倍以上。OceanBase 的 CPU 使用率也基本控制在 25%以下。

图 5 OceanBase 与 MySQL 执行 SQL 耗时

在 60 个并发执行 OLAP 业务的同时，我们也用 256 个并发去运行 Sysbench 任务，在 OLAP SQL 扫描量较大的情况下，我们可以看到它的耗时出现了一些抖动（见图 6）。

图 6 并发量 256 运行 Sysbench 任务

以上就是作业帮对 OceanBase 4.0 的探索过程，目前，我们已经使用 OceanBase 半年了，总结出一些心得及建议，供大家参考。

使用 OceanBase 的心得和建议

首先，对于 OceanBase OCP 管理平台有如下几点建议。

• 建议增加 DDL 任务列表显示，需要在每一个租户下，可以看到有多少任务正在执行。

• 建议增加 SQL 审核的功能，如果有业务正在从 MySQL 迁移，可以尽快保证业务上线，减少 DBA 工作，聚焦于对业务的落地。

• 在使用过程中我们发现，每个租户下磁盘的使用量、数据库的大小及表的大小，这一部分数据的监控是缺失的，需要完善。

• 在集群中测试时，需要实时监控性能数据，比如 QPS 响应时间、CPU 的使用率等，建议在现有能力上再缩短延迟。

其次，对 OceanBase 集群的一些问题，我们也给出反馈，希望得以提升。

• DDL 无法实时查看任务的进度百分比，希望后续可以增加该功能。

• 现在集群升级时需要确保每个租户的 leader 都聚集在单个 Zone 下，这样对于每个集群有上百个租户来说，操作会比较繁琐，希望可以优化。

• 对于大家在使用过程中需要注意大小写敏感的参数设置，一旦创建后业务上线不合理则无法通过 SQL 语句进行修改，希望优化。

• 建议注意 redo log 磁盘跟内存大小的配比，防止出现当磁盘空间还有富裕的时候，创建 redo log ，显示磁盘空间不够的问题。

最后，还有一些关于 OMS 数据迁移平台的小建议：目前存在的问题有三个，一是在数据迁移过程中不支持新增 DB 的同步，对于数据归档或汇总的需求不友好；二是 OpenAPI 开放的太少，不利于我们内部平台的改造；三是 ghc 的临时表忽略写法过于繁琐，需要每一个 DB 都写一个配。由于 OMS 数据迁移是测试中常用的功能，我们希望后续能有统一的配置，可以将 ghc 临时表统一过滤掉。

欢迎访问 OceanBase 官网获取更多信息：https://www.oceanbase.com/