Redis数据持久化如何做的？

Redis数据持久化如何做的？

为什么要做持久化？

​ 通过数据持久化可以将内存中的数据保存到磁盘中，以保证数据在服务重启或宕机时不会丢失。

持久化方式：RDB、AOF

**1、RDB（Redis数据备份文件）：**也叫做Redis数据快照。就是把内存所有数据都记录到磁盘中。当Redis出现故障重启后，从从磁盘读取快照文件，恢复数据。

Redis中默认使用RDB的方式，在redis.conf文件中有触发RDB的机制。

#900秒内，如果至少有一个Key被修改，则触发快照
save 900 1 
save 300 10
save 60 10000   
#可以根据业务的需求，适当修改触发机制。

RDB执行原理：

①、触发条件：

​ 通过配置文件中的save指令或手动触发RBD持久化操作。

②、生成快照：

​ 当满足条件是，Redis会fork出一个子进程，该子进程负责将当前内存中的数据写到一个临时文件中，防止阻塞主进程。

​ 子进程遍历所有的数据结构，将数据以Redis内部数据结构的形式写入一个临时文件，最终生成一个快照文件。

③、替换快照：

​ 生成快照文件后，Redis会用新的快照文件替换原有的RDB文件（默认名dump.rdb），这样就完成了一次RDB持久化操作。

​ 在这个过程中，Redis会确保使用原子性操作来替换文件，以避免在替换过程中的数据丢失或不一致。

④、恢复数据：

​ 在Redis重启时，会检查是否存在RDB文件，如果存在，则会加载RDB文件中的数据到内存中恢复状态。

​ 通过加载RDB文件，Redis可以在重启后迅速恢复到最近保存的数据状态，实现数据的持久化和恢复功能。

2、AOF（追加文件）：可以看做是日志命令文件，Redis在执行写操作时命令会记录在AOF文件中。

Redis中AOF默认是关闭的，可以在redis.conf文件中修改。

#是否开启AOF功能，默认是no
appendonly yes
#AOF文件名称
appendfilename "appendonly.aof"

AOF中的刷盘策略（数据更新方式）。

可以在redis.conf文件中修改。

#表示每执行一次写命令，立即记录到AOF文件中
appendfsync always
#写命令执行完成先放入AOF缓冲区，然后表示每隔一秒将缓冲区数据写到AOF文件，是默认方案。
appendfsync everysec
#写命令执行完先放入AOF缓冲区，由操作系统决定合适将缓冲区内容写回磁盘
appendfsync no

不同策略的区别、优点、缺点。

always：

​ 刷盘时机：同步刷盘

​ 优点：可靠性高，几乎不丢失数据。

​ 缺点：性能影响大

everysec：

​ 刷盘时机：每秒刷盘

​ 优点：性能适中

​ 缺点：最多丢失一秒钟的数据

no：

​ 刷盘时机：操作系统控制

​ 优点：性能最好

​ 缺点：可靠性较差，可能丢失大量数据

RDB和AOF对比：

1. RDB持久化：
   • 优点：
     • RDB持久化生成的快照文件相对较小，适合用于全量备份和恢复数据。
     • 在数据恢复时速度较快，因为只需加载一次快照文件即可恢复数据。
     • 对于大规模数据集和读写频繁的场景，RDB持久化对性能影响较小。
   • 缺点：
     • RDB持久化会定期保存快照，可能会导致在两次保存之间发生数据丢失。
     • 如果系统在最近一次保存之后崩溃，可能会丢失最后一次保存后的数据。
2. AOF持久化：
   • 优点：
     • AOF持久化记录了每次写操作的日志，可以提供更可靠的数据恢复保障。
     • 可以根据需要灵活地设置同步策略，平衡性能和数据安全性。
     • AOF持久化适合对数据完整性要求较高的场景。
   • 缺点：
     • AOF持久化生成的日志文件通常比RDB文件大，可能会占用更多的存储空间。
     • 在数据恢复时可能需要重新执行大量写操作，恢复速度相对较慢。
     • 对于大规模写入和频繁修改的场景，AOF文件可能会变得非常庞大。

总结：

1. 在实际应用中，可以根据业务需求和对数据一致性的要求选择合适的持久化方式或结合使用RDB和AOF。
2. 2.一种常见的做法是同时使用RDB和AOF持久化，通过AOF重写来压缩AOF文件大小，既保证了数据的完整性又提高了性能。
3. 总的来说，RDB持久化适合用于全量备份和快速数据恢复，而AOF持久化适合对数据完整性要求高的场景。选择合适的持久化方式取决于具体的业务需求和性能考量。