面试必会聊聊Mysql的binlogrelogunlog？

　　本文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流)。