Canal——原理架构及应用场景

Canal简介

Canal是阿里开源的一款基于Mysql数据库binlog的增量订阅和消费组件,通过它可以订阅数据库的binlog日志,然后进行一些数据消费,如数据镜像、数据异构、数据索引、缓存更新等。相对于消息队列,通过这种机制可以实现数据的有序化和一致性。

github地址:https://github.com/alibaba/canal

完整wiki地址:https://github.com/alibaba/canal/wiki

Canal工作原理

原理相对比较简单:

  1. canal模拟mysql slave与mysql master的交互协议,伪装自己是一个mysql slave,向mysql master发送dump协议
  2. mysql master收到mysql slave(canal)发送的dump请求,开始推送binlog增量日志给slave(也就是canal)
  3. mysql slave(canal伪装的)收到binlog增量日志后,就可以对这部分日志进行解析,获取主库的结构及数据变更

Mysql主从同步原理

canal工作原理其实也是基于mysql主从同步原理的,所以理解mysql主从同步原理是第一步

  1. master将改变记录到二进制日志(binary log)中
  2. slave(I/O thread)将master的记录改变的binlog日志拷贝到它的中继日志(relay log)中
  3. slave(SQL thread)重做中继日志中的事件,将改变反映它自己的数据从库中

Canal架构

说明:
server代表一个canal运行实例,对应于一个jvm
instance对应于一个数据队列

instance模块:
eventParser (数据源接入,模拟slave协议和master进行交互,协议解析)
eventSink (Parser和Store链接器,进行数据过滤,加工,分发的工作)
eventStore (数据存储)
metaManager (增量订阅&消费信息管理器)

Canal应用场景

  1、同步缓存redis/全文搜索ES

  canal一个常见应用场景是同步缓存/全文搜索,当数据库变更后通过binlog进行缓存/ES的增量更新。当缓存/ES更新出现问题时,应该回退binlog到过去某个位置进行重新同步,并提供全量刷新缓存/ES的方法,如下图所示。

  2、下发任务

  另一种常见应用场景是下发任务,当数据变更时需要通知其他依赖系统。其原理是任务系统监听数据库变更,然后将变更的数据写入MQ/kafka进行任务下发,比如商品数据变更后需要通知商品详情页、列表页、搜索页等先关系统。这种方式可以保证数据下发的精确性,通过MQ发送消息通知变更缓存是无法做到这一点的,而且业务系统中不会散落着各种下发MQ的代码,从而实现了下发归集,如下图所示。

  3、数据异构

  在大型网站架构中,DB都会采用分库分表来解决容量和性能问题,但分库分表之后带来的新问题。比如不同维度的查询或者聚合查询,此时就会非常棘手。一般我们会通过数据异构机制来解决此问题。

所谓的数据异构,那就是将需要join查询的多表按照某一个维度又聚合在一个DB中。让你去查询。canal就是实现数据异构的手段之一。

参考:

https://www.cnblogs.com/huangxincheng/p/7456397.html

原文地址:https://www.cnblogs.com/caoweixiong/p/11824423.html

时间: 2024-08-29 13:24:06

Canal——原理架构及应用场景的相关文章

【Netty】最透彻的Netty原理架构解析

这可能是目前最透彻的Netty原理架构解析 本文基于 Netty 4.1 展开介绍相关理论模型,使用场景,基本组件.整体架构,知其然且知其所以然,希望给大家在实际开发实践.学习开源项目方面提供参考. Netty 是一个异步事件驱动的网络应用程序框架,用于快速开发可维护的高性能协议服务器和客户端. JDK 原生 NIO 程序的问题 JDK 原生也有一套网络应用程序 API,但是存在一系列问题,主要如下: NIO 的类库和 API 繁杂,使用麻烦.你需要熟练掌握 Selector.ServerSoc

(转)OpenStack —— 原理架构介绍(一、二)

原文:http://blog.51cto.com/wzlinux/1961337 http://blog.51cto.com/wzlinux/category18.html-------------OpenStack -- 原理架构介绍(一~九) 一.OpenStack 简介 Openstack是一个控制着大量计算能力.存储.乃至于整个数据中心网络资源的云操作系统,通过Dashboard这个Web界面,让管理员可以控制.赋予他们的用户去提供资源的权限(即:能够通过Dashboard控制整个Ope

HTTPS 原理剖析与项目场景

最近手头有两个项目,XX导航和XX产业平台,都需要使用HTTPS协议,因此,这次对HTTPS协议做一次整理与分享. 为什么使用HTTPS HTTP 协议,本身是明文传输的,没有经过任何安全处理.那么这个时候就很容易在传输过程中被中间者窃听.篡改.冒充等风险.这里提到的中间者主要指一些网络节点,是用户数据在浏览器和服务器中间传输必须要经过的节点,比如 WIFI 热点,路由器,防火墙,反向代理,缓存服务器等. HTTP 协议,中间者可以窃听隐私,使用户的敏感数据暴露无遗:篡改网页,例如往页面插的广告

python 装饰器语法糖(@classmethod @staticmethod @property @name.)原理剖析和运用场景

引用:http://blog.csdn.net/slvher/article/details/42497781 这篇文章系统的介绍这几者之间的关系和区别.有兴趣的朋友可以到上面的链接查看原文,这里我把原文拷贝如下(如有侵权,通知马上删除) ==================================================================== 在阅读一些开源Python库的源码时,经常会看到在某个类的成员函数前,有类似于@staticmethod或@classme

Durid(一): 原理架构

Durid是在2013年底开源出来的,当前最新版本0.9.2, 主要解决的是对实时数据以及较近时间的历史数据的多维查询提供高并发(多用户),低延时,高可靠性的问题.对比Druid与其他解决方案,Kylin对数据按照分区每天构建前一天的cube数据提供给用户查询,用户查询的是历史数据.而Druid不断的从ingest去拉取数据,持续构建cube,提供实时查询,主要作者下面两位, 其中一位创建了一家公司继续发展druid (Impty.io)           目录: Druid特性 使用场景 D

局部性原理的点滴应用场景 use of localityprinciple

话说九月份博士入学面试的时候被问到了一个问题:请说明一下局部性原理在计算机科学中的应用场景?(哈哈,不记得怎么问的了,大概是这个意思)但是巴拉巴拉整半天却也只说出了一个Cache,后来补充的也都是跟Cache相关的,就是没能跳出Cache,哎~~于是就想写这个博客了,但是苦于涉及的面实在太广,于是乎,遇到一个写一个吧. 首先,Cache肯定算一个,设计Cache也是为了性能考虑,主要是为了解决内存和磁盘之间的速度差问题,而将近期访问的一部分数据保存在内存中以便下次直接可以提取,从而加速.围绕Ca

K8s 原理架构介绍(一)

一.Kubernetes 是什么 Kubernetes最初源于谷歌内部的Borg,提供了面向应用的容器集群部署和管理系统.Kubernetes 的目标旨在消除编排物理/虚拟计算,网络和存储基础设施的负担,并使应用程序运营商和开发人员完全将重点放在以容器为中心的原语上进行自助运营.Kubernetes 也提供稳定.兼容的基础(平台),用于构建定制化的workflows 和更高级的自动化任务. Kubernetes 具备完善的集群管理能力,包括多层次的安全防护和准入机制.多租户应用支撑能力.透明的服

nginx之旅(第四篇):nginx限速原理、nginx限速场景、nginx限速实现

一.nginx限速 在生产环境中,为了保护WEB服务器的安全,我们都会对用户的访问做出一些限制,保证服务器的安全及资源的合理分配. 限流(rate limiting)是NGINX众多特性中最有用的,也是经常容易被误解和错误配置的,特性之一访问请求限速.该特性可以限制某个用户在一个给定时间段内能够产生的HTTP请求数.请求可以简单到就是一个对于主页的GET请求或者一个登陆表格的POST请求.用于安全目的上,比如减慢暴力密码破解攻击.通过限制进来的请求速率,并且(结合日志)标记出目标URLs来帮助防

lvs之 lvs原理架构介绍

一. 概念 lvs的术语: Router:GWIP vs:virtual server,director rs:real server CIP:client IP VIP:virtual server IP DIP:ditecter IP(connect with rs) RIP:real server IP 用户请求的IP一定是VIP,否则vs就失去了负载均衡的调度意义 LVS方式的cluster从结构上可分为两部分:前端的负载均衡器(称之为director)和后端的真实服务器(称之为real