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

3.打开redis-cli，向Redis中设置5个value

127.0.0.1:6379> flushall # 清空Redis中已有的所有数据 OK 127.0.0.1:6379> set hello world OK 127.0.0.1:6379> set a b OK 127.0.0.1:6379> set c d OK 127.0.0.1:6379> set e f OK 127.0.0.1:6379> set g i OK

4.查看Redis的日志记录

[root@mysql ~]# tail /var/log/redis/redis.log # 查看Redis日志的最后10行 3325:M 13 Oct 15:53:44.323 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128. 3325:M 13 Oct 15:53:44.323 # Server started, Redis version 3.2.10 3325:M 13 Oct 15:53:44.323 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect. 3325:M 13 Oct 15:53:44.323 # WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled. 3325:M 13 Oct 15:53:44.323 * The server is now ready to accept connections on port 6379 3325:M 13 Oct 15:55:17.431 * 5 changes in 60 seconds. Saving... 3325:M 13 Oct 15:55:17.432 * Background saving started by pid 3349 3349:C 13 Oct 15:55:17.434 * DB saved on disk 3349:C 13 Oct 15:55:17.435 * RDB: 2 MB of memory used by copy-on-write 3325:M 13 Oct 15:55:17.534 * Background saving terminated with success

5.查看Redis的持久化文件

[root@mysql redis]# pwd /var/lib/redis [root@mysql redis]# ls -lah total 8.0K drwxr-x--- 2 redis redis 22 Oct 13 15:55 . drwxr-xr-x. 64 root root 4.0K Oct 13 13:38 .. -rw-r--r-- 1 redis redis 115 Oct 13 15:55 dump.rdb

RDB现存问题

1.耗时耗性能

Redis把内存中的数据dump到硬盘中生成RDB文件，首先要把所有的数据都进行持久化，所需要的时间复杂度为O(N)，同时把数据dump到文件中，也需要消耗CPU资源，
由于BGSAVE命令有一个fork子进程的过程，虽然不是完整的内存拷贝，而是基于copy-on-write的策略，但是如果Redis中的数据非常多，占用的内存页也会非常大，fork子进程时消耗的内存资源也会很多
磁盘IO性能的消耗，生成RDB文件本来就是把内存中的数据保存到硬盘当中，如果生成的RDB文件非常大，保存到硬盘的过程中消耗非常多的硬盘IO

2.不可控，丢失数据

自动创建RDB文件的过程中，在上一次创建RDB文件以后，又向Redis中写入多条数据，如果此时Redis服务停止，则从上一次创建RDB文件到Redis服务挂机这个时间段内的数据就丢失了

3.2 AOF(AppendOnlyFile)方式 3.2.1 AOF原理

AOF创建

当向Redis中写入一条数据时，就向AOF文件中添加一条写记录

如下图所示

AOF恢复

Redis发生宕机重启后，读取AOF文件对Redis中的数据进行完整的恢复，而且使用AOF文件来恢复Redis中的数据是实时的

如下图所示

3.2.2 AOF

AOF持久化保存数据库的方法是：每当有修改的数据库的命令被执行时，服务器就会将执行的命令写入到AOF文件的末尾。

因为AOF文件里面储存了服务器执行过的所有数据库修改的命令，所以Redis只要重新执行一遍AOF文件里面保存的命令，就可以达到还原数据库的目的

3.2.3 AOF安全性问题

虽然服务器执行一次修改数据库的命令，执行的命令就会被写入到AOF文件，但这并不意味着AOF持久化方式不会丢失任何数据

在linux系统中，系统调用write函数，将一些数据保存到某文件时，为了提高效率，系统通常不会直接将内容写入硬盘里面，而是先把数据保存到硬盘的缓冲区之中。

等到缓冲区被填满，或者用户执行fsync调用和fdatasync调用时，操作系统才会将储存在缓冲区里的内容真正的写入到硬盘里

对于AOF持久化来说，当一条命令真正的被写入到硬盘时，这条命令才不会因为停机而意外丢失

因此，AOF持久化在遭遇停机时丢失命令的数量，取决于命令被写入硬盘的时间

越早将命令写入到硬盘，发生意外停机时丢失的数据就越少，而越迟将命令写入硬盘，发生意外停机时丢失的数据就越多

3.2.4 AOF三种策略

为了控制Redis服务器在遇到意外停机时丢失的数据量，Redis为AOF持久化提供了appendfsync选项，这个选项的值可以是always,everysec或者no