本文900字，内容经过多篇作者的提炼，用做简短干练的话让你瞬间读懂理解

一、redo log ：重做日志

　　作用：确保事务的持久性。防止在发生故障的时间点，尚有脏页未写入磁盘，在重启mysql服务的时候，根据redo log进行重做，从而达到事务的持久性特性。

　　内容：物理格式的日志，记录的是物理数据页面的修改的信息，其redo log是顺序写入redo log file的物理文件中去的。

特点：mysql，如果每次更新操作都要写进磁盘，然后磁盘要找到对应记录，然后再更细，整个过程io成本、查找成本都很高。

解决方案：WAL技术（Write-Ahead Logging）。先写日志，再写磁盘。

二、bin log ：归档日志（二进制日志）

　　作用：用于复制，在主从复制中，从库利用主库上的binlog进行重播，实现主从同步。用于数据库的基于时间点的还原。

　　内容：逻辑格式的日志，可以简单认为就是执行过的事务中的sql语句。但又不完全是sql语句这么简单，而是包括了执行的sql语句（增删改）反向的信息，也就意味着delete对应着delete本身和其反向的insert；update对应着update执行前后的版本的信息；insert对应着delete和insert本身的信息。

　　binlog 有三种模式：Statement（基于 SQL 语句的复制）、Row（基于行的复制） 以及 Mixed（混合模式）

三、undo log : 回滚日志

　　作用：保存了事务发生之前的数据的一个版本，可以用于回滚，同时可以提供多版本并发控制下的读（MVCC）即非锁定读

　　内容：逻辑格式的日志，在执行undo的时候，仅仅是将数据从逻辑上恢复至事务之前的状态，而不是从物理页面上操作实现的，这一点是不同于redo log的。数据库事务四大特性中有一个是原子性，原子性底层就是通过undo log实现的。

• 在执行更新语句过程，redo log与binlog的写入时机不一样。会导致问题么？

时机不同：

redo log在事务执行过程中可以不断写入。

binlog只有在提交事务时才写入。

所以redo log与binlog的写入时机不一样。会导致问题么？

• 为了解决两份日志之间的逻辑一致问题，InnoDB存储引擎使用两阶段提交。
• 原理很简单，将redo log的写入拆成了两个步骤prepare和commit，这就是两阶段提交。

开始事务 
更新数据 -----> 写入redo log（prepare阶段） 
提交事务 -----> 1.写binlog , 2.写入redo log（commit阶段)

四、Mysql 支持binlog订阅 怎么实现？

看下业界常规实现如下：

mysql-binlog -> 通过canal增量订阅 -> 发送到kafka（binlog json） - flink数据转换/分发(UMS格式)

原理：

canal模拟mysql slave的交互协议，伪装自己为mysql slave，向mysql master发送dump协议 mysql master收到dump请求，开始推送binary log给slave(也就是canal) canal解析binary log对象(原始为byte流)。