一、Redis配置文件详解

注意这是Redis服务本身的配置文件，相当于maven的settings.xml，而不是我们在springboot去配置Redis的那个application.yml。

========================核心部分======================

include 引入其他redis配置文件，相当于spring的<import>

bind 设置IP，默认是127.0.0.1

protected-mode yes  是否开启保护模式，默认开启

daemonize yes 是否以守护进程方式运行redis，默认是no，我们将其改为yes

pidfile /../../..pid  既然是守护进程，就指定这个守护进程的pid文件

loglevel  日志级别，有好多种日志级别

logfile 指定日志文件的位置

databases 16  默认数据库16个

always-show-logo yes  这个很有意思，就是开启redis服务的时候会不会打印图标（和springboot的那个图标一回事）

==============SNAPSHOP快照部分（用于RDB持久化的配置）===============
save 900 1

save 60 10000 设置多长时间、多少次修改持久化一次，60s内修改1万次进行一次持久化

stop-writes-on-bgsave-error yes 持久化出错后，是否继续工作

rdbcompression yes 是否要压缩rdb文件，默认是压缩

rdbchecksum yes 保存rdb文件的时候是否检查文件错误

dir ./  rdb文件和aof文件的保存目录（RDB和AOF保存在相同目录下，都通过dir指定）

===============REPLICATION主从复制用到的配置=======================
下次再讲


========================SECURITY安全配置========================
requirepass 123456 设置密码

=====================CLIENT 对客户端的限制（不用动，了解即可）=======
maxclients 10000  最多可以连接redis-server的客户端数量

maxmemory  redis的最大运行内存

maxmemory-policy redis要超过最大运行内存了怎么办？同JUC的6个策略（1-6从谨慎到发疯）
                                   # 1. noeviction 一个都不能删，直接返回redis运行内存不够了这个错误
                                   # 2. volatile-lru 只对设置了过期时间的key进行LRU
                                   # 3. allkeys-lru 对所有 key进行LRU
                                   # 4. valatile-ttl 删除即将过期的key
                                   # 5. volatile-random 随机删除即将过期的key
                                   # 6. allkeys-random 随机删除key  
=================APPEND ONLY AOF持久化配置================
appendoNly no 默认不开启AOF持久化，默认使用RDB方式持久化，因为RDB在大部分情况下就够用了

appendfilename AOF持久化文件名

appendfsync always/everysec/no  # 每次修改都sync，消耗性能/每秒一次sync,可能会丢失这1s的数据/不执行sync,这个时候操作系统自己同步数据，速度最快

在redis中查看密码的命令：

bash 复制代码

cj:0>config  get requirepass
1) "requirepass"
2) "CsiFlow!@#680"

二、持久化

PS :RBD类比~，AOF可以类比mysql的binlog去看

持久化的原因：

redis必须持久化吗？对啊！redis是内存数据库，不持久化的话断电即失！但"断电"这只是redis需要持久化的其中一个原因。一共有两个原因：

重用数据（比如重启机器、机器故障之后恢复数据）
或者是为了做数据同步（比如 Redis 集群的主从节点通过 RDB 文件同步数据）

3 种持久化方式:

Redis 不同于 Memcached 的很重要一点就是，Redis 支持持久化，而且支持

快照（snapshotting，RDB）
只追加文件（append-only file, AOF）
RDB 和 AOF 的混合持久化(Redis 4.0 新增)

2.1 RDB 持久化

Redis 可以通过创建快照来获得存储在内存里面的数据在 某个时间点 上的副本 。Redis 创建快照之后，可以
- 将快照复制到主从结构其他服务器从而创建具有相同数据的服务器副本
- 将快照留在原地以便重启服务器的时候使用。
RDB持久化的过程跟浏览器下载文件的过程一样，先在dir指定的路径下创建一个dump.rdb文件，往里写入数据，写完后替换上次的dump.rdb文件。
持久化了以后怎么用？全自动的！只要dump.rdb文件放在redis开启目录下，redis每次开启时都会开机自检核对数据
持久化是 Redis 默认采用的持久化方式，在 redis.conf 配置文件中默认有此下配置（不用改，默认的就很好用）：

save 900 1 #在900秒(15分钟)之后，如果至少有1个key发生变化，Redis就会自动触发bgsave命令创建快照。

save 300 10 #在300秒(5分钟)之后，如果至少有10个key发生变化，Redis就会自动触发bgsave命令创建快照。

save 60 10000 #在60秒(1分钟)之后，如果至少有10000个key发生变化，Redis就会自动触发bgsave命令创建快照。

1、触发RDB的时机

上面save设置了触发RDB的时机，但这并不是全部的时机。

flushdb、flushall命令会自动触发RDB
满足上面save规定
关掉redis时

2、RDB 创建快照时会阻塞主线程吗？

redis是单线程的，但是在进行持久化的时候会fork一个子线程/子进程，专门进行持久化操作，主线程照样运行其他命令。

Redis 提供了两个命令来生成 RDB 快照文件：

save : 同步保存操作，会阻塞 Redis 主线程；
bgsave : fork 出一个子进程/线程，子进程执行，不会阻塞 Redis 主线程，默认选项。

2.2 AOF 持久化

只记录写命令，不记录读命令，和binlog一样。恢复数据的时候把所有命令都执行一遍
过 appendonly yes参数开启，其他配置都不用动
文件名：appendonly.aof

2.3 二者的选择与比较

能说出这仨点即可

**RDB运行效率更高，**所以RDB是redis默认开启的，AOF默认不开启
AOF的安全性更高。但是效率是牺牲数据的实时性带来的，AOF可以用sync命令去设置每次修改都同步，或者每秒同步，但是RDB只能用save命令设置多少秒同步，不能精确到每一条命令。试想我们设置一个save 60 10000,60s内发生一万次修改的时候持久化到硬盘，但是如果还没到60s，发生第9999次修改后宕机了，那这9999次修改就丢失了。但AOF也不是完全安全的哦，因为AOF默认开始的是每秒同步，但是如果这1秒没来及同步就宕机了，就会丢失这1秒的数据。当然如果你开启每条命令同步，那就是绝对安全的了。
RDB恢复速度更快。RDB存储的是数据库快照，而AOF就和mysql的binlog一样，存储的是一条条执行过的命令。如果要恢复大规模数据，RDB直接拷贝快照，但是AOF要一条条执行命令，你想想哪个快？

2.4 rdb或aof文件被破坏怎么办？

aof文件是可以打开的，比如说我们打开文件以后，往里面随便敲点东西。那么下次redis开机会直接开不了

解决：调用redis提供的redis-check-aof工具修复aof文件。

综上：

如果Redis 保存的数据丢失一些也没什么影响的话，可以选择使用只用RDB。
不建议单独使用 AOF，因为RDB确实牛哇！时不时地创建一个 RDB 快照可以进行数据库备份、更快的重启以及解决 AOF 引擎错误。
如果企业对保存的数据要求安全性比较高的话，建议同时开启 RDB 和 AOF 持久化或者开启 RDB 和 AOF 混合持久化

所以，要么单独使用RDB，要么使用RDB+AOF，要么使用混合策略，就是不能单独使用AOF！

三、Redis发布订阅

底层如何实现发布订阅逻辑：redis是用C语言写的，发布与订阅的功能在pubsub.c这个文件里，想看源码的可以去看。

三个命令：

subscribe 频道名
publish 频道名
unsubscribe 频道名

应用场景：

redis的消息中间件功能只用于简单场景，复杂场景的话我们用rocketMQ，卡夫卡这种专业的消息中间件去做。

除了推送公众号这种显而易见的发布订阅，聊天室可以用redis实现吗？

可以！管理者（我自己瞎起的名字）作为发布者，所有聊天室的人作为订阅者。要想做到每一个发送的聊天信息都能被所有人收到，那就要先发给管理者，然后由管理者推送给所有订阅者。就是多了先"发给管理者"这一步而已

四、Redis主从复制

4.1 集群搭建

和docker"数据卷容器"实现多个容器之间的数据同步，"通过docker run --volumes-from docker01挂载了docker01，那么docker01就是docker02的父容器"的思想是一样的。

https://blog.csdn.net/qq_44886213/article/details/127844443https://blog.csdn.net/qq_44886213/article/details/127844443

五、宕机后手动配置主机

哨兵模式

缓存穿透和雪崩

Redis（五）—— Redis进阶部分