通俗易懂解释redo log以及binlog为什么能够保证MySQL的crash-safe能力

什么是redo log以及binlog？在这里我就不用什么官方的语言去解释了，这种解释网上一大把一大把的，在这里我以一个生动的例子解释redo log以及binlog为什么能够保证MySQL的crash-safe能力。
redo log以及bing log的区别 
（1）：记录内容不同：
以一个仓库管理为例，redo log与binlog可以理解为该仓库的货物进出记录，只不过redo log和binlog记录的内容不一样。redo log记录物理日志的变化，比如在这个仓库中A货物从100件变成了102件。而binlog主要记录逻辑日志，比如A货物增加了2件。
（2）：记录方式不一样
redo log采用循环写的方式，也就是这个redo log写到末尾之后，再从头开始写（check部分后续会详细解释的）。而binlog会一直向后写，可以理解为没有空间限制。
（3）：用途不一样
因此当仓库管理员刚刚开始新的一天上班时（可以理解为MySQL刚刚崩溃重启），通过redo log就可以获取到该仓库里面货物的存放详细数据。当基于某个时间节点进行盘库时（可以理解为MySQL在某个时间点上进行恢复），假设这个时间点已经
做了盘库（在MySQL里可以理解为备份）那么可以通过binlog日志盘查到从这个时间点到任意时间点的货物数量详情。
为什么可以保证crash-safe
在这里以执行一个update语句为例说明redo log以及binlog是如何相互结合。
当执行update语句时，数据修改完，先写redo log 并设置redo log为准备阶段，再写binlog，写完binlog设置为redo log为结束阶段。两个中间有一个写入差错，那么该操作都是失败，即redo log发现只有准备阶段没有结束，那么会将该条事务进行回滚。
假如不采用这种机制的话那么会有什么影响呢？
（1）先写redo log：当写完redo log设备断电，binlog没有记录，那么数据库刚刚启动之后通过redo log可以恢复到断电前的状态，但是由于binlog没有写入，当从某个节点进行恢复时，那么binlog没用这条记录，恢复出来的数据库是有错误的。
（2）先写binlog：当写完binlog设备断电，redo log没有记录，那么数据库刚刚启动之后通过redo log恢复并没有这条数据，而当从某个时间点进行恢复时，binlog有相关数据，所以会导致数据不统一。