写点什么

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

刘强

  • 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:0013495
用户头像
李冬梅 加V:busulishang4668

发布了 1046 篇内容, 共 659.9 次阅读, 收获喜欢 1210 次。

关注

评论 1 条评论

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

补充延时

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

硬核!万字神文精解高并发高可用系统实战,分布式系统一致性文档

做梦都在改BUG

Java 高可用 高并发 分布式一致性

如何通过Java应用程序在PPT中创建SmartArt图形

在下毛毛雨

Java PowerPoint 添加艺术图形

升级企业数智化底座,构建数智连接全能力

用友BIP

技术大会 用友iuap 用友技术大会

NFTScan 与 Web3 Analytics 达成合作伙伴,双方在多链 NFT 数据方面展开合作

NFT Research

NFT 区块链、

最佳云转码,腾讯云MPS夺得MSU编码器大赛21项第一

科技热闻

chrome调试技巧(一)

知心宝贝

前端 后端 调试 三周年连更

Zabbix5.0配置企业微信告警

A-刘晨阳

Linux zabbix 三周年连更

站群SEO是什么意思?站群SEO怎么做效果才好?

海拥(haiyong.site)

三周年连更

简单的视频格式转换器:MacX Video Converter Pro中文版

真大的脸盆

Mac Mac 软件 视频格式转换 格式转换器

企业全面数智化转型,国产替代成为安全保障

用友BIP

技术大会 用友iuap 数智化转型 用友BIP 用友技术大会

知你懂你,聪明得简直不像一台车,问界M5智驾版重磅升级鸿蒙3

极客天地

Solr和Elasticsearch,搜索框架怎么选?

会踢球的程序源

Java

DLRover:云上自动扩缩容 DeepRec 分布式训练作业案例分享

AI Infra

程序员 AI 互联网 DLRover

FastAPI入门

Liam

程序员 开发工具 API FastApi API 开发

ChatGPT无需API开发连接第三方系统,让舆情自动监控

集简云开放平台

数据集成 数据集成平台 Chat

前端沙箱利用这些特性实现代码的隔离与限制

没有用户名丶

Python本地SQL文件对比工具

YUKI0506

Python 文件对比 对比工具 difflib

共享电动车生产厂家!共享电单车厂商

共享电单车厂家

共享电动车厂家 共享电单车厂商 智能电动车生产

阿里大神整理的Java核心知识点和面试官常问到的知识点,压压惊

会踢球的程序源

Java 面试 求职 java面试 Java构架

什么是企业数智化的创新加速器?

用友BIP

技术大会 用友iuap 用友BIP 用友技术大会

听说谛听闹退休?感知网络接班啦!

脑极体

感知网络

浪潮海岳低代码平台inBuilder开源社区版正式发布

科技热闻

用友iuap平台一站式服务,助力央国企推进数智化转型

用友BIP

这是你的云-云起实验室

六月的雨在InfoQ

开发者 实验室 三周年连更 云起实验室

国内Google翻译失效的解决方法(MAC/WIN)

互联网搬砖工作者

时隔两个多月,一起来看ChatGPT现况如何?

加入高科技仿生人

人工智能 AI 低代码 数字化

集简云开放平台是什么?

集简云开放平台

「云原生」Elasticsearch + Kibana on k8s 讲解与实战操作

会踢球的程序源

Java elasticsearch Kibana

AutoCAD2024最新版介绍及autocad 2024系统要求

互联网搬砖工作者

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