作业帮多云架构下的数据库集群解决方案,实现资源隔离、快速响应

2024年 5月 7日 88.4k 0

导语:面对业务多元、数据海量、数据库种类多样、多云架构复杂等痛点,该如何制定既能解决问题又能降本增效的数据库升级方案?作业帮作为实践者,将从四方面分享其数据库选型过程与思考。以下为作业帮DBA刘强在DTCC大会中的讲述。

企业简介:作业帮公司致力于为全国中小学生提供全学科的学习辅导服务,旗下拥有工具类产品作业帮、作业帮口算、K12直播课产品、作业帮直播课,素质教育产品小鹿编程、小鹿写字、小鹿学习力、小鹿美术等,以及喵喵机等智能学习硬件。拥有作业帮业务生态系统、内部营销中台、教研中台、教学中台、辅导运营中台等五大平台,持续赋能更多素质教育产品,不断为用户带来更好的学习和使用体验。

作业帮数据库生态痛点及选型诉求

众所周知,作业帮作为在线教育的领军品牌之一,旗下有多款教育软件产品与硬件产品,而且每个产品背后的业务都有不同的特性和诉求。在这个背景下,我们的数据库状态呈现出五个特点。

作业帮多云架构下的数据库集群解决方案,实现资源隔离、快速响应-1

1. 数据库种类多样

为了更好地承接各类业务需求,作业帮使用不同的数据库产品来支撑不同的业务。目前使用的数据库主要有 MySQL+Orch、Redis-Cluster、MongoDB、Elasticsearch、TiDB 和 OceanBase。

2. 业务需求多元

经过几年的沉淀,目前我们公司的在线教育相关软硬件业务线较多, 数据库的使用场景也越来越细分化,对数据处理的灵活性和高效性都提出了更多的要求。比如 MongoDB 的 Schema Design 特性,对第三方信息的获取、Json格式文档存储提供了非常灵活高效的存取方式,再比如Elasticsearch 在业务日志的存储分析、在大数据的快速聚合分析、基础运维指标的采集监控等场景都有明显优势。

3. 多云架构复杂

作业帮是一个多云架构,在云原生的大背景下,作业帮使用阿里云、腾讯云、百度云三云架构。业务流量主要分布在腾讯云上,其次是阿里云和百度云。

我们选择多云的主要原因是保证业务的连续性,避免因云厂商的设施故障导致在线业务的中断;另外一个比较重要的原因是可以结合每个云厂商特有的优势,更好的为业务赋能。

同时这种多云环境对数据库的高可用架构提出了更高要求。

4. 海量数据存储

相信很多 MySQL 用户都会遇到单机存储瓶颈带来的困扰,通常,解决办法要么是定期清理数据,要么分库分表,这都会给业务人员和DBA人员增加额外的工作。作业帮也不例外,解决单机存储问题是我们使用分布式数据库最基本的需求。

5. 运维管理智能

很多公司会针对不同数据库来开发自己的运维管理平台,以提升对数据库管理的敏捷性和可靠性。而完善的运维管理平台对DBA人员来说,意味着一项复杂且周期较长的工作。

总结来说,业务场景的技术需求和企业降本增效的诉求驱动我们进行数据库方案的替换和升级,我们把目标瞄准在分布式数据库领域。

  • 业务场景的技术需求:
  • 作业帮有很多业务不需要分库分表的设计模式,这样可以减少对业务代码的侵入,也可以减轻DBA 的压力。
  • 承接复杂的查询操作,有时业务会查询一些扫描量较大的数据,也会经常去执行轻量级的 OLAP 类型的 SQL,而使用 MySQL时总会出现响应不及时、跑不出数据的情况。
  • 探索多云架构下数据库集群的解决方案。
  • 对历史数据的归档。
  • 降本增效的诉求:从数据存储的角度进行压缩,或对主机的 CPU 和内存进行更高效的利用。

作业帮多云架构下的数据库集群解决方案,实现资源隔离、快速响应-2

OceanBase与TiDB的测试对比

在很早之前,我们就对OceanBase有所耳闻,但仅停留在“蚂蚁集团自研的一款优秀的国产数据库”这样的印象中。在OceanBase开源后,我们开始关注它并对它进行深入了解。

就在11月3日,OceanBase 社区版 4.0 发布,我们立即对 OceanBase 4.0做了进一步的调研和测试。结果,我们发现 OceanBase 主要有以下几个特点:

  • 弹性扩缩容:能够很好地解决作业帮最基本的单机存储瓶颈问题。
  • 数据压缩比、多租户模式:这两个特性能够帮助作业帮真正做到降本增效,尤其是OceanBase 4.0支持对CPU进行超卖分配,可以使我们更充分地利用硬件资源。
  • OLTP 性能高:我们只进行了最基本的sysbench压测,性能超出意料,在高并发情况下,SQL 的响应耗时依然维持较低的水平。

作业帮多云架构下的数据库集群解决方案,实现资源隔离、快速响应-3

  • 业务兼容性:如果想从 MySQL 切换至 OceanBase,与 MySQL 5.7.24 兼容性的对比是很重要的一点,我们测试了 OceanBase 4.0后,发现兼容性很高。
  • 管理易用性:我们使用的数据库如MySQL、Redis等, 都需要自己开发管理平台。 OceanBase 的 OCP 管理平台由于其功能完善,且使用方便,对我们DBA人员来说能解放很大一部分生产力,因此有较大的吸引力。

由于我们的部分业务使用TiDB作支撑,因此,在测试OceanBase的过程中,我们也对二者进行了横向对比,数据如下。

作业帮多云架构下的数据库集群解决方案,实现资源隔离、快速响应-4

我们在数据写入后对比发现:

  • OceanBase 在存储效率方面相较于 TiDB 节省了 35% 以上的磁盘空间
  • 在兼容性上,TiDB 与OceanBase的表现都很好,相较而言,TiDB涉及的业务改造较少,但主键操作受限,OceanBase则可能涉及将表改成分区表的成本投入。
  • 在运维管理方面,TiDB 的监控比较完善,OceanBase的优势在于其运维管理平台(OCP)易于使用,可以极大地减少 DBA的开发管理工作。
  • 关于数据同步组件,TiDB 的DM 相对来说比较完善,在我们的业务中使用较多,OceanBase的OMS 在测试中表现也比较亮眼,但对于我们的业务场景来说,还有一些功能需要进一步完善。
  • 我们也关注到TiDB 不支持多租户模式和多副本类型,而OceanBase 对多租户模式的支持可以帮助我们高效利用资源,而且,OceanBase还支持只读副本和日志副本。
  • 另外,我们也很看重DDL的响应,OceanBase 和 TiDB 在加字段方面都是秒级响应,在加索引或修改一些字段类型的情况下,可能会涉及数据的拷贝,但并不阻塞读写。

OceanBase 方案实现资源隔离与快速响应

基于以上的调研和测试结果,我们选择使用OceanBase 承接一些离线数据查询需求。

作业帮的业务人员经常需要连接 MySQL 来查询线上数据,时常会有一些慢 SQL 导致线上存库所在的主机性能抖动,影响线上业务。我们将 MySQL 通过工具同步到 OceanBase 后,将业务查询平台的入口数据源改成 OceanBase,同时对同步工具进行监控。如果发现了中断,或者有比较大的延迟,我们也会将这个查询的入口切换回 MySQL。

下图是使用OceanBase后的架构,该架构实现了资源隔离,极大地减少了对线上数据库不必要的影响。同时,在使用 MySQL 时一些耗时较长或对线上影响较大的 SQL,在 OceanBase 中都能快速响应。后续,我们会将作业帮内部对统计分析类业务逐渐迁移到 OceanBase 中。

作业帮多云架构下的数据库集群解决方案,实现资源隔离、快速响应-5

期待OceanBase 解决作业帮多云环境的四个问题

我在文章开头提到,作业帮采用的是多云环境,如下图所示,三个机房之间有机房专线,业务流量分布不均匀,主要的业务流量都在腾讯云,阿里云和百度云会分布层级节点。作业帮的业务部署流量是实现单元闭环,每个机房都部署业务,这个业务只访问本机房内部的数据库入口节点(业务访问路径是App -> Proxy->MySQL)。

作业帮多云架构下的数据库集群解决方案,实现资源隔离、快速响应-6

这个多云架构存在四个问题。

第一个问题,在专线抖动的情况下,当阿里云的业务节点需要向 master 进行写数据的时候,会出现写入失败的情况。我们的基本诉求是业务节点在阿里云内能够实现只读,这样可以尽可能地减少对业务的影响。

第二个问题是专线故障。当腾讯云和阿里云之间出现了专线故障且长时间不可恢复,此时在保证高可用不会误切主的前提下,通知业务将阿里云的业务流量调度到腾讯云, 等专线恢复后再将架构复原。

第三个问题是机房级别的故障。机房级别的故障分为主机房不可用和主机房可用两种情况,如果主机房可用,而主机房和其他两个机房都实现了网络隔离,我们会优先将业务流量切换到腾讯云,这样能保证绝大部分流量不用进行切换处理。

第四个问题是基础机房不可用,导致腾讯云整个系统故障。此时我们会进行数据库层面的切换,将主节点切换到阿里云或百度云,再将腾讯云的业务流量切换到新的集群主节点中。

基于我们的业务流量分布特点和架构情况,当前高可用架构的主要痛点在于如何保证其稳定性并在极端网络情况下不发生脑裂。同时,基于MySQL 的双活架构,实现难度也较大。

那么,OceanBase 是否能给我们带来更好的解决方案?

OceanBase 不需要额外的高可用管理组件,使用Paxos 协议能更好地保证高可用架构的稳定性,且避免了脑裂的情况。

在我们同城三机房的背景下,我们使用三zone 五副本的方式部署一套集群,能够满足绝大部分业务需求。同时,在单云化改造方面提供了较为完善的解决方案。

假如我们按照用户的某个维度进行数据分片,一个机房一个分片表,通过leader 的调度功能将leader 副本调度到本机房内,每个机房的业务单云在本机房实现流量闭环读写。

作业帮多云架构下的数据库集群解决方案,实现资源隔离、快速响应-7

除此之外,据 OceanBase 的工程师透露,OceanBase 的主备集群的的功能将会在 OceanBase 开源4.1 版本中发布,这让我们非常期待。因为该架构的主要优势在于可以进行异地机房的数据容灾,且备集群只需要单个副本,架构易于管理且成本低。

作业帮多云架构下的数据库集群解决方案,实现资源隔离、快速响应-8

写在最后

基于 OceanBase 的种种优势,比如高效的资源利用、灵活地副本调度、稳定地高可用架构等,我们将陆续在公司内部进行推广,并连同业务尝试单元化方案的改造和落地。

另外,OceanBase 商业版的一些优秀特性如透明加密,我们也会持续关注并在适当的时机推进商业化服务的合作。

嘉宾介绍:刘强,多年数据库运维经验,要负责MySQL、Redis、TiDB和OceanBase 等不同数据库的使用与探索,数据库管理平台的开发工作。 重点工作方向是分布式数据库在公司内部的推广和使用;配合业务部门进行需求测试以及方案落地。

欢迎持续关注 OceanBase 技术社区,我们将不断输出技术干货内容,与千万技术人共同成长!!!

搜索🔍钉钉群(33254054),或扫描下方二维码,还可进入 OceanBase 技术答疑群,有任何技术问题在里面都能找到答案哦~

作业帮多云架构下的数据库集群解决方案,实现资源隔离、快速响应-9

相关文章

Oracle如何使用授予和撤销权限的语法和示例
Awesome Project: 探索 MatrixOrigin 云原生分布式数据库
下载丨66页PDF,云和恩墨技术通讯(2024年7月刊)
社区版oceanbase安装
Oracle 导出CSV工具-sqluldr2
ETL数据集成丨快速将MySQL数据迁移至Doris数据库

发布评论