disruptor在数据同步场景下的应用实战

本文涉及的产品
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
简介: disruptor在数据同步场景下的应用实战

1、场景描述


了解过mysql主从同步机制的童鞋们应该都知道是基于binlog实现,mysql增量同步的核心设计理念:将同步线程“伪装”为需要同步的mysql节点的从节点(slave),主动向mysql主节点发送dump请求即可获得主节点的binlog推送。


业界一个比较知名的 mysql bing log 解析类库为Canal,结合笔者公司实际情况,决定只使用底层的binlog解析工具,其他数据同步功能自研,本文将重点关注binlog拉取与解析

986aa46911d7e617fac893eabb817682.png

接下来将尝试优化上面的性能,逐步引出disruptor。


2、技术方案与优化


一个线程负责拉取binglog消息,然后对拉取的消息进行解析,解析出数据库相关字段后写入目标端,拉取、解析这两个操作本身就是一个比较重(慢)的操作,如果将其进行分解,一旦拉取线程拉取到数据后,解析线程在解析的过程中,拉取动作可以继续拉取,两者并发执行,可以提高执行效率,其设计理念如下:

78a62d6e8d60d55968bc24f6ac191a50.png

能想到的第一个优化方案肯定是引入多线程,一个进程通常只会开启一个线程与MySQL服务端拉取binlog,该线程拉取到数据后,放入到一个有界队列中,然后启动一个多线程去将拉取到的信息进行并发解析,解析完后再发送给目标端。


思路是对的,但这里有一个非常关键点:基于binlog解析进行的数据同步,必须考虑事件的顺序性。


例如在源端,对一条数据id=5的记录,出现一个INSERT、UPDATE、DELETE,如果在发给目标端先将INSERT事件发给目标端,然后再将DELETE、UPDATE事件依次发送到目标端,造成的结果就是数据的不一致

9384c9b4872180ce06a5af585999dec2.png

为了保证发送到目标端端顺序性,在原来的基础上引入了一个转发线程,再结合批处理的思路来实现日志解析的并发性,但不打破顺序性语义,实现关键点如下:


  • 引入一个线程,一次从阻塞队列中获取多条数据,该数量可以配置,然后将该批消息转发到解析线程,但转发的时候,会将这条消息所在的批的序号告知解析线程。
  • 解析线程在处理完一条任务的解析工作后,反馈给转发线程,得这个批次中所有的消息都解析完成后,然后将该批次的所有消息,按照顺序传送到目标端


此过程,该批次的解析任务是并行的,但每一批次的消息是串行,性能得到优化的前提下,兼顾来顺序语义,是不是很完美?


至少当时的我是觉得这个优化方案还是不错的,邀请团队成员进行方案评审(设计方案是架构师出没错,但不要刚愎自用,多发挥团队的智慧),当我讲完方案设计后,其中一个小伙伴说,我非常赞同这个方案,并且业界已经有了成熟的方案,那就是disruptor,内部已经提供了封装,并且内部没有使用锁,在会上我当即表示,既然已有开源类库,那我们优先采用类库,会后麻烦你提供一下示例代码。


组员也非常给力,会后“三下五除二”就提供了示例代码,截图如下:

688a3a8e80f21fb7a7de6c4670524f82.png

核心关键点:


  • 创建RingBuffer,环形缓存区,并且注意使用的是createSingleProducer方法,创建一个单一生产者,表示这个环形队列只会有一个生产者往里丢数据,这种模式可以提供多个消费者无锁访问RingBuffer;与此对应还提供了createMultiProducer,支持多生产者单消费者的无锁化访问。
  • 使用WorkPool,线程池并发解析,多个消费者访问同一个环形队列。
  • 引入SequenceBarrier,将并发解析后的结果按序抽取到一个新的队列中,即目标端。


为了方便理解上disruptor的使用,我们将上述代码与技术方案进行一个对标


  • 阻塞队列 技术方案图中的阻塞队列换成了disruptor的环形队列RingBuffer,PULL线程将拉取到的消息丢入队列中
  • 解析线程 解析线程对标WorkPool,WorkPool中会创建多个WorkProcessor,多个线程不加锁的访问环形队列,并发解析。
  • 顺序性输出到目标端
    在disruptor中引入了SequenceBarrier,保证顺序依赖性保证。


从实战场景来看disruptor的经典使用场景多线程基于队列协作进行,实现百万级的性能保证。其核心要点无锁化

相关实践学习
如何在云端创建MySQL数据库
开始实验后,系统会自动创建一台自建MySQL的 源数据库 ECS 实例和一台 目标数据库 RDS。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
相关文章
|
消息中间件 大数据 Kafka
多云与混合云场景下的数据同步方案-KAFKA
多云与混合云场景下的数据同步方案-KAFKA
|
canal 消息中间件 关系型数据库
系统重构数据同步利器之Canal实战篇
系统重构数据同步利器之Canal实战篇
638 1
|
canal 监控 负载均衡
秃头也要学习的微服务进阶场景实战:基于Bifrost的数据同步方案
技术选型 项目组决定找一个开源中间件,它需要满足以下5点要求。 1)支持实时同步。 2)支持增量同步。 3)不用写业务逻辑。 4)支持MySQL之间的同步。 5)活跃度高。
|
2月前
|
canal 消息中间件 关系型数据库
Canal作为一款高效、可靠的数据同步工具,凭借其基于MySQL binlog的增量同步机制,在数据同步领域展现了强大的应用价值
【9月更文挑战第1天】Canal作为一款高效、可靠的数据同步工具,凭借其基于MySQL binlog的增量同步机制,在数据同步领域展现了强大的应用价值
621 4
|
3月前
|
存储 关系型数据库 MySQL
【TiDB原理与实战详解】5、BR 物理备份恢复与Binlog 数据同步~学不会? 不存在的!
BR(Backup & Restore)是 TiDB 分布式备份恢复的命令行工具,适用于大数据量场景,支持常规备份恢复及大规模数据迁移。BR 通过向各 TiKV 节点下发命令执行备份或恢复操作,生成 SST 文件存储数据信息与 `backupmeta` 文件存储元信息。推荐部署配置包括在 PD 节点部署 BR 工具,使用万兆网卡等。本文介绍 BR 的工作原理、部署配置、使用限制及多种备份恢复方式,如全量备份、单库/单表备份、过滤备份及增量备份等。
|
3月前
|
关系型数据库 MySQL 调度
【TiDB原理与实战详解】4、DM 迁移和TiCDC数据同步~学不会? 不存在的!
TiDB Data Migration (DM) 和 TiCDC 是两款用于数据库迁移和同步的强大工具。DM 支持将兼容 MySQL 协议的数据库(如 MySQL、MariaDB)的数据异步迁移到 TiDB 中,具备全量和增量数据传输能力,并能合并分库分表的数据。TiCDC 则专注于 TiDB 的增量同步,利用 TiKV 日志实现高可用性和水平扩展,支持多种下游系统和输出格式。两者均可通过 TiUP 工具进行部署与管理,简化了集群的安装、配置及任务管理过程。
|
3月前
|
canal 关系型数据库 MySQL
"揭秘阿里数据同步黑科技Canal:从原理到实战,手把手教你玩转MySQL数据秒级同步,让你的数据处理能力瞬间飙升,成为技术界的新晋网红!"
【8月更文挑战第18天】Canal是一款由阿里巴巴开源的高性能数据同步系统,它通过解析MySQL的增量日志(Binlog),提供低延迟、可靠的数据订阅和消费功能。Canal模拟MySQL Slave与Master间的交互协议来接收并解析Binary Log,支持数据的增量同步。配置简单直观,包括Server和Instance两层配置。在实战中,Canal可用于数据库镜像、实时备份等多种场景,通过集成Canal Client可实现数据的消费和处理,如更新缓存或写入消息队列。
742 0
深入浅出阿里数据同步神器:Canal原理+配置+实战全网最全解析!
canal 翻译为管道,主要用途是基于 MySQL 数据库的增量日志 Binlog 解析,提供增量数据订阅和消费。 早期阿里巴巴因为杭州和美国双机房部署,存在跨机房同步的业务需求,实现方式主要是基于业务 trigger 获取增量变更。从 2010 年开始,业务逐步尝试数据库日志解析获取增量变更进行同步,由此衍生出了大量的数据库增量订阅和消费业务。
|
存储 监控 Cloud Native
《阿里云认证的解析与实战-数据仓库ACP认证》——云原生数据仓库AnalyticDB PostgreSQL版解析与实践(下)——一、数据同步
《阿里云认证的解析与实战-数据仓库ACP认证》——云原生数据仓库AnalyticDB PostgreSQL版解析与实践(下)——一、数据同步
|
分布式计算 DataWorks Cloud Native
带你读《全链路数据治理-全域数据集成》之1:1. 数据集成简介
带你读《全链路数据治理-全域数据集成》之1:1. 数据集成简介
466 0

热门文章

最新文章