大厂Data+Agent 秘籍:腾讯/阿里/字节解析如何提升数据分析智能。 了解详情
写点什么

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

刘强

  • 2024-09-05
    北京
  • 本文字数:3349 字

    阅读完需:约 11 分钟

大小:1.63M时长:09:30
作业帮在多云环境下的高可用双活架构优化实践

作者|刘强,就职于作业帮基础架构 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 临时表统一过滤掉。

2024-09-05 09:0013668
用户头像
李冬梅 加V:busulishang4668

发布了 1121 篇内容, 共 739.8 次阅读, 收获喜欢 1268 次。

关注

评论 1 条评论

发布
用户头像
是主从延时?

补充延时

2024-11-13 10:14 · 浙江
回复
没有更多了
发现更多内容

颠覆传统的自动化测试平台

虫师

自动化 测试 框架 测试平台

ByConity ELT 测试体验

穿过生命散发芬芳

ByConity

Redis【1】- 如何阅读Redis源码

秦怀杂货店

redis 源码

为什么需求管理对于软件开发过程至关重要

易成研发中心

需求管理

用全彩LED显示屏打造抢眼的空间设计!

Dylan

技术 艺术 科技 LED display LED显示屏

2025江苏省正规等保测评机构名单大汇总

行云管家

等保 等保测评 江苏

如何管理一个散漫的团队

易成研发中心

团队管理

韦恩图如何在线制作?10个韦恩图模板案例推荐!

职场工具箱

在线白板 绘图软件 效率软件 信息可视化 韦恩图

《Django 5 By Example》阅读笔记:p339-p358

codists

Python django

鸿蒙NEXT元服务:收藏、卡片、用户协议、隐私声明、分享链接、评分与评论

zhongcx

鸿蒙元服务

命令行应用开发入门指南:从脚手架搭建到UI库与交互增强

代码忍者

PIRF-416:How To-A way Sound Interesting

Echo!!!

English

数智绩效:数智预算精准配置资源

用友智能财务

财务 企业数智化 企业数智化转型

一文让你简单了解航空运输业定义以及特点

行云管家

网络安全 堡垒机 航空运输

AIGC产品经理训练营第一期 -- 毕业总结

AnMin

聚焦银行业数智化转型,火山引擎数据飞轮系列白皮书重磅发布

字节跳动数据平台

GreptimeDB 监控自举 | 如何用 GreptimeDB 监控 GreptimeDB

Greptime 格睿科技

数据库 数据 数据监控

作业帮在多云环境下的高可用双活架构优化实践_数据湖仓_InfoQ精选文章