MySql教程

从 20 多套 MySQL 到 1 套 TiDB丨骏伯网络综合运营管理平台应用实践

本文主要是介绍从 20 多套 MySQL 到 1 套 TiDB丨骏伯网络综合运营管理平台应用实践,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

导读

骏伯网络是一家聚焦移动互联网营销服务的公司,综合运营管理平台是其核心业务系统,包括营销系统、订单、支付以及与外部系统的交互服务接口。为满足多元化的业务发展需求,降低系统间交互链路的复杂性,提升业务连续性,以及实现降本增效的整体规划,骏伯网络选择将 TiDB 作为综合运营管理平台的底层数据库。经过上线实践证明,TiDB 为骏伯在业务连续性、性能提升、数据资源整合、降本增效等方面带来了显著价值。未来,骏伯将扩展 TiDB 在数据分析类业务场景中的应用,提升数据实时分析能力,加快业务创新的步伐 。

本文作者:骏伯网络 唐帆,PingCAP 贺美存

骏伯网络简介

广州骏伯网络是一家以数据驱动的科技公司,聚焦移动互联网营销服务,坚持以客户为中心,深耕 APP、运营商、金融保险等行业,以解决客户营销痛点为目标,为客户提供全链路营销服务。骏伯网络于 2015 年挂牌新三板,连续 5 年入选广州未来独角兽企业,已累计为超过 1000 家企业、超过 1600 款产品提供推广服务,长期与头部 APP、三大运营商以及知名金融产品进行合作,具备丰富的客户资源 。

业务痛点与数据库技术选型

1 业务简介、现状和痛点

综合运营管理平台是骏伯最核心的业务系统,主要覆盖营销、渠道、媒介、创意等业务部门,底层数据库包含 OLTP、OLAP 两种,业务系统主要包含营销、订单和信息展现三部分。订单数据均会回流到订单服务模块,订单成功后会推送到下单流程,同时可以在平台中及时查看订单信息。

https://img1.sycdn.imooc.com/65d0d1890001487d10800571.jpg

综合运营管理平台应用架构图

整套应用由 40 多个微服务组成,底层数据库采用 20 多套 MySQL 主备高可用架构,部署在 4 台物理服务器上,主备交叉部署的模式。大数据分析平台采用 Hadoop 生态,数据分析模式为 T+1 的离线模式。

综合运营管理平台是一套面向互联网用户的实时交易系统,对可靠性和性能要求较高。物理服务器的硬件故障会对生产运维和业务连续性造成较大的挑战和影响,各套数据库相对相互独立,需要实现跨库的数据实时共享。

2 技术选型要求

为了配合系统改造,解决业务连续性、数据扩展能力、资源利用率和性能等生产环境面对的痛点,骏伯启动了对国内多家头部原生分布式数据库的测试选型,具体的要求包括:

业务连续性

任何硬件单点故障对数据库集群无影响,在无人工干预的情况下,业务能够持续对外提供正常服务。数据库应具备原生分布式高可用能力,可根据业务重要性灵活设定数据副本数,具备异地灾备能力,可满足机房级高可用要求。

数据扩展能力

满足企业快速的业务变化需求,支持横向扩展能力,对业务无入侵性。数据库采用松耦合的存算分离架构,按需灵活扩展计算或存储能力,数据可自动重平衡,通过节点扩展实现性能的线性增长。

应用透明迁移能力

数据库可兼容和延续现有的应用架构和代码,提供数据在线的透明迁移能力,降低应用改造和迁移难度。

数据实时压缩能力

数据库应具备库内实时在线的压缩能力,在性能不受影响的前提下,节省数据存储的成本。

数据可恢复性

数据库需提供物理和逻辑备份,支持可选对象粒度的全量和增量备份,可将集群恢复到任何时间点。在数据误操作的情况下,提供闪回能力。

经过多轮对比测试和业务场景的验证,TiDB 满足了本次技术选型的所有指标。骏伯网络选择将 TiDB 作为综合运营管理平台的底层数据库。

TiDB 在骏伯网络综合运营管理平台的应用

从整体数据规模、业务访问请求、资源高可用等维度考虑,我们制定了详细的部署方案。结合现有应用和数据库情况,我们设计了分批业务迁移计划,历时 3 个月成功完成了所有应用的平滑迁移和部署。在主中心部署一套包含 4 台物理服务器的 TiDB 集群,用于支撑综合运营管理平台。主中心集群通过 BR 完成数据库备份任务。MySQL 数据的迁移工作由 DM 组件完成,以确保数据迁移的顺利进行。未来,我们计划在异地构建一套单副本的集群,通过 TiCDC 组件搭建数据容灾的演练环境,从而实现异地灾备。

https://img1.sycdn.imooc.com/65d0d18a0001b82710800772.jpg

系统架构图

目前所有应用模块已成功迁移到 TiDB 集群上,第一批迁移的业务已经稳定运行超过半年。系统在业务高峰期经历了验证,并成功应对了单服务器硬件异常故障对业务连续性保障的实际考验,完全实现了项目最初规划的目标 。 业务峰值流量 QPS 大于 10K,活跃连接数 400 左右,且平均响应延时低于 200ms

应用价值

结合系统的实际运行效果,总结 TiDB 为骏伯网络带来的收益如下:

保障业务连续性

TiDB 原生多副本能力避免了任何单点硬件故障,为业务提供无感知的保障能力。通过跨数据中心集群灾备能力保障机房级的故障影响,充分保障业务的连续性。

降低资源和运维投入

TiDB 内置的数据实时压缩能力,保障数据三副本的高可用。集群整体资源较原有 MySQL 主备集群实现了 20% 的成本降低。过去需要运维 20 多套 MySQL,现在只需要运维一套 TiDB 集群,整体运维投入大幅下降。

数据的实时汇聚和查询能力提升

通过 TiDB 原生分布式和透明扩展能力,将原有 20 多套 MySQL 主备库归集到一套 TiDB 集群内,实现多业务系统的数据实时汇聚、实时查询和数据实时变现能力。

应用迁移透明,业务无侵入

通过 DM 工具实现从 MySQL 到 TiDB 的平滑迁移。TiDB 对 MySQL 的兼容能力和业务无入侵性,对应用迁移改造成本极低,在保障性能的基础上实现了应用的无缝迁移。目前,已成功完成 20 多套库的应用透明迁移。

未来展望

骏伯网络致力于成为一家以数据服务为目标的企业,将数据服务视为核心竞争力。近年来,业务对数据服务能力提出了更高的要求:从 T+1 的离线数据分析转变为 T+0 的实时分析效果。然而,企业现有的 Hadoop 生态框架已无法满足新业务的数据分析需求,主要表现在技术栈复杂、开发运维成本高、数据实时服务能力弱等方面。

在 2024 年的计划中,我们旨在构建一套以 TiDB 为底座的数据实时分析平台,以实现对数据的实时加工和统一服务能力。通过结合现有的 Hadoop 框架,我们将打造一套流批一体化的数据湖平台,从而加速企业数字化能力的提升。这一举措旨在有效解决技术栈复杂性、降低开发运维成本,并增强数据的实时服务能力,以更好地满足业务发展对数据实时分析和实时变现的要求。


这篇关于从 20 多套 MySQL 到 1 套 TiDB丨骏伯网络综合运营管理平台应用实践的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!