Redis--基础知识点--19--Redis_aof为什么先写数据库再写日志

发现问题

因为在常见的数据库中，持久化重做日志一般是先写日志再修改数据库，保证数据/操作不会丢失。所以看到redis的AOF日志的机制后，很困惑，

常见的有两种解释：

1.仅仅是因为，由于AOF文件会比较大，为了避免写入无效指令（错误指令），必须先做指令检查？如何检查，只能先执行了。因为语法级别检查并不能保证指令的有效性，比如删除一个不存在的key。而MySQL这种是因为它本身就维护了所有的表的信息，所以可以语法检查后过滤掉大部分无效指令直接记录日志，然后再执行。

2.Redis 的数据是存内存的，断电之后就丢了。Redis 的 AOF / RDB 相当于有一个把硬盘当内存的 slave。存储引擎数据是存硬盘的，断电之后，可能有脏数据，也可能没有，需要 redo log / undo log 来做原子 commit。保护 commit 的数据是不可能在 commit 之后写的。存储引擎的日志只保护 uncommitted data。

我个人觉得都有道理，可以综合考虑

1.如果有多条语句，执行了一条，然后停电了，就会导致出现脏数据，也无法进行完美的回滚，所以先记redo log/undo log来保证操作的原子性；
而redis停电了内存里的数据就没有了，如果停电前已记入aof，则重启后会执行aof中的操作，保证数据的一致性；如果停电前未计入aof,则重启后执行aof时由于最后一条指令没有计入aof也不会执行，此时相当于mysql的回滚，也会保证数据的一致性。

2.如果redis也采取先写日志再操作的话，AOF日志中会出现很多无效/错误的命令记录，对本来就庞大的AOF文件来说简直是雪上加霜，我认为这是第一个原因。

3.另外一个原因我认为是，redis的事务比起mysql等数据库的事务机制来说，可以称为弱事务，事务中出现某一个错误也会继续执行，同时如果CAS发现事务执行过程中，数据被其他线程更改了，那么事务执行失败，redis也没有回滚。这样的事务，会出现很多没有修改成功数据命令。如果先写日志，同样会有很多无效命令。