canal

序 本文主要研究一下canal的CanalAdapterService CanalAdapterService canal-1.1.4/client-adapter/launcher/src/main/java/com/alibaba/otter/canal/adapter/launcher/loader/CanalAdapterService.java @Component @RefreshScope public class CanalAdapterService { private static final Logger logger = LoggerFactory.getLogger(CanalAdapterService.class); private CanalAdapterLoader adapterLoader; @Resource private ContextRefresher contextRefresher; @Resource private AdapterCanalConfig adapterCanalConfig; @Resource private Environment env; // 注入bean保证优先注册 @Resource private SpringContext springContext; @Resource private

序 本文主要研究一下canal的CanalAdapterWorker CanalAdapterWorker canal-1.1.4/client-adapter/launcher/src/main/java/com/alibaba/otter/canal/adapter/launcher/loader/CanalAdapterWorker.java public class CanalAdapterWorker extends AbstractCanalAdapterWorker { private static final int BATCH_SIZE = 50; private static final int SO_TIMEOUT = 0; private CanalConnector connector; /** * 单台client适配器worker的构造方法 * * @param canalDestination canal实例名 * @param address canal-server地址 * @param canalOuterAdapters 外部适配器组 */ public CanalAdapterWorker(CanalClientConfig canalClientConfig, String canalDestination, SocketAddress

目录 6.2 Zookeeper在大型分布式系统中的应用 6.2.1 Hadoop YARN介绍 如何解决ResourceManager单点问题，实现高可用？ 6.2.3 Kafka 术语介绍 问题 Kafka与Zookeeper Broker注册管理 Topic注册管理 生产者负载均衡 消费者负载均衡 消费分区与消费者关系 消息消费进度Offset记录 消费者注册 负载均衡 1）Range策略 2）RoundRobin策略 资料 6.3 Zookeeper在阿里巴巴的实践与应用 6.3.2 案例二 RPC服务框架：Dubbo 服务提供者 服务消费者 监控中心 6.3.3 案例三 基于MySQL Binlog的增量订阅和消费组件：Canal Canal基本工作原理 Canal Server主备切换设计 Canal Client的HA设计 6.3.4 案例四 分布式数据库同步系统：Otter 分布式SEDA模型 数据模型 任务处理流程(多阶段任务协调处理) 6.2 Zookeeper在大型分布式系统中的应用 6.2.1 Hadoop YARN介绍 YARN是Hadoop为了提高计算节点的扩展性，同时为了支持多计算模型和提供资源的细粒度调度而引入的全新一代分布式协调框架。 核心为ResourceManager，资源管理中心，负责集群中所有资源的统一管理和分配。 （可理解为YARN的大脑

3 月，跳不动了？>>> 导读 ： 作者：知数堂学员-邓志航；MySQL DBA,天生的MySQL爱好者,热衷于为他人解决问题,善于总结和分享。对数据平台构建和排查疑难问题有非常浓厚的兴趣 一、简介 记一次mysql流量问题的排查之旅 二、问题描述 在每天的业务高峰期间，都会出现流量被打满的情况，严重影响了业务的正常运行。 三、收集数据 1、通过监控图进行定位，发现是出口流量打满； 2、通过iftop进行定位,发现流量来源包括三方面： 从库的binlog拉取 canal的binlog拉取 多个应用服务的数据查询 3、查看binlog的生成量,发现binlog的生成量非常频繁,大概1分钟1个； 四、解决思路 1、首先尝试将canal的binlog不抽取主库,只抽取从库,然后进行观察,发现有效果,但是并不明显； 2、然后尝试建立缓存,将非必要的mysql查询走缓存,减少查询流量； 3、根据binlog进行分析,获取以下信息； 表:1 热表名称 2 热表的操作 发现更新和插入很频繁 单条insert内容 我们根据以上信息发现热表的insert和update操作都有大字段参与,经过与研发沟通了解到,是将类似json类型的数据存储到了mysql表中,造成了binlog频繁生成和切换,定位到了最主要的问题。 五、解决方法 1、减少binlog生成量(去掉大字段,减少事务操作量)

3 月，跳不动了？>>> 之前 设计篇 讲了数据拆分的方式、场景、优缺点以及实施步骤，偏方法与理论。技术篇会介绍分布式数据服务平台设计与实现，讲述如何通过技术手段解决数据拆分带来的各种问题，以及各中间件的架构与原理。 平台主要包括分布式数据访问中间件（SDK、Proxy）、平滑扩容、数据集成、管控平台等四部分。 一、分布式数据访问中间件 数据拆分后，分散在多个库与表中，但应用开发时怎样才能准确访问数据库，换言之，如何才能拿到准确的数据库连接，拼接出正确的sql（主要是实际表名），然后执行返回结果集呢？ 为了尽可能减少业务侵入性，应用少做改造，往往都会抽象出一个数据访问层负责上述功能。数据访问层按实现方式不同，可分为应用自定义、数据中间件、分布式数据库三种方式，在我们项目中采用的是中间件方式，其技术架构如下： 分布式数据访问层 按照接入方式不同，数据访问中间件可以分为 SDK、Proxy （云原生架构下可能还会有sidecar方式）。 一个典型的分库分表中间件由JDBC接口实现（SDK模式）、MySQL报文解析（Proxy、Sider模式）、SQL解析器，路由计算、SQL重写， SQL执行、聚合处理、结果集合并、数据源管理、配置管理等部分构成。 1、JDBC接口实现 JDBC接口实现起来并不太难，数据库连接池都是基于此实现，本质上就是一种装饰器模式，主要就是java

3 月，跳不动了？>>> 来源： oschina 链接： https://my.oschina.net/thomas2/blog/3207639

3 月，跳不动了？>>> 之前 设计篇 讲了数据拆分的方式、场景、优缺点以及实施步骤，偏方法与理论。技术篇会介绍分布式数据服务平台设计与实现，讲述如何通过技术手段解决数据拆分带来的各种问题，以及各中间件的架构与原理。 平台主要包括分布式数据访问中间件（SDK、Proxy）、平滑扩容、数据集成、管控平台等四部分。 一、分布式数据访问中间件 数据拆分后，分散在多个库与表中，但应用开发时怎样才能准确访问数据库，换言之，如何才能拿到准确的数据库连接，拼接出正确的sql（主要是实际表名），然后执行返回结果集呢？ 为了尽可能减少业务侵入性，应用少做改造，往往都会抽象出一个数据访问层负责上述功能。数据访问层按实现方式不同，可分为应用自定义、数据中间件、分布式数据库三种方式，在我们项目中采用的是中间件方式，其技术架构如下： 分布式数据访问层 按照接入方式不同，数据访问中间件可以分为 SDK、Proxy （云原生架构下可能还会有sidecar方式）。 一个典型的分库分表中间件由JDBC接口实现（SDK模式）、MySQL报文解析（Proxy、Sider模式）、SQL解析器，路由计算、SQL重写， SQL执行、聚合处理、结果集合并、数据源管理、配置管理等部分构成。 1、JDBC接口实现 JDBC接口实现起来并不太难，数据库连接池都是基于此实现，本质上就是一种装饰器模式，主要就是java

某厂面试归来，发现自己落伍了！>>> 前提 近段时间，业务系统架构基本完备，数据层面的建设比较薄弱，因为笔者目前工作重心在于搭建一个小型的数据平台。优先级比较高的一个任务就是需要近实时同步业务系统的数据（包括保存、更新或者软删除）到一个另一个数据源，持久化之前需要清洗数据并且构建一个相对合理的便于后续业务数据统计、标签系统构建等扩展功能的数据模型。基于当前团队的资源和能力，优先调研了 Alibaba 开源中间件 Canal 的使用。 这篇文章简单介绍一下如何快速地搭建一套 Canal 相关的组件。 关于Canal 简介 下面的简介和下一节的原理均来自于 Canal 项目的 README ： Canal[kə'næl] ，译意为水道/管道/沟渠，主要用途是基于 MySQL 数据库增量日志解析，提供增量数据订阅和消费。早期阿里巴巴因为杭州和美国双机房部署，存在跨机房同步的业务需求，实现方式主要是基于业务 trigger 获取增量变更。从 2010 年开始，业务逐步尝试数据库日志解析获取增量变更进行同步，由此衍生出了大量的数据库增量订阅和消费业务。 基于日志增量订阅和消费的业务包括： 数据库镜像 数据库实时备份 索引构建和实时维护（拆分异构索引、倒排索引等） 业务 Cache 刷新 带业务逻辑的增量数据处理 Canal的工作原理 MySQL 主备复制原理： MySQL 的 Master

前阵子老板安排了一个新任务，要建设一个商家商品搜索系统，能够为用户提供快速、准确的搜索能力，在用户输入搜索内容时，要能从商家名称和商品名称两个维度去搜索，搜索出来的结果，按照准确率排序，并按商家所属商品的关联关系，来组合数据结构，同时提供API给业务系统调用。 背景很简单，现实蛮复杂！我们面临以下几个难题： ①商家数据库和商品数据库是多台不同的服务器，并且数据量达百万级，如何才能实现跨数据库的数据同步呢？ ②商家和商品的数据是有从属关系的，不然就会把肯德基的香辣鸡腿堡挂到麦当劳去，这就尴尬了！ ③商家商品数据是经常更新的，比如修改价格、库存、上下架等，那搜索服务可不能搜出一堆过时的数据，如果客户明明搜出来的商品，点进去后却已下架了，那么客户就要吐槽了！如何实现搜索数据与源数据库增删改均实时同步呢？ 带着以上3个问题，我们开始了搜索服务的整体架构设计。 系统架构设计思路 为了设计出合适的系统架构，我们分析了现状。 首先，商家数据和商品数据分别存储在2个独立的MySQL8数据库，为满足商家数据和商品数据的关联，我们需要将两个库中所需要的表实时ETL到我们的搜索系统数据库。 其次，数据从商家、商品数据库ETL到搜索系统数据库后，需要实时的组合成为商家关联商品数据结构，并以父子文档的格式，存储到ES中。 最后，商家、商品数据库的增删改操作，需要实时的同步到ES中，也就是ES中的数据

前言 前面的文章里，我们了解到 canal 可以从 MySQL 中感知数据的变化。这是因为它模拟 MySQL slave 的交互协议，伪装自己为 MySQL slave ，从而实现了主从复制。 正是了解到这一点，笔者有两个问题便一直萦绕于心： 它是如何模拟 MySQL slave 交互协议的？ 它又是怎么解析 binlog 日志的呢？ 今天，笔者准备就着这两个问题，扒拉扒拉 canal 的代码，一探究竟。 一、MySQL 主从复制 在谈 canal 之前，我们有必要再重温下 MySQL 主从复制的原理。 总结上图的流程如下： MySQL master 将数据变更写入二进制日志 (binary log , 其中记录叫做二进制日志事件binary log events)； MySQL slave 将 master 的 binary log events 拷贝到它的中继日志 (relay log)； MySQL slave 重放 relay log 中的事件，将数据变更反映到自己的数据库。 二、canal 原理 上图就很形象的描述了 canal 的角色。它的原理也很简单： canal模拟mysql slave的交互协议，伪装自己为mysql slave，向mysql master发送dump协议； mysql master收到dump请求，开始推送binary log给slave