启动一个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
把写的命令备份到一个文件中，文件以明文方式存储
