目录
CentOS7安装redis-6.2.4
第一步：先安装redis想要的依赖包
第二步：开始安装redis
第三步：修改配置（线上启动配置方案）
redis 持久化的两种⽅式
RDB 优缺点
AOF 优缺点
RDB 和 AOF 到底该如何选择
redis持久化配置和定时冷备份脚本
综合使用 AOF 和 RDB 两种持久化机制
配置RDB持久化
配置AOP持久化
冷备份方案
CentOS7安装redis-6.2.4
redis官网现在redis-6.2.4压缩包，可以根据自己想要下载对应的包，官网地址：https://redis.io/
将下载的上传到 /usr/soft_pack 文件目录下（soft_pack是我这边自己建的文件夹，个人习惯把安装包统一放到一个地方）
开始安装
第一步：先安装redis想要的依赖包
yum -y install gcc gcc-c++ make tcl #测试需要依赖tcl
编译安装需要gcc5.3以上，可以用gcc -v 命令查看当前版本号，使用下面的命令升级到gcc9.1：
yum -y install centos-release-scl
yum -y install devtoolset-9-gcc devtoolset-9-gcc-c++ devtoolset-9-binutils
#scl命令启用只是临时的，新开的会话默认还是原gcc版本。
scl enable devtoolset-9 bash
#如果要长期使用gcc 9.1的话执行下面的命令即可：
echo -e "\nsource /opt/rh/devtoolset-9/enable" >>/etc/profile第二步：开始安装redis
# 1、切换到redis安装所在目录
cd /usr/soft_pack
# 2、解压安装包
tar -zxvf redis-6.2.4.tar.gz
# 3、将解压后的文件整个剪切到/usr/local 目下
mv redis-6.2.4 /usr/local/
# 4、切换进入redis 目录
cd /usr/local/redis-6.2.4
# 5、开始安装redis,需要花点时间，等执行完命令就安装成功了。
make && make test && make install
也可以一个命令一个命令来，如果是第一次安装建议一步一步来。
make 编译
make test 测试编译结果
make install 安装第三步：修改配置（线上启动配置方案）
如果是一般的学习课程，你就随便用redis-server 启动一下redis，做一些实验，生产的线上正式环境需要把redis作为一个系统的daemon进程去运行，每次系统启动，redis进程一起启动。
关于配置文件等文件使用端口号（6379）来命名，主要是需要在一台机子启动两个服务的时候，用于区分。
（1）redis utils 目录下，有个redis_init_script 脚本，将redis_init_script脚本拷贝到linux的 /etc/init.d 目录下，并重命名为redis_6379，6379是redis实例监听的端口号。
# 拷贝
cp /usr/local/redis-6.2.4/utils/redis_init_script /etc/init.d/
# 切换目录
cd /etc/init.d/
# 重命名
mv redis_init_script redis_6379
# 对redis_6379文件进行授权
chmod 777 redis_6379（2）修改redis_6379脚本的Redisport ，设置为相同的端口号（默认就是6379）
（3）创建两个目录，/etc/redis （存放redis的配置文件），/var/redis/6379 (redis的工作目录，存放redis的持久化文件）
mkdir -p /etc/redis
mkdir -p /var/redis/6379（4）修改redis配置文件（默认在redis根目录下，redis.conf），拷贝到/etc/redis 目录中，并重命名为redis_6379.conf
# 拷贝配置文件
cp /usr/local/redis-6.2.4/redis.conf /etc/redis/
# 修改配置文件名称
cd /etc/redis/
mv redis.conf redis_6379.conf
(注意：因为编辑配置文件直接下载下拉在打开编辑方便一点，使用也要授权一下，
因为如果没有授权的话，使用finalshell 工具，在文件夹下是找不到这个文件的)
chmod 777 redis_6379.conf注意：redis.conf 配置文件的重命名不是随便写的，对应的是 /etc/init.d/redis_6379 的conf 参数，如果配置不正确，启动会找不到配置文件
（下图是我修改后的，没有修改的之前是"/etc/redis/${REDISPORT}.conf"）
（5）修改redis.conf中的部分配置为生产环境
daemonize yes 让redis以daemon进程运行
pidfile /var/run/redis_6379.pid 设置redis的pid文件位置
port 6379 设置redis的监听端口号
dir /var/redis/6379 设置持久化文件的存储位置（6）启动redis ，执行 cd /etc/init.d ，./redis_6379 start
#切换目录
cd /etc/init.d
# 启动
./redis_6379 start（7）确认redis进程是否启动成功：ps -ef|grep redis
（8）配置redis跟随系统自动启动，需要在/etc/init.d/redis_6379 这个文件中添加一下两行注释
# chkconfig: 2345 90 10
# description: Redis is a persistent key-value database
# 执行命令，设置随系统启动 成功
chkconfig redis_6379 on以上单机的redis安装及配置完成。
redis 持久化的两种⽅式
RDB：RDB 持久化机制，是对 redis 中的数据执⾏周期性的持久化。
AOF：AOF 机制对每条写⼊命令作为⽇志，以 append-only 的模式写⼊⼀个⽇志⽂件中， 在 redis 重启的时候，可以通过回放 AOF ⽇志中的写⼊指令来重新构建整个数据集。
通过 RDB 或 AOF，都可以将 redis 内存中的数据给持久化到磁盘上⾯来，然后可以将这些数据 备份到别的地⽅去，⽐如说阿⾥云等云服务。
如果 redis 挂了，服务器上的内存和磁盘上的数据都丢了，可以从云服务上拷⻉回来之前的数 据，放到指定的⽬录中，然后重新启动 redis，redis 就会⾃动根据持久化数据⽂件中的数据， 去恢复内存中的数据，继续对外提供服务。
如果同时使⽤ RDB 和 AOF 两种持久化机制，那么在 redis 重启的时候，会使⽤ AOF 来重新构建 数据，因为 AOF 中的数据更加完整。
RDB 优缺点
- RDB 会⽣成多个数据⽂件，每个数据⽂件都代表了某⼀个时刻中 redis 的数据，这种多个数 据⽂件的⽅式，⾮常适合做冷备，可以将这种完整的数据⽂件发送到⼀些远程的安全存储 上去，⽐如说 Amazon 的 S3 云服务上去，在国内可以是阿⾥云的 ODPS 分布式存储上，以 预定好的备份策略来定期备份 redis 中的数据。
- RDB 对 redis 对外提供的读写服务，影响⾮常⼩，可以让 redis 保持⾼性能，因为 redis 主进 程只需要 fork ⼀个⼦进程，让⼦进程执⾏磁盘 IO 操作来进⾏ RDB 持久化即可。
- 相对于 AOF 持久化机制来说，直接基于 RDB 数据⽂件来重启和恢复 redis 进程，更加快 速。
- 如果想要在 redis 故障时，尽可能少的丢失数据，那么 RDB 没有 AOF 好。⼀般来说，RDB 数据快照⽂件，都是每隔 5 分钟，或者更⻓时间⽣成⼀次，这个时候就得接受⼀旦 redis 进 程宕机，那么会丢失最近 5 分钟的数据。
- RDB 每次在 fork ⼦进程来执⾏ RDB 快照数据⽂件⽣成的时候，如果数据⽂件特别⼤，可能 会导致对客户端提供的服务暂停数毫秒，或者甚⾄数秒。
AOF 优缺点
- AOF 可以更好的保护数据不丢失，⼀般 AOF 会每隔 1 秒，通过⼀个后台线程执⾏⼀次 fsync 操作，最多丢失 1 秒钟的数据。
- AOF ⽇志⽂件以 append-only 模式写⼊，所以没有任何磁盘寻址的开销，写⼊性能⾮常 ⾼，⽽且⽂件不容易破损，即使⽂件尾部破损，也很容易修复。
- AOF ⽇志⽂件即使过⼤的时候，出现后台重写操作，也不会影响客户端的读写。因为在 rewrite log 的时候，会对其中的指令进⾏压缩，创建出⼀份需要恢复数据的最⼩⽇志出 来。在创建新⽇志⽂件的时候，⽼的⽇志⽂件还是照常写⼊。当新的 merge 后的⽇志⽂件 ready 的时候，再交换新⽼⽇志⽂件即可。
- AOF ⽇志⽂件的命令通过⾮常可读的⽅式进⾏记录，这个特性⾮常适合做灾难性的误删除 的紧急恢复。⽐如某⼈不⼩⼼⽤ flushall 命令清空了所有数据，只要这个时候后台 rewrite 还没有发⽣，那么就可以⽴即拷⻉ AOF ⽂件，将最后⼀条 flushall 命令给删 了，然后再将该 AOF ⽂件放回去，就可以通过恢复机制，⾃动恢复所有数据。
- 对于同⼀份数据来说，AOF ⽇志⽂件通常⽐ RDB 数据快照⽂件更⼤。 AOF 开启后，⽀持的写 QPS 会⽐ RDB ⽀持的写 QPS 低，因为 AOF ⼀般会配置成每秒 fsync ⼀次⽇志⽂件，当然，每秒⼀次 fsync ，性能也还是很⾼的。（如果实时写⼊， 那么 QPS 会⼤降，redis 性能会⼤⼤降低）
- 以前 AOF 发⽣过 bug，就是通过 AOF 记录的⽇志，进⾏数据恢复的时候，没有恢复⼀模⼀ 样的数据出来。所以说，类似 AOF 这种较为复杂的基于命令⽇志 / merge / 回放的⽅式，⽐ 基于 RDB 每次持久化⼀份完整的数据快照⽂件的⽅式，更加脆弱⼀些，容易有 bug。不过 AOF 就是为了避免 rewrite 过程导致的 bug，因此每次 rewrite 并不是基于旧的指令⽇志进⾏ merge 的，⽽是基于当时内存中的数据进⾏指令的重新构建，这样健壮性会好很多。
RDB 和 AOF 到底该如何选择
- 不要仅仅使⽤ RDB，因为那样会导致你丢失很多数据；
- 也不要仅仅使⽤ AOF，因为那样有两个问题：第⼀，你通过 AOF 做冷备，没有 RDB 做冷备 来的恢复速度更快；第⼆，RDB 每次简单粗暴⽣成数据快照，更加健壮，可以避免 AOF 这 种复杂的备份和恢复机制的 bug；
- redis ⽀持同时开启开启两种持久化⽅式，我们可以综合使⽤ AOF 和 RDB 两种持久化机制， ⽤ AOF 来保证数据不丢失，作为数据恢复的第⼀选择; ⽤ RDB 来做不同程度的冷备，在 AOF ⽂件都丢失或损坏不可⽤的时候，还可以使⽤ RDB 来进⾏快速的数据恢复。
redis持久化配置和定时冷备份脚本
综合使用 AOF 和 RDB 两种持久化机制
- 用 AOF 来保证数据不丢失，作为数据恢复的第一选择;
- 用 RDB 来做不同程度的冷备，在 AOF 文件都丢失或损坏不可用的时候，还可以使用 RDB 来进行快速的数据恢复;
通过 RDB 或 AOF，都可以将 redis 内存中的数据给持久化到磁盘上面来，然后可以将这些数据备份到别的地方去，比如说阿里云，云服务。如果同时使用 RDB 和 AOF 两种持久化机制，那么在 redis 重启的时候，会使用 AOF 来重新构建数据，因为 AOF 中的数据更加完整。我觉得这里面两种最重要的差别是什么？rdb文件是快照 ， aof文件是操作指令。
配置RDB持久化
redis-6.2.4 配置文件两种持久化都是默认关闭的（有些版本是默认就是rdb持久化）
修改/etc/redis/redis-6379.conf 配置文件，将save 三个配置的注释去掉
- save 60 10000 : 每隔60s，如果有超过10000个key发生了变更，那么就生成一个新的dump.rdb文件，就是当前redis内存中完整的数据快照，这个操作也被称之为snapshotting，快照。也可以手动调用save或者bgsave命令，同步或异步执行rdb快照生成。
- save可以设置多个，就是多个snapshotting检查点，每到一个检查点，就会去check一下，是否有指定的key数量发生了变更，如果有，就生成一个新的dump.rdb文件。
- 可以设置多个检查点，默认设置了 3 个检查点。
配置AOP持久化
AOF 持久化，默认是关闭的，RDB 是默认开启的。
/etc/redis/redis_6379.conf 中的 APPEND ONLY MODE 配置区，将appendonly 配置成yes
appendonly yes 启用后 appendfsync 属性开始生效，有三个策略可选
- no：不主动执行fsync，仅仅 redis 负责将数据写入 os cache 就撒手不管了，然后后面 os 自己会时不时有自己的策略将数据刷入磁盘，不可控了
- always：每次写入一条数据就执行一次 fsync，每次写入一条数据，立即将这个数据对应的写日志 fsync 到磁盘上去，性能非常非常差，吞吐量很低; 确保说 redis 里的数据一条都不丢，那就只能这样了
- everysec：每隔一秒执行一次 fsync，每秒将 os cache 中的数据 fsync 到磁盘，这个最常用的，生产环境一般都这么配置，性能很高，QPS 还是可以上万的。
AOF rewrite
redis 中的数据其实有限的，很多数据可能会自动过期，可能会被用户删除，可能会被 redis 用缓存清除的算法清理掉，总之 redis 中的数据会不断淘汰掉旧的，就一部分常用的数据会被自动保留在 redis 内存中。
所以可能很多之前的已经被清理掉的数据，对应的写日志还停留在 AOF 中，AOF 日志文件就一个，会不断的膨胀，变大。
所以 AOF 会自动在后台每隔一定时间做 rewrite 操作，比如日志里已经存放了针对 100w 数据的写日志了; redis 内存中只剩下 10 万; 基于内存中当前的 10 万数据构建一套最新的日志，到 AOF 中; 覆盖之前的老日志; 确保 AOF 日志文件不会过大，保持跟 redis 内存数据量一致。
上面的配置意思是： 当 aof 日志超过 64 m 且，上一次 aof 之后的文件大小，比如是 60 m，那么当文件增长到 120 m 的时候，就会触发 rewrite 操作。
auto-aof-rewrite-percentage: 增长百分比，比上一次增长多少内容的时候就会触发 rewrite 操作。
auto-aof-rewrite-min-size：rewrite 操作的最小文件大小，超过该大小才会执行 rewrite 操作。
redis发生异常，重启，就会先恢复aof命令里面保存的数据。如果 redis 在 append 数据到 AOF 文件时，机器宕机了，可能会导致 AOF 文件破损。
可以用 redis-check-aof --fix 命令来修复破损的 AOF 文件（该命令在 redis 安装目录下）。
做完以上配置后，可以执行 redis-cli shutdown 命令，然后到安装的时候设置的持久化存放文件位置/var/redis/6379 可以查看到持久化的文件（注意：如果是使用kill -9 的方式直接杀掉进程，缓存中的数据没有满足 save 配置的要求，rdb快照文件可能是不存在的，因为还没有写入文件，redis-cli shutdown 执行这个命令会触发不管有没有满足，都会把缓存中的数据持久化。）
冷备份方案
正常情况下，redis宕机或者其他原因导致机器停止工作，重启后都会通过AOF持久化文件来恢复缓存中的数据。做备份处理的目的：特殊情况导致刚好rdb和aof两个持久化文件丢失或者损坏无法正常使用，那么就需要通过冷备份的rdb文件来恢复缓存中的数据。因为这种情况需要快速恢复缓存中的数据，所以RDB 非常适合做冷备，每次生成之后，就不会再有修改了。
数据备份方案：写 crontab 定时调度脚本去做数据备份
- 小时级：每小时都 copy 一份 rdb 的备份，到一个目录中去，仅仅保留最近 48 小时的备份。
- 日级：每天都保留一份当日的 rdb 的备份，到一个目录中去，仅仅保留最近 1 个月的备份，每天晚上将当前服务器上所有的数据备份，发送一份到远程的云服务上去。
数据冷备份需要使用脚本来完成
创建相关目录：
mkdir /usr/local/redis/snapshotting
mkdir /usr/local/redis/copy按小时级备份:
1、备份脚本
vi copy/redis_rdb_copy_hourly.sh
#!/bin/sh
# 生成文件夹名称 2020070810
cur_date=`date +%Y%m%d%k`
# 以防万一，先删除，再创建目录
rm -rf /usr/local/redis/snapshotting/$cur_date
# -p 可以创建多级目录
mkdir -p /usr/local/redis/snapshotting/$cur_date
cp /var/redis/6379/dump.rdb /usr/local/redis/snapshotting/$cur_date
# 生成 48 小时前的目录 2020070610
del_date=`date -d -48hour +%Y%m%d%k`
rm -rf /usr/local/redis/snapshotting/$del_date
2、定时操作脚本
# 该命令打开的是一个列表，有多条调度任务就一行一个
crontab -e
# 每/周日时分 0 秒，也就是每小时执行一次该脚本
0 * * * * sh /usr/local/redis/copy/redis_rdb_copy_hourly.sh按天备份也是如此，与前面的脚本一样，只是时间表达式不一样
vi copy/redis_rdb_copy_daily.sh
#!/bin/sh
# 生成文件夹名称 20210707
cur_date=`date +%Y%m%d`
# 以防万一，先删除，再创建目录
rm -rf /usr/local/redis/snapshotting/$cur_date
# -p 可以创建多级目录
mkdir -p /usr/local/redis/snapshotting/$cur_date
cp /var/redis/6379/dump.rdb /usr/local/redis/snapshotting/$cur_date
# 生成 一个月前的文件夹
del_date=`date -d -1month +%Y%m%d`
rm -rf /usr/local/redis/snapshotting/$del_date
# 该命令打开的是一个列表，有多条调度任务就一行一个
crontab -e
# 每/周日时分 0 秒，也就是每小时执行一次该脚本
0 * * * * sh /usr/local/redis/copy/redis_rdb_copy_hourly.sh
0 0 * * * sh /usr/local/redis/copy/redis_rdb_copy_daily.sh特别注意的是用rdb冷备恢复数据因为也启用aof备份恢复的原因，重启redis会优先给予aof文件恢复，虽然删除了appendonly.aof，但是因为打开了aof持久化，redis就一定会优先基于aof去恢复，即使文件不在，那就创建一个新的空的aof文件。
如何在数据安全丢失的情况下，基于rdb冷备，如何完美的恢复数据，同时还保持aof和rdb的双开？
- 停止redis，conf配置文件关闭aof（appendonly no），拷贝rdb备份，重启redis，确认数据恢复，直接在命令行热修改redis配置，打开aof，这个redis就会将内存中的数据对应的日志，写入aof文件中。此时aof和rdb两份数据文件的数据就同步了。
- redis config set热修改配置参数，可能配置文件中的实际的参数没有被持久化的修改，再次停止redis，手动修改配置文件，打开aof的命令，再次重启redisredis-cli
config get appendnoly
config set appendonly yes- 最后这个时候，conf文件的aof配置还是no,这个时候，再安全关停一下redis ，在再改成 appendonly yes，启动redis。
