自学html做网站要多久,搜索引擎优化是什么?,小型网站建设参考文献,网页设计制作公司做什么Redis 支持多种持久化方式来保证数据的可靠性和持久性。前面我们介绍了RDB方式。我们我们介绍第二种方式——AOF#xff08;Append Only File#xff09;机制是一种常用的持久化方式#xff0c;它记录了所有对 Redis 数据库进行修改的命令#xff0c;在 Redis 重启时可以使…Redis 支持多种持久化方式来保证数据的可靠性和持久性。前面我们介绍了RDB方式。我们我们介绍第二种方式——AOFAppend Only File机制是一种常用的持久化方式它记录了所有对 Redis 数据库进行修改的命令在 Redis 重启时可以使用这些命令来重构数据库状态。
目录
1.AOF的基本原理
1.1 如何启动AOF
1.2 AOF 文件的创建
1.3. AOF 文件的写入
1.4. AOF 文件的重写
1.5. AOF 文件的恢复
1.6. 小结
2. RDB和AOF混合方式
3 .AOF 持久化实践 1.AOF的基本原理
1.1 如何启动AOF
在 Redis 的配置文件中可以通过以下配置项来设置 AOF 持久化相关的参数 1. appendonly设置是否开启 AOF 持久化默认为 no关闭状态。 2. appendfilename设置 AOF 文件名默认为 appendonly.aof。 3. appendfsync设置 AOF 文件同步策略有以下三种可选值 - always每次写入都会同步到磁盘最安全但性能最差 - everysec每秒同步一次到磁盘安全性和性能的折中方案 - no由操作系统决定何时同步最不安全但性能最好。 4. auto-aof-rewrite-percentage设置 AOF 重写触发的条件之一即 AOF 文件大小增长率达到该值时触发 AOF 重写默认为 100。 5. auto-aof-rewrite-min-size设置 AOF 重写触发的条件之一即 AOF 文件大小达到该值时触发 AOF 重写默认为 64MB。 6. aof-load-truncated设置当 Redis 以 AOF 模式启动时是否自动修复截断的 AOF 文件默认为 yes。 7. aof-use-rdb-preamble设置是否在 AOF 文件中使用 RDB 文件的前缀默认为 yes。 修改 Redis 配置文件后需要重启 Redis 才能使配置生效。同时对于 AOF文件同步策略的选择需要根据实际情况进行权衡和选择。如果对数据的安全性要求非常高可以选择 always 策略如果对性能的要求比较高可以选择 everysec 策略。
1.2 AOF 文件的创建
当启用 AOF 持久化机制时Redis 会在启动时创建一个 AOF 文件用于记录所有写命令。AOF 文件的默认文件名为 appendonly.aof可以通过配置文件中的 appendfilename 参数进行修改。如果 AOF 文件已经存在则 Redis 会在启动时读取文件中的内容并将其加载到内存中。
1.3. AOF 文件的写入
当 Redis 执行写命令时会将命令追加到 AOF 文件的末尾。如果 AOF 文件不存在则 Redis 会自动创建一个新的 AOF 文件。如果 AOF 文件已经存在则 Redis 会将命令追加到文件的末尾。
Redis 为了提高写入性能通常会将多个命令缓存到内存中然后在满足一定条件时批量写入到 AOF 文件中。具体来说Redis 会维护一个 AOF 缓冲区将每个写命令追加到缓冲区的末尾。当缓冲区的大小超过一定阈值时或者缓冲区中的命令已经等待了一定时间后Redis 会将缓冲区中的命令批量写入到 AOF 文件中。 1.3. AOF 文件的同步 为了保证写命令的可靠性和持久性Redis 会在写入 AOF 文件后进行同步操作将数据从内存中刷到磁盘中。这就是我通常所说的刷盘操作。刷盘操作可以分为两种方式
同步磁盘上的所有数据每次写入 AOF 文件时Redis 会调用 fsync 系统调用将数据从内存刷到磁盘中。这种方式可以保证数据的可靠性但是会带来较大的性能损耗。定期同步磁盘上的数据Redis 也可以通过配置文件中的 appendfsync 参数来控制 AOF 文件的同步方式。其中有三种常用的方式
always每次写入 AOF 文件时都进行同步操作可以保证数据的可靠性但是会带来较大的性能损耗。everysec每秒钟对 AOF 文件进行一次同步操作可以在一定程度上平衡数据安全和性能需求。no不进行同步操作只在 Redis 进程退出时进行一次同步操作可以提高性能但是会带来一定的数据风险。
这三种方式的对比我们可以通过下面的表来判断 总结来说就是
如果要高性能就选择 No 策略如果要高可靠就选择 Always 策略如果允许数据丢失一点但又想性能高就选择 Everysec策略。
1.4. AOF 文件的重写
Redis AOF 文件在长时间运行后可能会变得非常大不仅占用磁盘空间还会影响 Redis 的性能。为了解决这个问题Redis 提供了 AOF 文件重写机制可以将 AOF 文件中的写命令进行压缩生成一条等效的命令序列从而减少 AOF 文件的大小。
AOF 文件重写机制的实现原理如下
1Redis 会启动一个新的子进程用于执行 AOF 文件重写操作。
2Redis 主进程会将所有写命令发送到子进程中子进程会执行这些命令并生成一条等效的命令序列。
3子进程会将等效命令序列写入到一个新的 AOF 文件中同时在写入过程中进行同步操作保证数据的可靠性。
4当子进程完成 AOF 文件的重写操作后Redis 主进程会将新的 AOF 文件重命名为原来的 AOF 文件并删除旧的 AOF 文件。
需要注意的是AOF 文件重写操作只会对已经执行过的写命令进行压缩新的写命令仍然会被追加到 AOF 文件的末尾。Redis 会周期性地检查 AOF 文件的大小并在满足一定条件时触发 AOF 文件重写操作。
1.5. AOF 文件的恢复
AOF 的数据恢复过程设计很巧妙它模拟一个 Redis 的服务过程。Redis 首先虚拟一个客户端读取 AOF 文件恢复 Redis 命令和参数接着过程就和服务客户端一样执行命令相应的函数从而恢复数据这样做的目的无非是提高代码的复用率。这些过程主要在 loadAppendOnlyFile() 中实现。我们可以理解为假的重放。
真实的过程当 Redis 重启时会根据 AOF 文件中记录的命令重构数据库状态。具体来说Redis 会按照 AOF 文件中记录的命令顺序逐个执行命令并在执行过程中重建数据库状态。需要注意的是AOF 文件的恢复过程可能会比较耗时因此需要在 Redis 配置文件中设置 AOF 文件的恢复方式可以选择同步方式always、everysec或异步方式no。
所以Redis AOF 持久化机制其实说白了就是redis启动的时候创建一个server.aof_buf的文件通过一个文件实现了将写命令追加到 AOF 文件中并在需要时同步到磁盘中从而保证了数据的可靠性和持久性。 当异常宕机需要恢复数据的时候又通过读取文件回放之前的命令进行数据还原。 由此大家也可以推断出它存在的弊端。
1.6. 小结
对于相同的数据集来说AOF 文件的体积通常要大于 RDB 文件的体积。
根据所使用的 fsync 策略AOF 的速度可能会慢于 RDB 。
在一般情况下 每秒 fsync 的性能依然非常高 而关闭 fsync 可以让 AOF 的速度和 RDB 一样快 即使在高负荷之下也是如此。 不过在处理巨大的写入载入时RDB 可以提供更有保证的最大延迟时间latency
到此我们学完了 Redis 的持久化方式 RDB 和AOF 。那么我们对比一下。整理出如下表格
RDBAOF启动优先级低高体积比 AOF 小比 RDB 大恢复速度比 AOF 快比 RDB 慢数据安全性在定时备份时可能会丢失一定量的数据根据同步策略决定相对更安全数据一致性RDB 持久化的数据可能不是最新的但数据一致性较高AOF 持久化的数据较新但数据一致性较低运维复杂度相对简单只需要定期备份 RDB 文件即可相对复杂需要配置 AOF 缓冲区大小、同步策略等参数写入性能相对较高因为 RDB 只需要生成一次快照文件即可完成持久化操作相对较低因为 AOF 需要将每一次写操作都写入到 AOF 文件中读取性能相对较高因为 RDB 文件读取速度快相对较低因为需要将 AOF 文件中的所有写操作都执行一遍才能恢复文件格式二进制格式比较紧凑文本格式可读性好恢复方式通过加载 RDB 文件来恢复数据库通过加载 AOF 文件并执行其中的写操作来恢复数据库文件重写方式通过 BGSAVE 命令生成新的 RDB 文件来实现文件重写通过执行 BGREWRITEAOF 命令来生成新的 AOF 文件实现文件重写
2. RDB和AOF混合方式
Redis 4.0 中提出了一个混合使用 AOF 日志和内存快照的方法。简单来说内存快照以一定的频率执行在两次快照之间使用 AOF 日志记录这期间的所有命令操作。
混合方式可以同时利用 RDB 的快速恢复和 AOF 的数据安全性。在这种混合方式下Redis 会同时生成 RDB 文件和 AOF 文件来保证数据的安全性和可靠性。
具体来说可以采用如下的持久化配置
将 AOF 模式设置为 always并设置合适的同步策略以确保 Redis 在执行写操作时都将对应的操作写入 AOF 文件中。
在 Redis 中启用 RDB 持久化并设置一个合适的持久化间隔以确保 Redis 在每隔一定时间内执行一次 RDB 文件的快照生成操作。
将 Redis 配置为在启动时先尝试使用 AOF 文件进行恢复如果 AOF 文件不存在或损坏则使用 RDB 文件进行恢复。
通过这种方式可以将 RDB 和 AOF 的优点结合起来从而达到更加全面的数据保护和恢复能力。同时也需要注意这种方式会带来一定的存储和性能开销需要根据实际情况进行权衡和优化。
参考 AOF
3 .AOF 持久化实践
这个和上一篇一样后面研究一下如何在本地能启动多个redis然后再补充如何实战
