高可用Redis(七)：Redis持久化 (5)

1.打开一个Redis客户端

[root@mysql ~]# redis-cli 127.0.0.1:6379> config get appendonly # 查看appendonly配置项结果 1) "appendonly" 2) "no" 127.0.0.1:6379> config set appendonly yes # 设置appendonly选项为yes OK 127.0.0.1:6379> config rewrite # 把配置写入到文件中 OK 127.0.0.1:6379> config get appendonly # 再次查看appendonly选项结果，看修改是否写入到配置文件中 1) "appendonly" 2) "yes" 127.0.0.1:6379> set hello world OK 127.0.0.1:6379> set hello php OK 127.0.0.1:6379> set hello python OK 127.0.0.1:6379> incr counter (integer) 1 127.0.0.1:6379> incr counter (integer) 2 127.0.0.1:6379> rpush list a (integer) 1 127.0.0.1:6379> rpush list b (integer) 2 127.0.0.1:6379> rpush list c (integer) 3 127.0.0.1:6379> dbsize # 查看Redis中数据量 (integer) 3

2.在系统命令提示符中查看AOF文件的大小

[root@mysql redis]# ll -h # 正常的AOF文件大小为278B total 8.0K -rw-r--r-- 1 redis redis 278 Oct 13 18:32 appendonly.aof -rw-r--r-- 1 redis redis 135 Oct 13 18:32 dump.rdb

3.在Redis客户端执行AOF重写命令

127.0.0.1:6379> bgrewriteaof # 在Redis客户端中执行AOF重写命令 Background append only file rewriting started

4.再次在系统命令提示符中查看新的AOF文件大小

[root@mysql redis]# ll -h total 8.0K -rw-r--r-- 1 redis redis 138 Oct 13 18:33 appendonly.aof # AOF重写后文件大小为138B -rw-r--r-- 1 redis redis 135 Oct 13 18:32 dump.rdb [root@mysql redis]# 3.3 RDB和AOF的选择 3.3.1 RDB和AOF的比较

3.3.2 RDB最佳策略

RDB是一个重操作

Redis主从复制中的全量复制是需要主节点执行一次BGSAVE命令，然后把RDB文件同 步给从Redis从节点来实现复制的效果

如果对Redis按小时或者按天这种比较大的量级进行备份，使用RDB是一个不错的选择，集中备份管理比较方便

在Redis主从架构中，可以在Redis从节点开启RDB，可以在本机保存RDB的历史文件，但是生成RDB文件的周期不要太频繁

Redis的单机多部署模式对服务器的CPU，内存，硬盘有较大开销，实际生产环境根据需要进行设定

3.3.3 AOF最佳策略

建议把appendfsync选项设定为everysec，进行持久化，这种情况下Redis宕机最多只会丢失一秒钟的数据

如果使用Redis做为缓存时，即使数据丢失也不会造成任何影响，只需要在下次加载时重新从数据源加载就可以了

Redis单机多部署模式下，AOF集中操作时会fork大量的子进程，可能会出现内存爆满或者导致操作系统使用SWAP分区的情况

一般分配服务器60%到70%的内存给Redis使用，剩余的内存分留给类似fork的操作

3.3.4 RDB和AOF的最佳使用策略

使用max_memory对Redis进行规划，例如Redis使用单机多部署模式时，每个Redis可用内存设置为4G，这样无论是使用RDB模式还是AOF模式进行持久化，fork子进程操作都只需要较小的开销

Redis分布式时，小分片会产生更多的进程，可能会对CPU的消耗更大

根据缓存或者存储不同架构使用不同策略

使用监控软件对服务器的硬盘，内存，负载，网络进行监控，以对服务器各硬盘有更全面的了解，方便发生故障时进行定位

不要占用100%的内存

上面的策略，无论使用RDB还是使用AOF，都可以做为参考

4. Redis持久化开发运维问题 4.1 Redis的fork操作

Redis的fork操作是同步操作

执行BGSAVE和BGAOF命令时，实际上都是先执行fork操作，fork操作只是内存页的拷贝，而不是完全对内存的拷贝

fork操作在大部分情况下是非常快的，但是如果fork操作被阻塞，也会阻塞Redis主线程的运行

fork与内存量息息相关：Redis中数据占用的内存越大，耗时越长(与机器类型有关)，可以通过info memory命令查看上次fork操作消耗的微秒数：latest_fork_usec:0

fork操作优化：

1.优先使用物理机或者高效支持fork操作的虚拟化技术 2.控制Redis实例最大可用内存:maxmemory 3.合理配置linux内存分配策略：vm.overcommit_memory = 1 4.降低fork频率，例如放宽AOF重写自动触发机制，不必要的全量复制 4.2 进程外开销 4.2.1 CPU开销

RDB和AOF文件的生成操作都属于CPU密集型

通常子进程的开销会占用90%以上的CPU，文件写入是非常密集的过程

CPU开销优化

1.不做CPU绑定，不要把Redis进程绑定在一颗CPU上，这样Redis fork子进程时，会分散消耗的CPU资源，不会对Redis主进程造成影响

2.不和CPU密集型应用在一台服务器上部署，这样不会产生CPU资源的过度竞争

3.在使用单机部署Redis时，不要发生大量的RDB,BGSAVE,AOF的过程，保证可以节省一定的CPU资源

4.2.2 内存开销

fork子进程会产生一定内存开销，理论上fork子进程操作占用的内存是等于父进程占用的内存