【redis】AOF日志：宕机了，Redis如何避免数据丢失

专题3-AOF日志：宕机了，Redis如何避免数据丢失

因为redis的数据是存在内存中的，一旦服务器宕机，内存中的数据会全部丢失。

AOF：redis先执行命令，把数据写入内存，然后才记录日志。

AOF优点；在命令执行后记录日志，所以不会阻塞当前的写操作。

AOF缺点：如果刚执行完一个命令，还没有来得及记录日志就宕机了，那么这个命令和相应的数据就有丢失的风险。 其次。虽然避免了当前命令的阻塞，但是可能会给下一个操作带来阻塞的风险。（因为AOF日志也是在主线程中执行，如果把日志写入磁盘时，磁盘写压力大，就会导致写盘很慢，进而后续的操作就无法执行）

为了解决AOF存在的问题，有三种写回策略：

Always，同步写回：每个写命令执行完，立马同步地将日志写回磁盘；-?影响主线程性能

Everysec，每秒写回：每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，每隔一秒把缓冲区中的内容写入磁盘； -》可能会丢失上一秒的数据

No，操作系统控制的写回：每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘。 -》可能导致数据丢失

AOF重写机制

为了防止AOF文件过大的性能问题。

为什么会有性能问题？

1. 文件系统的限制，无法保存过大的文件
2. 如果文件过大，往里面的追加记录，效率会变低
3. 如果发生宕机，AOF中的命令要被一个个重新执行，如果日志文件过大，整个恢复过程非常缓慢

AOF重写机制

可以减少文件大小，因为AOF文件会记录每一行的数据，而AOF重写只会记录最新的数据。

重写过程：

一个拷贝，两处日志

一个拷贝：

每次重写时，主线程fork后台的bgrewriteaof子线程，并且把主线程内存拷贝一份给bgrewrieaof子线程，然后bgrewrieaof子线程在不影响主线程的状况下，逐一把拷贝的数据携程操作。

两处日志：

第一处日志是正在使用的AOF日志。

第二处日志是AOF重写日志。

总结来说，每次 AOF 重写时，Redis 会先执行一个内存拷贝，用于重写；然后，使用两个日志保证在重写过程中，新写入的数据不会丢失。而且，因为 Redis 采用额外的线程进行数据重写，所以，这个过程并不会阻塞主线程。