Redis配置文件详解，包括网络、通用、SNAPSHOT快照、复制、安全性、客户端限制等设置。讨论了RDB和AOF两种持久化策略的优缺点，以及如何进行数据恢复。介绍了Redis发布订阅、主从复制的工作原理和配置，以及哨兵模式在主节点故障时的角色切换和自动恢复功能。此外，提到了缓存穿透、缓存击穿和缓存雪崩的问题及解决方案。
Redis.conf详解
启动的时候就是通过配置文件来启动的！
行家有没有，出手就知道！
单位
1、配置文件unit单位对大小写不敏感
包含
网络
bind 127.0.0.1
protect-mode yes
port 6379 #端口
通用
daemonize yes #以守护进程的方式运行，默认是no
pidfile /var/run/redis_6379.pid #如果以后台方式运行，我们就需要指定一个pid文件
#日志
logfile "" #日志文件的位置名
databases 16
always-show-logo yes
SNAPSHOT 快照
持久化，在规定的时间内，执行了多少次操作，则会持久化到文件 .rdb .aof
redis是内存数据库，断断电即失，所以需要持久化到本地
# 如果900s内，如果至少有1个key进行了需改，我们就进行持久化操作
sava 900 1
# 如果300s内，如果至少有10个key进行了需改，我们就进行持久化操作
sava 300 10
# 如果60s内，如果至少有10000个key进行了需改，我们就进行持久化操作
sava 60 10000
stop-writes-on-bgsava-error yes #持久化出错，是否还继续工作
rdbcompression yes #是否压缩rdb文件，会损耗寻功能
rdbchecksum yes #保存rdb文件的时候，进行错误的检查校验
dir ./ # rdb文件保存的目录
REPLICATION 复制，在主从复制中讲
SECURITY
可以设置密码，默认没有密码
config get requirepass
config set requirepass
auth + 密码
限制 CLIENT
maxclients 10000 #最大客户端的数量
maxmemory <bytes> #redis配置最大内存容量
maxmemory-policy #内存达到容量后的处理策略
APPEND ONLY模式 aof配置
appendonly no #默认是关闭的，使用rdb方式持久化，大部分情况，rdb够用了
appendfilename "appendonly.aof" #持久化文件的名字
appendfsync #什么时候同步
Redis持久化
内存数据库，就会有持久化的操作。
RDB
什么是rdb
默认采用rdb进行持久化！
rdb保存的文件 就是dump.rdb 可配置
sava命令，保存配置文件并生效
触发机制
1、save规则满足的情况
2、执行flushall命令，会触发save规则
3、退出redis，也会产生rdb文件
恢复rdb文件
1、只需要将rdb文件放在redis的启动目录就可以，redis启动就会自动检查dump.rdb，去恢复数据
2、查看需要存放的位置
config get dir
rdb几乎默认的配置就够用了
优点：
1、适合大规模的数据恢复
2、如果对数据完整性要求不高
缺点：
1、需要一定的时间间隔进行操作，如果redis意外宕机了，最后一次修改的数据就没了
AOF
将所有命令记录下来，history，恢复的时候就把这个文件全部执行一遍！
是什么
以日志的形式来记录每个修改命令，将redis所有的指令记录下来（读操作不记录），只追加但不改写文件，redis启动之初会读取文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令全部重新执行一遍完成数据的恢复。
append 配置
默认不开启，需要我们手动开启！我们只需要将appendonly改为yes
appendonly.aof文件可能被破坏，此时redis将无法启动，可以用redis-check-aof --fix appendonly.aof修复文件，``redis-check-aof `这是官方提供的一个工具
文件重写规则
aof默认是文件的无限制追加
文件太大了就会触发重写己制
优点和缺点
优点：
1、每一次修改都同步，文件的完整性会更好
2、默认开启没秒同步一起，可能会丢弃1s的数据
3、从不同步效率最高
缺点：
1、相对于数据文件来说，aof远远大于rdb，修复速度比rdb慢
2、aof运行效率比rdb慢
Redis发布订阅
Redis发布订阅是一种消息通信模式：发布者发送消息，订阅者接收消息。微博、微信、关注系统
第一个：消息发送者，第二个：频道，第三个：消息订阅者
命令
测试
subscribe kuangshenshuo
#新开一个客户端：发消息
publish kuangshenshuo "hello everyone"
订阅端：
127.0.0.1:10002> SUBSCRIBE iwat
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "iwat"
3) (integer) 1
1) "message"
2) "iwat"
3) "hello everyone"
发送端：
127.0.0.1:10002> PUBLISH iwat "hello everyone"
(integer) 1
原理
使用场景：
1、实时消息系统
2、实时聊天
3、订阅，关注系统
Redis主从复制
原理
主从复制，读写分离！80%的情况都是在进行读操作！
单台redis容量达到20G，就应该考虑集群了
只要在公司
环境配置
只配置从库，不配置主库
# 查看当前库的节点信息
# info replication
127.0.0.1:10002> info replication
# Replication
role:master
connected_slaves:0
master_replid:2d0b316b2b7811a0dee43fefd21ba2c3ad6e9607
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
复制3个配置文件，然后修改对应的信息
- 端口
- pid文件名字：
- log文件名字：
- rdb文件：只能修改名字，不能修改位置
修改完毕就可以启动了
注意：如果主机设计了密码，那么在从机的配置文件中需要修改配置
默认情况都是主节点：一般情况只配置从机就行了
认老大！一主（02）二从（04，05）
# slaveof <主机> <ip> 意思时变成谁的从机
127.0.0.1:10002> info replication
# Replication
role:master #主机
connected_slaves:0 #从机数量
master_replid:2d0b316b2b7811a0dee43fefd21ba2c3ad6e9607
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
#从机1
127.0.0.1:10004> SLAVEOF 127.0.0.1 10002
OK
127.0.0.1:10004> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:10002
master_link_status:up #主机在线
master_last_io_seconds_ago:2
master_sync_in_progress:0
slave_repl_offset:0
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:430b6bc8cac4b404011732f1027ef75ca1657ffa
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:0
#从机2
127.0.0.1:10005> SLAVEOF 127.0.0.1 10002
OK
127.0.0.1:10005> INFO replication
# Replication
role:slave #从机
master_host:127.0.0.1
master_port:10002
master_link_status:down #主机没有在线，就是没连上，因为没有配置主机密码
master_last_io_seconds_ago:-1
master_sync_in_progress:0
slave_repl_offset:1
master_link_down_since_seconds:1625465904
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:fd3cb80a16c3c31a2fb4c38f8002dbdb6b7dfb40
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
# 主机
127.0.0.1:10002> info replication
# Replication
role:master
connected_slaves:1 #目前显示一个从机，下面一行时从机信息
slave0:ip=127.0.0.1,port=10004,state=online,offset=126,lag=1
master_replid:430b6bc8cac4b404011732f1027ef75ca1657ffa
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:126
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:126
这里是通过命令配置，这样修改时暂时。但真实的要通过修改配置文件
细节
主机可以写，从机只能读！主机中所有的数据都会被从机保存
当主机断掉之后，从机不会受影响，但是由于主机断掉，写操作无法执行了。如果主机回来了，从机依旧可以读取新写入的元素。就是说即使主机断了，主从机连接依旧保持着。
如果使用命令行配置的从机，如果从机重启服务，就会变回主机，就无法拿到主机写入的数据了。但是只要变成了从机，数据就会被立刻被复制到从机。
# 主机写入
127.0.0.1:10002> flushdb
OK
127.0.0.1:10002> keys *
(empty array)
127.0.0.1:10002> set k1 v1
OK
#从机读取
127.0.0.1:10004> get k1
"v1"
127.0.0.1:10004> set k2 v2
(error) READONLY You can't write against a read only replica. #从机不可写入
复制原理
层层链路，第二种主从复制结构
从节点，又有从节点。但即使主机宕机后，从机也还是从机！
如果没有老大了 这个时候能不能选一个老大出来了？手动配置
salveof no one #不当从机了
哨兵模式（老大去世后自动选取老大）
概述
主机宕机后，自动根据规则选取从机使之变成老大
基本模型
多哨兵模式
测试
1、配置哨兵，哨兵的配置文件：sentinel.conf
# myredis 主机名称 随便取
# 1 主机挂了后，让从机投票看让谁解题成为主机
sentinel monitor mymaster 127.0.0.1 10002 1
port 10006
sentinel auth-pass mymaster 1804903555 #主机从机的密码要一致，以便可以实现几个主机连续宕机，可以继续切换主机
2、启动sentinel服务
redis-sentinel myconf/sentinel.conf
出现如下图所示，就说明哨兵服务就启动了
3、主关闭主机redis服务，模拟宕机。过一会，哨兵服务的控制太会有如下输出
4、恢复原主机
主机挂了之后又回来了，它就成从机了
没有配置主机密码，所以没能连上主机、、、
哨兵模式
优点：
1、哨兵集群，基于主从复制
2、主从可以切换，故障可以转移，高可用
3、手动主从复制的升级，手动到自动
缺点：
1、redis不好在线扩容，集群容量如果达到上限
2、配置比较麻烦
# 哨兵配置文件详解
port 26381
pidfile "/var/run/redis-sentinel-26381.pid"
logfile "/var/log/redis/redis-sentinel-26381.log"
sentinel monitor mymaster 11.11.11.11 6379 2 #主节点别名为mymaster，后面是ip和端口，2代表判断主节点失败至少需要2个sentinel节点同意
sentinel auth-pass mymaster 123456
sentinel down-after-milliseconds mymaster 30000 #主节点故障30秒后启用新的主节点
sentinel parallel-syncs mymaster 1 #故障转移时最多可以有1个从节点同时对主节点进行数据同步，数字越大，用时越短，存在网络和 IO 开销
sentinel failover-timeout mymaster 180000 #故障转移超时时间180s：a 如果转移超时失败，下次转移时时间为之前的2倍；b 从节点变主节点时，从节点执行 slaveof no one 命令一直失败的话，当时间超过180S时，则故障转移失败；c 从节点复制新主节点时间超过180S转移失败
Redis缓存穿透和雪崩
缓存穿透（查不到）
概念
解决方案
布隆过滤器
缓存空对象
缓存击穿（量太大，空档期）
概述
解决方案
1、热点数据永不过期
2、加锁，很多人要访问一个资源，给资源加一个锁，就只能有一个访问
缓存雪崩
概念
解决方案
扫一扫
4843
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
