redis持久化概念

Author:SimpleWu
GitHub-redis

什么是持久化？

概念：把内存的数据保存在磁盘的过程。

Redis的持久化？

redis是内存数据库，它把数据存储在内存中，这样在加快读取速度的同时也对数据安全性产生了新的问题，即当redis所在服务器发生宕机后，redis数据库里的所有数据将会全部丢失。

Redis实现持久化的两种方式：

1. RDB(Redis DataBase )：就是在不同的时间点，将redis存储的数据生成快照并存储到磁盘等介质上.
2. AOF(Append Only File )：那就是将redis执行过的所有写指令记录下来，在下次redis重新启动时，只要把这些写指令从前到后再重复执行一遍，就可以实现数据恢复了。

全量写入-RDB

是将redis某一时刻的数据持久化到磁盘中，是一种快照式的持久化方法。

这种方式是就是将内存中所有的数据以快照的方式写入到二进制文件中，默认的文件名为dump.rdb。

修改默认文件名，找到将dump.rdb修改即可：

dbfilename dump.rdb

可以通过配置设置自动做快照持久化的方式。

默认：

save 900 1 save 300 10 save 60 10000

三个配置解析：

• 900秒内如果超过1个key被修改，则发起快照保存。
• 300秒内如果超过10个key被修改，则发起快照保存。
• 60秒内如果超过10000个key被修改，则发起快速保存。

注意：修改配置后，需要重启redis服务。

RDB参数

查看配置：

config get save

修改配置：

config set save "120 10"

RDB快照及恢复

三种触发快照方式：

1. 自动保存快照，配置文件中的快照参数设置。
2. 输入命令保存save或者bgsave。
3. 执行shutdown或者flsuhall命令时。

save和bgsave的区别：

当执行save时，不能进行其他操作，全部阻断。 bgsave为后台异步操作，执行时，服务器任然可以进行其它操作。如果想禁用RDB持久化策略，只要不设置任何save命令，或者给save传入一个空字符串也可以。

RDB-优点

1. redis在进行数据持久化的过程中，会先将数据写入到一个临时文件中，待持久化过程都结束了，才会用这个临时文件替换上次持久化好的文件。正是这种特性，让我们可以随时来进行备份，因为快照文件总是完整可用的。
2. RDB 可以最大化 Redis 的性能：父进程在保存 RDB 文件时唯一要做的就是 fork 出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘 I/O 操作。
3. 如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。

RDB-缺点

1. 虽然RDB有不少优点，但它的缺点也是不容忽视的。如果你对数据的完整性非常敏感，那么RDB方式就不太适合你，因为即使你每5分钟都持久化一次，当redis故障时，仍然会有近5分钟的数据丢失。
2. 每次保存 RDB 的时候，Redis 都要 fork() 出一个子进程，并由子进程来进行实际的持久化工作。 在数据集比较庞大时， fork() 可能会非常耗时，造成服务器在某某毫秒内停止处理客户端； 如果数据集非常巨大，并且 CPU 时间非常紧张的话，那么这种停止时间甚至可能会长达整整一秒。 虽然 AOF 重写也需要进行 fork() ，但无论 AOF 重写的执行间隔有多长，数据的耐久性都不会有任何损失。

增量写入AOF

AOF方式是将执行过的写指令记录下来，在数据恢复时按照从前到后的顺序再将指令都执行一遍，就这么简单。

redis会将每一个收到的写命令（如set、sadd、rpush）追加到 (默认是appendonly.aof)文件中。当redis重启时会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。

默认的AOF持久化策略是每秒钟fsync一次（fsync是指把缓存中的写指令记录到磁盘中），因为在这种情况下，redis仍然可以保持很好的处理性能，即使redis故障，也只会丢失最近1秒钟的数据。

AOF配置

修改AOF文件存放路径：

默认：

                    

                        
关键字：