Redis 核心面试题归纳_write-ahead-log redis-优快云博客

本文链接：https://blog.youkuaiyun.com/Mr_changxin/article/details/136513730

文章目录

- Redis

Redis

AOF 相关

1. redis AOF 文件备份时，是使用的 write ahead log 的方式吗

Redis的AOF备份不是使用的Write-Ahead Logging（WAL）方式。Redis的AOF（Append-Only File）备份实际上是一种写后日志（Write-After Logging）的方式。在Redis中，数据首先会被写入内存，然后再将相关的操作命令记录到AOF日志文件中。这种方式的主要好处是可以避免记录错误的命令，因为只有当命令成功执行后，它才会被写入日志文件。

与此相反，Write-Ahead Logging（WAL）是一种在数据实际写入之前，先将修改的数据记录到日志文件中的机制。这种机制在数据库系统（如MySQL）中很常见，用于确保在发生故障时能够恢复数据。

因此，虽然Redis和某些数据库系统都使用了日志来确保数据的持久性和可恢复性，但它们采用的日志机制和方式是不同的。Redis的AOF备份使用的是写后日志的方式，而不是Write-Ahead Logging的方式。

2. redis 开启AOF后的写入步骤

在Redis中，当使用AOF（Append-Only File）持久化时，写入操作并不是直接写入到AOF文件后立即返回写入成功。实际上，Redis的写入操作遵循以下步骤：

写入内存：当客户端发送一个写命令（如SET、ADD等）到Redis服务器时，Redis首先会在内存中执行该命令，更新相应的数据结构。
写入AOF缓冲区：然后，Redis会将这个写命令追加到一个内部的AOF缓冲区中。这个缓冲区是一个内存中的队列，用于暂存待写入AOF文件的命令。
异步写入AOF文件：Redis会在一个后台线程中，将AOF缓冲区中的命令异步地写入到AOF文件中。这个过程是异步的，意味着它不会阻塞主线程对客户端的响应。
返回写入成功：一旦写命令在内存中执行成功，并且已经被追加到AOF缓冲区中，Redis就会向客户端返回写入成功的响应。此时，即使AOF文件还未将命令写入磁盘，客户端也会认为写入操作已经完成。
持久化到磁盘：后台线程会在适当的时候（比如AOF缓冲区积累了一定数量的命令，或者达到了特定的时间间隔）将AOF缓冲区中的命令持久化到磁盘上的AOF文件中。这个过程是后台进行的，不会阻塞主线程。

因此，虽然Redis在写入命令到AOF文件之前就已经向客户端返回了写入成功的响应，但命令最终会被持久化到AOF文件中，保证了数据的持久性。这种设计使得Redis可以同时保证高性能和数据的安全性。在Redis的配置中，可以通过调整AOF相关的参数（如appendfsync）来控制AOF文件同步到磁盘的策略，以平衡性能和持久性之间的需求。

3. redis AOF文件重写过程

AOF（Append-Only File）重写是Redis持久化机制中的一个重要环节，它用于优化AOF文件的大小和性能。当AOF文件增长到一定大小时，Redis会触发AOF重写过程，创建一个新的AOF文件，其中包含了能够重建当前数据集的最小命令集合。这个过程可以显著减少AOF文件的大小，因为它只包含必要的命令，而不是所有原始的操作日志。

AOF重写的过程大致如下：

触发重写：当AOF文件的大小超过配置的auto-aof-rewrite-min-size参数（默认为64MB）和auto-aof-rewrite-percentage参数（默认为100，表示AOF文件大小是上一次重写后大小的两倍）时，Redis会触发AOF重写。
创建临时文件：Redis会创建一个新的临时AOF文件，用于存储重写后的命令。
遍历数据集：Redis会遍历当前内存中的数据集，而不是读取原始的AOF文件。对于每个key，Redis会生成一个或多个命令来重建这个key。
写入临时文件：生成的重建命令会被写入到临时AOF文件中。这个过程中，Redis会跳过那些不必要的命令，例如过期键的删除命令，以及那些被后续命令覆盖的命令。
替换旧文件：当临时AOF文件写入完成后，Redis会将这个临时文件重命名为原来的AOF文件，从而替换掉旧的AOF文件。在重命名过程中，如果有写操作发生，Redis会先将这些写操作写入到一个新的临时文件中，等重命名操作完成后，再将这个临时文件的内容追加到新的AOF文件中。
更新统计信息：完成AOF重写后，Redis会更新统计信息，例如最后一次AOF重写的时间和文件大小等。

需要注意的是，在AOF重写过程中，Redis会同时向旧的AOF文件和新的临时文件写入命令。这是为了保证在重写过程中，如果发生故障，Redis仍然可以从旧的AOF文件中恢复数据。只有当临时文件写入完成，并且成功重命名为新的AOF文件后，旧的AOF文件才会被删除。

AOF重写是一个资源密集型的操作，因为它需要遍历整个数据集。因此，Redis会在后台异步地执行这个过程，以避免阻塞正常的写操作。重写过程中，Redis的性能可能会有所下降，因此建议在生产环境中，根据实际的负载情况，合理地配置AOF重写相关的参数。

4.AOF 持久化策略

AOF 持久化策略：这个持久化策略和MySQL中的 redo 日志的持久化策略很相似

always：每次写入缓存区都要同步到AOF文件中，硬盘的操作比较慢，限制了Redis高并发，不建议配置。
no：每次写入缓存区后不进行同步，同步到AOF文件的操作由操作系统负责，每次同步AOF文件的周期不可控，而且增大了每次同步的硬盘的数据量。
eversec：每次写入缓存区后，由专门的线程每秒钟同步一次，做到了兼顾性能和数据安全。是建议的同步策略，也是默认的策略。

RDB 相关

1.RDB 写入过程

RDB（Redis DataBase）文件是Redis用于持久化数据的一种方式，它会在指定的时间间隔内，将内存中的数据集快照写入到磁盘上的RDB文件中。RDB文件的写入过程大致如下：

触发RDB持久化：RDB持久化可以在多种情况下被触发，例如执行SAVE或BGSAVE命令、配置文件中指定的时间间隔达到、或者Redis服务器接收到SHUTDOWN命令等。其中，SAVE命令会阻塞Redis服务器直到持久化完成，而BGSAVE命令则会在后台异步执行持久化。
创建子进程：当触发RDB持久化时，Redis会创建一个子进程来执行持久化操作。这个子进程是Redis主进程的副本，它会共享主进程的内存空间。由于子进程是在主进程的内存空间上创建的，因此它可以直接访问内存中的数据。
生成RDB文件：子进程会遍历Redis内存中的所有数据，并将这些数据以紧凑的格式写入到一个临时RDB文件中。这个过程包括了将键值对转换为RDB文件格式，并写入到临时文件中。在生成RDB文件的过程中ÿ