文章目录
Redis配置文件分析
1、Unit单位对大小写不敏感，比如1GB、1gb两者一样
2、可以包含其他配置文件
3、网络方面
bind 127.0.0.1
protected-mode yes #保护模式
port 6379
4、
以守护进程方式运行（后台运行）
daemonize yes
指定了进程文件
pidfile /www/server/redis/redis.pid
5、日志相关
日志级别
日志文件的位置
6、
数据库个数
databases 16
always-show-logo yes #是否总是显示LOGO
7、
持久化，在规定的时间内，执行了多少次操作，则会持久化到文件.rdb.aof
#如果900s内，至少有一个key进行了修改，就及时进行持久化操作
save 900 1
#如果300s内，至少有10个key进行了修改，就及时进行持久化操作
save 300 10
#如果60s内，至少有10000个key进行了修改，就及时进行持久化操作
save 60 10000
stop-writes-on-bgsave-error yes #持久化如果出错，默认继续工作
rdbcompression yes #是否压缩rdb文件
rdbchecksum yes #保存rdb文件时进行错误的检查校验
dir /www/server/redis/ #rdb文件保存的目录
8、可以在SECURITY模块里设置密码
也可以通过命令
config get requirepass #获取redis密码
config set requirepass “123456” #设置redis的密码
auth 123456 #使用密码登录
9、
设置能连上redis的最大客户端数量
maxclients 10000
maxmemory <bytes> #redis配置最大的内存容量
maxmemory-policy noeviction #内存达到上限之后的处理策略
maxmemory-policy 六种方式
1、volatile-lru：只对设置了过期时间的key进行LRU（默认值）
2、allkeys-lru ： 删除lru算法的key
3、volatile-random：随机删除即将过期key
4、allkeys-random：随机删除
5、volatile-ttl ： 删除即将过期的
6、noeviction ： 永不过期，返回错误
10、aof配置（另一种持久化）
appendonly no #默认不开启，用rdb就够了
appendfilename "appendonly.aof" #持久化的文件名字
三种同步
# appendfsync always #每次修改都会同步
appendfsync everysec #每秒执行一次同步
# appendfsync no #不执行同步，让操作系统自己执行同步，速度最快
Redis持久化
Redis提供了两种不同的持久化方法来将数据存储到硬盘里，一种方法叫快照（RDB），它可以将存在于某一时刻的所有数据都写入硬盘里面。另一种方法叫只追加文件（AOF），它会在执行写命令时，将被执行的写命令复制到硬盘里面。
RDB操作
RDB操作会生成dump.rdb文件，并存储在dir选项指定的路径
如果在新的快照文件创建完毕之前，Redis、系统或者硬件三者中的任意一个崩溃，那么Redis将丢失最近一次创建快照之后写入的所有数据
举个例子
假设Redis目前在内存里面存储了一定的数据，上一个快照是在下午2：35开始创建的，并且已经创建成功。下午3：06开始创建新的快照，并且在下午3：08快照文件创建完毕之前，有35个键进行了更新。如果在3：06至3：08之间系统发生崩溃，导致Redis无法完成新的快照创建，那么Redis将丢失下午2：35之后写入的所有数据。另一方面，如果系统恰好在新的快照文件创建完毕后崩溃，那么Redis只会丢失35个键的更新数据
触发方式
1、save触发方式
该命令会阻塞当前Redis服务器，执行save命令期间，Redis不能处理其他命令，直到RDB过程完成为止。执行完成时候如果存在老的RDB文件，就把新的替代掉旧的。我们的客户端可能都是几万或者是几十万，这种方式显然不可取。
2、bgsave触发方式
执行该命令时，Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。具体操作是Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短。基本上 Redis 内部所有的RDB操作都是采用 bgsave 命令。
3、自动触发
自动触发是由我们的配置文件来完成的。在redis.conf配置文件中，相关配置见Redis配置文件详解第7点
触发机制
1、save的规则满足的情况下，会自动触发RDB规则
2、执行flushall命令也会触发
3、退出redis也会触发
如何恢复rdb文件
只需将rdb文件放在redis启动目录，redis启动时自动扫描
查看目录的方法：
127.0.0.1:6379> config get dir
1) "dir"
2) "/www/server/redis"
优点：
1、适合大规模的数据规模
2、对数据的完整性要求不高
缺点：
1、需要一定的时间间隔进程操作，如果redis意外宕机了，最后一次修改的数据就没有了
2、fork进程的时候，会占用一定的内容空间
AOF操作
将所有的命令都记录下来，恢复的时候就把这个文件全部执行一遍
通俗的理解就是日志记录。以日志的形式来记录每个写操作，将Redis执行过的所有指令记录下来（读操作不记录），只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，即redis重启的话就根据日志文件的内容将写指令从前到候执行一次以完成数据的恢复，AOF保存的是appendonly.aof文件
文件重写原理
AOF会导致持久化文件变得越来越大。为了压缩aof的持久化文件。redis提供了bgrewriteaof命令。将内存中的数据以命令的方式保存到临时文件中，同时会fork出一条新进程来将文件重写。
重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。
开启AOF需要操作配置文件
appendonly yes
将默认的no改为yes，重启redis就生效
如果.aof文件有错误，redis会开启失败，客户端会无法连接，需要使用命令修复
redis-check-aof --fix
AOF也有三种触发机制
（1）每修改同步always：同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好
（2）每秒同步everysec：异步操作，每秒记录 如果一秒内宕机，有数据丢失
（3）不同no：从不同步
AOF的默认是每秒同步一次
appendfsync everysec
优点：
1、每一次修改都同步，文件的完整性会更好
2、每秒同步一次，最多会丢失一秒的数据
3、AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。
缺点：
1、相对于数据文件来说，aof远远大于rdb，修复的速度也比rdb慢
2、以前AOF发生过bug，就是通过AOF记录的日志，进行数据恢复的时候，没有恢复一模一样的数据出来。
参考
Redis实战
https://baijiahao.baidu.com/s?id=1654694618189745916&wfr=spider&for=pc
https://www.bilibili.com/video/BV1S54y1R7SB