redis 持久化存储（RDB&AOF）

启动一个centos容器

docker run -it centos7-python3.7:latest

安装epel源

yum install epel-release

安装redis

yum instal redis

安装supervisor

yum install supervisor

修改redis配置文件

注释这三行

因为我们要运行多个redis，所以为了区分他们的存储，把这个文件加上端口号命名

确认supervisor的配置文件,这两行要打开，才能去找配置的ini文件

设置supervisor启动redis的ini文件

[program:redis-6379]   #这里是任务名
;执行的命令
command=/root/virtualenv/cmdb/bin/uwsgi /cmdb/SharkAPAMP/conf/qf_uwsgi.ini
priority=999                ; 优先级（越小越优先）
autostart=true              ; supervisord启动时，该程序也启动
autorestart=true            ; 异常退出时，自动启动
startsecs=10                ; 启动后持续10s后未发生异常，才表示启动成功
startretries=3              ; 异常后，自动重启次数
exitcodes=0,2               ; exit异常抛出的是0、2时才认为是异常
stopsignal=QUIT             ; 杀进程的信号

; 在程序发送stopignal后，等待操作系统将SIGCHLD返回给supervisord的秒数。
; 如果在supervisord从进程接收到SIGCHLD之前经过了这个秒数，
; supervisord将尝试用最终的SIGKILL杀死它
stopwaitsecs=1
user=root                   ; 设置启动该程序的用户
log_stdout=true             ; 如果为True，则记录程序日志
log_stderr=false            ; 如果为True，则记录程序错误日志
logfile=/var/log/qf_cmdb.log    ; 程序日志路径
logfile_maxbytes=1MB        ; 日志文件最大大小
logfile_backups=10          ; 日志文件最大数量

用supervisor启动redis
supervisord -c /etc/supervisord.conf

supervisorctl 进入supervisor的命令行 可以查看和管理supervisor的进程

不进入supervisor的命令行，也可以在外面执行

RDB 保存的模式

save和bgsave

重启redis，看看我们设置的name还再不在

bgsave 命令和 save基本一样，就是 bgsave 命令不会产生阻塞

127.0.0.1:6379> bgsave
Background saving started
127.0.0.1:6379>

也可以动态地设置一些配置，不用重启redis服务

AOF 保存的模式

Redis 目前支持三种 AOF 保存模式，它们分别是：

AOF_FSYNC_NO ：不保存。
AOF_FSYNC_EVERYSEC ：每一秒钟保存一次。(生产中一般选这种)
AOF_FSYNC_ALWAYS ：每执行一个命令保存一次

不保存
在这种模式下， SAVE 只会在以下任意一种情况中被执行：

Redis 被关闭
AOF 功能被关闭
系统的写缓存被刷新（可能是缓存已经被写满，或者定期保存操作被执行）

这三种情况下的 SAVE 操作都会引起 Redis 主进程阻塞。

每执行一个命令保存一次
在这种模式下，每次执行完一个命令之后， WRITE 和 SAVE 都会被执行。
另外，因为 SAVE 是由 Redis 主进程执行的，所以在 SAVE 执行期间，主进程会被阻塞，不能接受命令请求。

AOF 三种保存模式的比较

因为阻塞操作会让 Redis 主进程无法持续处理请求， 所以一般说来， 阻塞操作执行得越少、完成得越快， Redis 的性能就越好。

模式 1 的保存操作只会在AOF 关闭或 Redis 关闭时执行， 或者由操作系统触发， 在一般情况下， 这种模式只需要为写入阻塞， 因此它的写入性能要比后面两种模式要高， 当然， 这种性能的提高是以降低安全性为代价的： 在这种模式下， 如果运行的中途发生停机， 那么丢失数据的数量由操作系统的缓存冲洗策略决定。

模式 2 在性能方面要优于模式 3 ， 并且在通常情况下， 这种模式最多丢失不多于 2 秒的数据， 所以它的安全性要高于模式 1 ， 这是一种兼顾性能和安全性的保存方案。

模式 3 的安全性是最高的， 但性能也是最差的， 因为服务器必须阻塞直到命令信息被写入并保存到磁盘之后， 才能继续处理请求。

综合起来，三种 AOF 模式的操作特性可以总结如下：

模式 WRITE 是否阻塞？ SAVE 是否阻塞？ 停机时丢失的数据量
AOF_FSYNC_NO 阻塞 阻塞 操作系统最后一次对 AOF 文件触发 SAVE 操作之后的数据。
AOF_FSYNC_EVERYSEC 阻塞 不阻塞 一般情况下不超过 2 秒钟的数据。
AOF_FSYNC_ALWAYS 阻塞 阻塞 最多只丢失一个命令的数据。

BGREWRITEAOF

AOF重写机制

为什么需要重写机制?
AOF 文件通过同步 Redis 服务器所执行的命令， 从而实现了数据库状态的记录， 但是， 这种同步方式会造成一个问题： 随着运行时间的流逝， AOF 文件会变得越来越大。
对同一个键的状态的多次不同操作，而最终得到一个结果。比如对列表的添加删除元素。被频繁操作的键。比如累加

重新机制是如何实现的?
实际上， AOF 重写并不需要对原有的 AOF 文件进行任何写入和读取， 它针对的是数据库中键的当前值，也就是源数据从目前的内存中获取。

考虑这样一个情况， 如果服务器对键 list 执行了以下四条命令：

RPUSH list 1 2 3 4      // [1, 2, 3, 4]

RPOP list               // [1, 2, 3]

LPOP list               // [2, 3]

LPUSH list 1            // [1, 2, 3]

那么当前列表键 list 在数据库中的值就为 [1, 2, 3] 。

如果我们要保存这个列表的当前状态， 并且尽量减少所使用的命令数， 那么最简单的方式不是去 AOF 文件上分析前面执行的四条命令， 而是直接读取 list 键在数据库的当前值， 然后用一条 RPUSH 1 2 3 命令来代替前面的四条命令。

除了列表之外，集合、字符串、有序集、哈希表等键也可以用类似的方法来保存状态。
根据键的类型， 使用适当的写入命令来重现键的当前值， 这就是 AOF 重写的实现原理。

基本的步骤-->

for  遍历所有数据库:
      if  如果数据库为空：
             那么跳过这个数据库
      else:
            写入 SELECT 命令，用于切换数据库
            for  选择一个库后，遍历这个库的所有键
                   if 如果键带有过期时间，并且已经过期，那么跳过这个键
                   if 根据数据的类型，进行相关操作。

AOF 重写的实现方式

方式 区别
bgrewriteaof 命令 不需要重启服务，不便于统一管理
配置文件实现 需要重启服务，便于进行统一管理

配置文件实现

aof_current_size 和 aof_base_size 可以通过命令 info persistence 查看到

redis 重写流程图

对于上图有四个关键点补充一下：

在重写期间，由于主进程依然在响应命令，为了保证最终备份的完整性；因此它依然会写入旧的AOF file中，如果重写失败，能够保证数据不丢失。当然这个是可以通过配置来决定在重写期间是否进行主进程普通的 AOF 操作。
为了把重写期间响应的写入信息也写入到新的文件中，因此也会为子进程保留一个buf，防止新写的file丢失数据。
重写是直接把当前内存的数据生成对应命令，并不需要读取老的AOF文件进行分析、命令合并。
AOF文件直接采用的文本协议，主要是兼容性好、追加方便、可读性高可认为修改修复。

注意：无论是RDB还是AOF都是先写入一个临时文件，然后通过 rename 完成文件的替换工作。

配置示例

// 要想使用 AOF 的全部功能，需要设置为  yes
appendonly yes

// AOF 文件名，路径才看之前的 `dir` 配置项
appendfilename "appendonly.aof"

// 平常普通的 AOF 的策略
appendfsync everysec


// 当执行 AOF 重写时，是否继续执行平常普通的 AOF 操作。
// 这里设置文件  yes , 表示不执行
// 因为假如，同时执行，两种操作都会对磁盘 I/O 进行访问，造成
// I/O 访问量过大，产生性能衰减
no-appendfsync-on-rewrite yes

// AOF 文件容量的增长率
auto-aof-rewrite-percentage 100

// AOF 文件的最低容量，就是当前文件的大小大于此值时，就会进行重写。当然这只是其中一个条件。
auto-aof-rewrite-min-size 64mb

添加键值对数据，观察 AOF 文件
这里在命令行中设置，以便立刻生效

[root@s1 ~]# redis-cli
127.0.0.1:6379> config get appendonly
1) "appendonly"
2) "no"
127.0.0.1:6379> config set appendonly yes
OK
127.0.0.1:6379> config get appendonly
1) "appendonly"
2) "yes"

进行简单的数据添加操作

127.0.0.1:6379> set hello world
OK
127.0.0.1:6379> set hello python
OK
127.0.0.1:6379> set hello redis
OK
127.0.0.1:6379> incr nums
(integer) 1
127.0.0.1:6379> incr nums
(integer) 2
127.0.0.1:6379> incr nums
(integer) 3
127.0.0.1:6379> incr nums
(integer) 4
127.0.0.1:6379> rpush li a
(integer) 1
127.0.0.1:6379> rpush li b
(integer) 2
127.0.0.1:6379> rpush li b
(integer) 3
127.0.0.1:6379> rpush li c
(integer) 4
127.0.0.1:6379> exit

查看 AOF 文件

[root@s1 ~]# head appendonly.aof
*2
$6
SELECT
$1
0
*3
$3
SET
$5
hello

主动触发

先备份一份目前的 AOF 文件

[root@s1 ~]# cp /appendonly.aof{,.bak}
执行命令 bgrewriteaof

127.0.0.1:6379> config get appendonly
1) "appendonly"
2) "yes"
127.0.0.1:6379> BGREWRITEAOF
Background append only file rewriting started

最后对比两个文件的内容的不同之处。

RDB 和 AOF区别

如何抉择

从服务器开启 RDB

始终开启 AOF

不要使用主机的全部内存

特点

RDB

把当前内存的数据的状态就像是以快照的形式存储到本地硬盘中，这个文件是二进制的方式存储的。

AOF

把写的命令备份到一个文件中，文件以明文方式存储

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
平台声明：文章内容（如有图片或视频亦包括在内）由作者上传并发布，文章内容仅代表作者本人观点，简书系信息发布平台，仅提供信息存储服务。