redo log在事务执行过程中可以不断写入，而binlog只有在提交事务时才写入，都指的是写入到cache中。
无论是 Redo log 还是 Binlog，在事务执行过程中都会先写入到内存中。只有在特定的刷新条件下（例如事务提交时或者特定的刷新策略）才会将日志数据从内存刷新到磁盘中。
redo log、undo log是由MySQL Innodb引擎提供大的事务日志，binlog是由MySQL的Server层实现的，由所有引擎公用的归档日志。

为什么需要两阶段提交

如果只有 redo log 或者只有 binlog，那么事务就不需要两阶段提交。但是如果同时使用了 redo log 和 binlog，那么就需要保证这两种日志之间的一致性。否则，在数据库发生异常重启或者主从切换时，可能会出现数据不一致的情况。

例如，假设我们有一个事务 T，它修改了两行数据 A 和 B，并且同时开启了 redo log 和 binlog。如果我们先写 redo log 再写 binlog，并且在写完 redo log 后数据库发生了宕机，那么在重启后，根据 redo log 我们可以恢复 A 和 B 的修改，但是 binlog 中没有记录 T 的信息，导致备份或者从库中没有 T 的修改。反之，如果我们先写 binlog 再写 redo log，并且在写完 binlog 后数据库发生了宕机，那么在重启后，根据 redo log 我们无法恢复 A 和 B 的修改，但是 binlog 中有记录 T 的信息，导致备份或者从库中有 T 的修改。

为了避免这种情况，MySQL 引入了两阶段提交的机制。两阶段提交就是将一个事务分成两个阶段来提交：prepare 阶段和 commit 阶段。在 prepare 阶段，事务会先写 redo log 并将其标记为 prepare 状态，然后写 binlog；在 commit 阶段，事务会将 redo log 标记为 commit 状态，并将 binlog 落盘。这样，无论数据库在哪个时刻发生宕机，都可以根据 redo log 和 binlog 的状态来判断事务是否提交，并保证数据的一致性。

两阶段提交的流程

1. 在准备阶段，MySQL先将数据修改写入redo log，并将其标记为prepare状态，表示事务还未提交。然后将对应的SQL语句写入bin log。
2. 在提交阶段，MySQL将redo log标记为commit状态，表示事务已经提交。然后根据sync_binlog参数的设置，决定是否将bin log刷入磁盘。

通过这样的流程，MySQL可以保证在任何时刻，redo log和bin log都是逻辑上一致的。如果MySQL发生崩溃，可以根据redo log恢复数据页的状态，也可以根据bin log恢复SQL语句的执行。

转载：https://www.cnblogs.com/shoshana-kong/p/17471621.html