canal

大数据技术与架构 点击右侧关注，大数据开发领域最强公众号！ 暴走大数据 点击右侧关注，暴走大数据！ 之前 《MySQL Binlog同步HDFS的方案》 介绍性的文章简单介绍了实时同步mysql到hdfs的几种方案，本篇主要记录下利用canal同步mysql到hdfs的具体方案。 本文来自：http://bigdatadecode.club/MysqlToHDFSWithCanal.html canal server 部署 在canal中一个mysql实例对应一个配置文件，配置文件放在conf目录下的一个文件夹中，该文件夹的名字就代表了mysql实例。结构如下 -rwxr-xr-x 1 dc user 2645 Jul 18 14:25 canal.properties -rwxr-xr-x 1 dc user 2521 Jul 17 18:31 canal.properties.bak -rwxr-xr-x 1 dc user 3045 Jul 17 18:31 logback.xml drwxr-xr-x 2 dc user 4096 Jul 17 18:38 spring drwxr-xr-x 2 dc user 4096 Jul 19 11:55 trans1 trans1代表一个mysql实例，该文件夹中有个instance.properties文件

使用Canal实现redis和mysql的同步 canal 工作思路 Canal 会将自己伪装成 MySQL 从节点（Slave），并从主节点（Master）获取 Binlog，解析和贮存后供下游消费端使用。Canal 包含两个组成部分：服务端和客户端。服务端负责连接至不同的 MySQL 实例，并为每个实例维护一个事件消息队列；客户端则可以订阅这些队列中的数据变更事件，处理并存储到数据仓库中。下面我们将mysql同步到 redis mysql版本 5.6 canal版本 1.1.0 安装 mysql 后修改自己mysql配置 vim /etc/my.cnf # 开启mysql的binlog模块 log-bin=mysql-bin binlog-format=ROW # server_id需保证唯一，不能和canal的slaveId重复 server_id=121 # 需要同步的数据库名称 binlog-do-db=test_canal # 忽略的数据库，建议填写 binlog-ignore-db=mysql # 启动mysql时不启动grant-tables授权表 skip-grant-tables 创建一个mysql用户 canal 并且赋远程链接权限权限，和测试库 test_canal , CREATE USER canal IDENTIFIED BY 'canal';

一、 Docker安装 略 二、 修改MySQL配置 2.1 修改my.cnf配置 对于自建 MySQL , 需要先开启 Binlog 写入功能，配置 binlog-format 为 ROW 模式，my.cnf 中配置如下 log-bin=mysql-bin # 开启 binlog binlog-format=ROW # 选择 ROW 模式 server_id=1 # 配置 MySQL replaction 需要定义，不要和 canal 的 slaveId 重复 记得重启MySQL 2.2 新建MySQL用户 授权 canal 链接 MySQL 账号具有作为 MySQL slave 的权限, 如果已有账户可直接 grant -- 新建用户 CREATE USER canal IDENTIFIED BY 'canal'; -- GRANT ALL PRIVILEGES ON *.* TO 'canal'@'%' ; GRANT SELECT, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'canal'@'%'; -- 刷新权限 FLUSH PRIVILEGES; 三、 Canal Admin部署 2.1 下载镜像 docker hub #拉取 canal Admin镜像 $ docker pull canal/canal-admin

当我们需要对数据库的修改做监听的时候，可以使用阿里的canal。例如，可以实现将mysql中修改的数据更新到redis中，而不用每个service都分两步去先操作mysql再操作redis。 配置mysql 启用mysql的binlog # vim /etc/my.cnf 添加： [mysqld] log-bin=mysql-bin #添加这一行就ok binlog-format=ROW #选择row模式 server_id=1 #配置mysql replaction需要定义，不能和canal的slaveId重复 添加canal数据库用户 CREATE USER canal IDENTIFIED BY 'canal'; GRANT SELECT, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'canal'@'%'; -- GRANT ALL PRIVILEGES ON *.* TO 'canal'@'%' ; FLUSH PRIVILEGES; 配置canal 解压 mkdir /tmp/canal tar zxvf canal.deployer-$version.tar.gz -C /tmp/canal 修改配置文件 vi conf/example/instance.properties ####################

SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFA Stack（ S calable O pen F inancial A rchitecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。 SOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 " SOFA WEEKLY " 的形式回复 1 、 @ 叶毅威 提问： 请教下 SOFARegistry 数据持久化在哪里啊? A：SOFARegistry 的元数据（注册中心自身的 IP 列表之类的数据）存储在 meta 角色内，使用 JRaft 进行存储。应用的发布数据保存在 data 角色的内存中，采用三副本（可配置）的方式实现高可用。 SO FARegistry ： https://github.com

本文是Netty系列笔记第2篇 Netty是网络应用框架，所以从最本质的角度来看，是对网络I/O模型的封装使用。 因此，要深刻理解Netty的高性能，也必须从网络I/O模型说起。 看完本文，可以回答这三个问题： 五种I/O模型是什么？核心区别在哪里？ 同步=阻塞？异步=非阻塞？ Netty的高性能，是采用了哪种I/O模型？ 1.掌握五种I/O模型的关键钥匙 Unix系统下的五种基本I/O模型大家应该都有所耳闻，分为： blocking I/O（同步阻塞IO,BIO） nonblocking I/O(同步非阻塞IO，NIO) I/O multiplexing (I/O多路复用) signal driven I/O（信号驱动I/O） asynchronous I/O（异步I/O，AIO） 每种I/O的特性如何，尤其是同步/非同步、阻塞/非阻塞的区别，其实很多人并不能准确地进行区分。 所以，我们先把最核心的“钥匙”告诉大家，带着这把“钥匙”再来看I/O模型的关键问题，就能手到擒来了。 当一次网络IO发生时，主要涉及到 三个对象 ： 发起此次IO操作的Process或者Application 系统内核kernel。用户进程无法直接操作I/O设备，必须通过系统内核kernel与I/O设备交互。 I/O设备，包括网络、磁盘等。本文主要针对网络。 真正的I/O过程，主要分为 两个阶段 ：

点击上方“蓝字”关注我们 Flink DataStream API主要分为三个部分，分别为Source、Transformation以及Sink，其中Source是数据源，Flink内置了很多数据源，比如最常用的Kafka。Transformation是具体的转换操作，主要是用户定义的处理数据的逻辑，比如Map，FlatMap等。Sink(数据汇)是数据的输出，可以把处理之后的数据输出到存储设备上，Flink内置了许多的Sink，比如Kafka，HDFS等。另外除了Flink内置的Source和Sink外，用户可以实现自定义的Source与Sink。考虑到内置的Source与Sink使用起来比较简单且方便，所以，关于内置的Source与Sink的使用方式不在本文的讨论范围之内，本文会先从自定义Source开始说起，然后详细描述一些常见算子的使用方式，最后会实现一个自定义的Sink。 数据源 Flink内部实现了比较常用的数据源，比如基于文件的，基于Socket的，基于集合的等等，如果这些都不能满足需求，用户可以自定义数据源，下面将会以MySQL为例，实现一个自定义的数据源。本文的所有操作将使用该数据源，具体代码如下： /** * @Created with IntelliJ IDEA. * @author : jmx * @Date : 2020/4/14 * @Time : 17

当执行写操作后，需要保证从缓存读取到的数据与数据库中持久化的数据是一致的，因此需要对缓存进行更新。 因为涉及到数据库和缓存两步操作，难以保证更新的原子性。 在设计更新策略时，我们需要考虑多个方面的问题: 对系统吞吐量的影响：比如更新缓存策略产生的数据库负载小于删除缓存策略的负载 并发安全性：并发读写时某些异常操作顺序可能造成数据不一致，如缓存中长期保存过时数据 更新失败的影响：若某个操作失败，如何对业务影响降到最小 检测和修复故障的难度: 操作失败导致的错误会在日志留下详细的记录容易检测和修复。并发问题导致的数据错误没有明显的痕迹难以发现，且在流量高峰期更容易产生并发错误产生的业务风险较大。 更新缓存有两种方式: 删除失效缓存: 读取时会因为未命中缓存而从数据库中读取新的数据并更新到缓存中 更新缓存: 直接将新的数据写入缓存覆盖过期数据 更新缓存和更新数据库有两种顺序： 先数据库后缓存 先缓存后数据库 两两组合共有四种更新策略，现在我们逐一进行分析。 并发问题通常由于后开始的线程却先完成操作导致，我们把这种现象称为“抢跑”。 下面我们逐一分析四种策略中“抢跑”带来的错误。 先更新数据库，再删除缓存 若数据库更新成功，删除缓存操作失败，则此后读到的都是缓存中过期的数据，造成不一致问题。 可能发生的并发错误: 时间 线程A 线程B 数据库 缓存 1 缓存失效 v1 null 2

点 击 上 方 “ 中 间 件 兴 趣 圈 ” ， 选 择 “ 设 为 星 标 ” 做 积 极 的 人 ， 越 努 力 越 幸 运 ！ 真的非常开心，『中间件兴趣圈』公众号粉丝数正式迈过1W大关，达成一个重要里程碑，笔者感慨真的不容易。 2018年10月19号通过公众号发布第一篇文章，到今天为止，公众号已经发表了145篇原创文章，坚持真的很难，但只要能坚持，就一定会有好的收获，这不，你瞧，1W个人与你一起同行，这成就不可谓不大。 在持续坚持努力下，我出版了《RocketMQ技术内幕》一书，从一家名不经传的小公司顺利跳槽到快递物流头部企业：中通快递，让我能在更高的平台上发光发热，使我深深的认识到： 越努力越幸运，唯有坚持不懈 。希望能用这句话与各位粉丝朋友共勉，相互交流，共同成长。 相信各位读者朋友们也能直观的感受到『中间件兴趣圈』主要发表的文章都比较枯燥，因为大部分都是以源码分析为主，认真读完一篇文章需要极大的耐心，我从后台的统计数据上看到，每篇文章的读完率其平均值在50%左右，这足以说明大家拥有强烈的求知欲望，这里必须有掌声，为各自点个赞吧。与各位优秀的读者同行，是我的一大荣幸，未来继续加油。 『中间件兴趣圈』的定位是记录笔者的学习历程与成长历程，同时也起到驱动笔者去学习，给自己提的要求是尽最大努力保证一周一篇原创文章。 绝不注水、绝不洗稿，这是我的初心也是底线。 『中间件兴趣圈

点击上方 IT牧场 ，选择 置顶或者星标 技术干货每日送达 前言 在分布式系统中，缓存和数据库同时存在时，如果有写操作，先操作数据库还是先操作缓存呢？本文将分5种方案 展 开 阐述对比，谢谢阅读~ github地址，衷心感谢每一颗star ❝ https://github.com/whx123/JavaHome ❞ 缓存维护方案一 如果是一读（线程B）一写（线程A）操作， 「先操作缓存，再操作数据库」 。流程图如下所示： 1.线程A发起一个写操作，第一步del cache 2.线程A第二步写入新数据到DB 3.线程B发起一个读操作，cache miss缓存失效了。 4.线程B从DB获取最新数据 5.线程B执行set cache，把从DB读到的数据，更新到缓存。 「这样看，没啥问题」 。我们再看第二个流程图，如下： 1.线程A发起一个写操作，第一步del cache 2.此时线程B发起一个读操作，cache miss 3.线程B继续读DB，读出来一个老数据 4.然后老数据设置入cache 5.线程A写入DB最新的数据 OK，酱紫，就有问题了吧，老数据入到缓存了， 「每次读都是老数据啦，缓存与数据与数据库数据不一致了」 。 缓存维护方案二 上个方案是一读一写，如果是双写操作， 「先操作缓存，在操作数据库」 ，会怎么样呢？ 1.线程A发起一个写操作，第一步set cache 2