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

作业帮作为国内主流在线教育品牌之一，旗下有多款教育软件产品与硬件产品，而且每个产品背后的业务都有不同的特性和诉求。在这个背景下，作业帮采用多云架构（阿里云、百度云、腾讯云），并同时使用 MySQL、Redis-Cluster、MongoDB、Elastisearch、TiDB 、OceanBase 这几款数据库。出于高可用和降本需求，作业帮决定将更多 MySQL 业务场景用 OceanBase 代替，本文将和大家分享具体原因，以及OceanBase 4.0与 MySQL5.7 的对比数据。

作者｜刘强，就职于作业帮基础架构 DBA 团队，负责分布式数据库的探索和使用，协同研发团队在公司内部推进分布式数据库在业务上的落地。

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

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

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

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

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

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

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

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

OceanBase 4.0 对比 MySQL5.7

性能对比

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

首先，从图 1 可见，在这样的硬件条件下，OceanBase 性能超过了 MySQL。

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

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

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

架构对比

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

字符集对比

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

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

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 副争抢资源。

对于成本敏感的逻辑资源隔离，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%以下。

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

以上就是作业帮对 OceanBase 4.0 的探索过程，供大家参考。