Redis - redis.windows.conf配置文件及RDB和AOF数据持久化方案
Redis - redis.windows.conf配置文件及RDB和AOF数据持久化方案
Redis的高性能是由于其将所有数据都存储在了内存中，为了使Redis在重启之后仍能保证数据不丢失，需要将数据从内存中同步到硬盘中，这一过程就是持久化。
Redis支持两种方式的持久化，一种是RDB方式，一种是AOF方式。可以单独使用其中一种或将二者结合使用。
RDB持久化（默认支持，无需配置）
该机制是指在指定的时间间隔内将内存中的数据集快照写入磁盘。
AOF持久化
该机制将以日志的形式记录服务器所处理的每一个写操作，在Redis服务器启动之初会读取该文件来重新构建数据库，以保证启动后数据库中的数据是完整的。
无持久化
我们可以通过配置的方式禁用Redis服务器的持久化功能，这样我们就可以将Redis视为一个功能加强版的Memcached(一个自由开源的，高性能，分布式内存对象缓存系统)了。
1、RDB持久化
1.1、RDB持久化机制优点
一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，让redis的数据存取速度变快，这对于文件备份而言是非常完美的。
1.2、RDB持久化机制缺点
1.如果想保证数据的高可用性，即最大限度的避免数据丢失，那么RDB将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失，服务器断电时会丢失部分数据(数据的完整性得不到保证)。
2.由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。
1.3、快照与备份
快照是数据存储的某一时刻的状态记录。
备份则是数据存储的某一个时刻的副本。
1.4、快照触发条件
1.客户端执行命令save和bgsave会生成快照；
2.根据配置文件save m n规则进行自动快照；
3.主从复制时，从库全量复制同步主库数据，此时主库会执行bgsave命令进行快照；
4.客户端执行数据库清空命令FLUSHALL时候，触发快照；
5.客户端执行shutdown关闭redis时，触发快照；
1.5、RDB持久化机制的配置
# 如果900s内，如果至少有一个1个key进行了修改，就进行持久化操作
save 900 1
# 如果300s内，如果至少10个key进行了修改，就进行持久化操作
save 300 10
# 如果60s内，如果至少10000个key进行了修改，就进行持久化操作
save 60 10000
# 关闭该规则使用save “ ”
# yes代表当使用bgsave命令持久化出错时候停止写RDB快照文件,no表明忽略错误继续写文件。
stop-writes-on-bgsave-error yes
# # 是否压缩 rdb 文件，需要消耗一些cpu资源，该功能可以节约磁盘空间。
rdbcompression yes
# 在写入文件和读取文件时是否开启rdb文件检查，检查是否有无损坏，如果在启动是检查发现损坏，则停止启动
rdbchecksum yes
# 持久化文件名
dbfilename dump.rdb
# 数据文件存放目录，rdb快照文件和aof文件都会存放至该目录，请确保有写权限
dir ./
1.6、测试
1、删除redis安装目录下的dump.rdb文件
2、对redis进行操作，比如set test abc
3、关闭服务端并观察bin目录的变化（会发现重新出现dump.rdb文件）
2、AOF持久化
当redis存储非临时数据时，为了降低redis故障而引起的数据丢失，redis提供了AOF(Append Only File)持久化，从单词意思讲， 将命令追加到文件。AOF可以将Redis执行的每一条写命令追加到磁盘文件(appendonly.aof)中
在redis启动时候优先选择从AOF文件恢复数据。由于每一次的写操作，redis都会记录到文件中，所以开启AOF持久化会对性能有一定的影响。
以日志的形式来记录每个写操作，将Redis执行过的所有指令记录下来（读操作不记录），只许追加文件 但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件 的内容将写指令从前到后执行一次以完成数据的恢复工作
AOF持久化数据丢失更少，其消耗内存更少(RDB方式执行bgsave会有内存拷贝)
2.1、开启AOF持久化
默认情况下，redis是关闭了AOF持久化，开启AOF通过将redis.windows.conf配置文件中的appendonly改为yes开启。将appendonly修改为yes，开启aof持久化机制，默认会在目录下产生一个appendonly.aof文件。修改redis.windows.conf配置文件或者在命令行直接使用config set修改，再用config rewrite同步到配置文件。通过客户端修改好处是不用重启redis，AOF持久化直接生效。
config get appendonly 查询配置状态
config set appendonly yes 修改配置，命令生效了，但配置文件里没有生效
config rewrite 写入到redis.conf中，配置文件生效（如果先将该配置文件中改为了yes则只需要通过config set appendonly yes 命令改为yes即可，平常不想用即改为no即可）
2.2、AOF配置
appendonly no # 默认是不开启aof模式的，默认使用rdb方式进行持久化，大部分情况rdb够用
appendfsync always # 每执行一次更新命令，持久化一次
appendfsync everysec # 每秒钟持久化一次
appendfsync no # 不持久化
2.3、AOF文件错误
如果这个 aof 文件有错误，这时候 redis 是启动不起来的，我们需要修复这个aof文件 redis 给我们提供了一个工具 redis-check-aof --fix 。
redis-check-aof --fix appendonly.aof
这个工具可以修复错误，但是可能会造成一部分数据丢失(出现错误的那部分数据)。
2.4、AOF重写规则
aof 默认就是文件的无限追加，文件会越来越大。
如果 aof 文件大于 64m，太大了。 fork一个新的进程来将我们的文件进行重写。
2.5、优点
每一次修改都同步，文件的完整会更加好，持久化良好,能包证数据的完整性
2.6、缺点
1、相对于数据文件来说，aof远远大于 rdb，修复的速度也比 rdb慢。
2、Aof 运行效率也要比 rdb 慢，所以我们redis默认的配置就是rdb持久化。
2.7、测试
1、删除appendonly.aof
2、设置appendonly为yes
2、对redis进行操作，比如向redis中存入一个key
3、观察bin目录的变化(appendonly.aof文件会重新出现，打开后里面内容是刚才对redis操作的语句)
3、RDB-AOF混合持久化
通过aof-use-rdb-preamble配置参数控制，yes则表示开启，no表示禁用，默认是禁用的，可通过config set修改。
4、持久化扩展
1、RDB 持久化方式能够在指定的时间间隔内对你的数据进行快照存储。
2、AOF 持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始 的数据，AOF命令以Redis 协议追加保存每次写的操作到文件末尾，Redis还能对AOF文件进行后台重 写，使得AOF文件的体积不至于过大。
3、只做缓存，如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化。
4、同时开启两种持久化方式
在这种情况下，当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF 文件保存的数据集要比RDB文件保存的数据集要完整。
RDB 的数据不实时，同时使用两者时服务器重启也只会找AOF文件，那要不要只使用AOF呢？建议不要，因为RDB更适合用于备份数据库（AOF在不断变化不好备份），快速重启，而且不会有 AOF可能潜在的Bug，留着作为一个万一的手段。
5、性能建议
因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够 了，只保留 save 900 1 这条规则。
如果Enable AOF ，好处是在恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自 己的AOF文件就可以了，代价一是带来了持续的IO，二是AOF rewrite 的后将 rewrite 过程中产 生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite 的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上，默认超过原大小100%大小重 写可以改到适当的数值。
如果不Enable AOF ，仅靠 Master-Slave Repllcation 实现高可用性也可以，能省掉一大笔IO，也 减少了rewrite时带来的系统波动。代价是如果Master/Slave 同时倒掉，会丢失十几分钟的数据， 启动脚本也要比较两个 Master/Slave 中的 RDB文件，载入较新的那个，微博就是这种架构。