Redis的持久化
- 把客户端和服务端都关闭了，再重新开启服务器和客户端，数据会不会丢失？
可能会全部丢失，也可能部分丢失
- Redis有两种数据持久化方法
- RDB(Redis Database)持久化:也称快照持久化 snap shotting：在指定的时间间隔能对你的数据进行快照存储，默认开启
- AOF持久化：记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据。，默认关闭
RDB持久化机制
- RDB持久化机制的配置
- 在 redis 的配置文件中，默认的持久化参数是：
# 时间策略 save 900 1 save 300 10 save 60 10000 # 持久化文件名称 dbfilename dump.rdb # 文件保存路径 redis安装目录下 # 如果持久化出错，主进程是否停止写入 stop-writes-on-bgsave-error yes # 是否压缩 rdbcompression yes #导入时是否检查 rdbchecksum yes- 上面参数说明
- 时间策略：
- 在900(15分钟)秒内如果修改了1个键，则进行持久化操作
- 在300(5分钟)秒内如果修改了10个键，则进行持久化操作
- 在60(1分钟)秒内如果修改了1万个键，则进行持久化操作
- 如果持久化出错，主进程是否停止写入：
stop-writes-on-bgsave-error yes:这个配置也是非常重要的一项配置，这是当备份进程出错时，主进程就停止接受新的写入操作，是为了保护持久化的数据一致性问题。如果自己的业务有完善的监控系统，可以禁止此项配置， 否则请开启。 - 是否压缩:
rdbcompression yes:建议没有必要开启，毕竟Redis本身就属于CPU密集型服务器，再开启压缩会带来更多的CPU消耗，相比硬盘成本，CPU更值钱。 - 当然如果你想要禁用RDB配置，也是非常容易的，只需要在save的最后一行写上：
save ""
- RDB持久化内存的数据到dump.rdb文件，文件中会存储键值对数据。
- RDB持久化的时候是将当时内存中所有的键值对一次性的持久化到dump.rdb文件。
案例
1.修改配置文件：redis.windows.conf 的101行，增加如下配置
save 15 3
2.重启redis服务器端：要求启动的时候指明配置文件启动
- 不能直接点击服务器打开，要做如下操作
1.进入Redis安装目录，在目录路径输入cmd，就打开了DOS命令窗口
2.启动服务器指定配置文件启动，格式：redis-server.exe redis.windows.conf
3.点击redis-cli.exe启动客户端，先在客户端执行keys * 查看所有的键
4.在客户端中测试在15秒内写入3个键
5.然后关闭服务器。再重复1-3步骤，就会发现数据还在
- 添加3个键后，服务器也出现提示成功，redis安装目录上会自动增加dump.rdb持久化文件，持久化文件中只记录内存中键值对的结果，不会记录对键值对修改的过程
- 关闭服务器，再重启服务器，执行keys *，查看所有的键已经恢复到数据库中
RDB持久化机制总结
1. RDB执行持久化的机制：在(指定时间)段内修改了(指定数量)的键时才执行持久化操作,只有两个条件同时才会持久化
2. RDB持久化机制的优点
因为不是实时持久化，所以效率高。
持久化文件中只记录内存中键值对的结果，不会记录对键值对修改的过程。
3. RDB持久化机制的缺点
因为不是实时持久化，所以数据容易丢失。
当一次持久化数据很大的时候，会导致服务器暂停。
AOF持久化机制
- 持久化机制： 以日志形式记录服务器每一个操作，在Redis服务器启动之初会读取该文件来重新构建数据库，以保证启动后数据库中的数据是完整的，默认是采用的策略是每秒持久化一次。
- AOF在redis配置文件中默认参数：
- appendonly no
# 是否开启aof
appendonly yes ---开启
# 文件名称
appendfilename "appendonly.aof"
# 同步方式
appendfsync everysec
# aof重写期间是否同步
no-appendfsync-on-rewrite no
# 重写触发配置
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
# 加载aof时如果有错如何处理
aof-load-truncated yes
# 文件重写策略
aof-rewrite-incremental-fsync yes
-
上面同步方式参数说明
-
appendfsync everysec它其实有三种模式:- always：每次修改都持久化，效率低，但是很安全
- everysec：每秒都持久化一次，是折中方案
- no：不持久化，效率最高，但是也最不安全
-
默认是采用的策略是每秒持久化一次。
-
一般情况下都采用 everysec 配置，这样可以兼顾速度与安全，最多损失1s的数据。
-
aof-load-truncated yes如果该配置启用，在加载时发现aof尾部不正确是，会向客户端写入一个log，但是会继续执行，如果设置为no，发现错误就会停止，必须修复后才能重新加载。
案例
- 开启AOF机制：修改配置文件：redis.windows.conf，将393行修改如下
appendonly yes
- 重启redis服务器端：启动的时候指明配置文件启动
- 启动客户端，添加3个键
4.关闭服务器，再次启动看是否有持久化
打开appendonly.aof文件，查看文件的变化，会发现文件记录了所有操作的过程。
扫描二维码关注公众号，回复：
9462426 查看本文章
AOF总结
1. AOF执行持久化的机制：每秒执行一次持久化操作。
2. AOF持久化机制的优点:
因为持久化的频率更高了，所以数据更加安全，更不容易丢失。
3. AOF持久化机制的缺点:
因为持久化的频率更高了，导致性能低了。
因为日志文件中记录的所有修改的操作，在运行恢复数据过程中效率低。
