Redis-Redis为什么先执行命令再写日志以及为什么与Mysql的WAL不一样呢？
背景
说到日志，我们比较熟悉的是数据库的写前日志（Write Ahead Log, WAL），也就是说，在实际写数据前，先把修改的数据记到日志文件中，以便故障时进行恢复。不过，AOF日志正好相反，它是写后日志，“写后”的意思是Redis是先执行命令，把数据写入内存，然后才记录日志。那为什么有这个差异&以及Redis为什么这么设计呢？，特此记录一下这个对于我来说的一个灵魂问题，不知道大家会不会有这个疑惑，欢迎交流????????????
为什么Mysql是日志先行，Redis确可以不用
数据库的WAL机制解决的核心问题：InnoDB引擎就可以保证即使Mysql数据库发生异常重启，之前提交的记录都不会丢失，这个能力称为crash-safe。这种能力保证了使用InnoDB引擎的Mysql保持这严格的数据持久性。为了满足这个能力需要Mysql实现日志在前，操作在后。然后基于对日志的两阶段提交，实现crash-safe。
Redis的AOF机制解决核心问题：保证服务器宕机后，大量数据不用通过后端数据库进行恢复，通过自己记录的信息，就可以恢复很多数据，并不要求严格的数据持久性，因为数据兜底保存在数据库，没有的数据可以从数据库里面重新加载。基于这个特性，其实Redis的AOF日志不需要实现Mysql那种对日志的两阶段提交，因此就不需要强制必须要先记录日志然后在执行命令。
核心点：两个日志解决的核心问题不一样。
Redis为什么先执行命令再写日志？
| 方案 | 优点 | 缺点 |
|---|---|---|
| 写日志，再执行命令 | 如果是每次都刷磁盘，这种情况下可以保证数据不丢失，比如遇到日志写成功，但是执行失败的情况，后面恢复就可以找回数据 | 需要前置一个命令正确性检查模块，类似于Mysql语法、词法解析，影响性能 |
| 先执行命令，再写日志 | 避免额外命令正确性开销 | 无论如何都做不到数据不丢失 |
补充说明：关于先执行命令，再写日志策略网上其他文章写的另外一个好处：不会阻塞当前操作，但是这个会阻塞后面操作。其实这样从宏观层面，Redis吞吐量还是不变的，我个人觉得这个不算是一个好处，毕竟我们不关心具体阻塞的哪一个操作或者阻塞时机，我们更关心这个阻塞会不会对Redis整体吞吐量有影响。
总结
Mysql的WAL机制和Redis的AOF机制出发点不一样，导致他们流程不一样，但是他们也有一样的地方，就是关于刷盘时机，InnoDB的Mysql有两种日志，因此有两个参数(sync_binlog、innodb_flush_log_at_trx_commit) Redis只有一种日志，通过appendfsync控制。这里比较出来两种流程差异到是其次，更重要对于文件的刷盘机制考虑，他们的考虑设计或许对我们日常真正的业务场景更有参考价值。
关于AOF日志写入时机，虽然进行方案对比，但是其实选择哪个方案是不言而喻的，写日志，再执行命令方案带来的好处刚好违背了Redis的最重要的理念:高性能。因此选择后者先执行命令，再写日志。
作者：WiseZ
链接：https://juejin.cn/post/7022447255722393608