redis笔记——持久化，主从、哨兵、缓存穿透和雪崩

不不爱写博客

于 2023-04-25 18:25:33 发布

阅读量479

点赞数

分类专栏：笔记文章标签：缓存 redis 笔记

本文链接：https://blog.csdn.net/qq_31240423/article/details/130371265

版权

笔记专栏收录该内容

46 篇文章 1 订阅

订阅专栏

redis.conf配置文件

大小写不敏感，并且k和kb单位指定的内存大小不一样

# Note on units: when memory size is needed, it is possible to specify
# it in the usual form of 1k 5GB 4M and so forth:
#
# 1k => 1000 bytes
# 1kb => 1024 bytes
# 1m => 1000000 bytes
# 1mb => 1024*1024 bytes
# 1g => 1000000000 bytes
# 1gb => 1024*1024*1024 bytes
#
# units are case insensitive so 1GB 1Gb 1gB are all the same.

可以包含其他的配置文件

# include /path/to/local.conf
# include /path/to/other.conf

网络配置

绑定可访问ip地址，需要远程连接则需要改动这里的ip地址，可以指定ipv4地址也可以同时指定ipv6地址
```
bind 127.0.0.1 -::1
```
保护模式，一般情况下开启，只有需要别的主机能够连接到Reids时候会关闭
```
protected-mode yes
```
端口
```
port 6379
```

通用配置

以守护进程的方式运行，默认为no，需要开启redis挂在后台就设置为yes

daemonize no

指定进程文件，如果使用守护进程的方式运行，则需要指定一个pid文件

pidfile /var/run/redis_6379.pid

设置日志级别

# Specify the server verbosity level.
# This can be one of:
# debug (a lot of information, useful for development/testing)
# verbose (many rarely useful info, but not a mess like the debug level)
# notice (moderately verbose, what you want in production probably)
# warning (only very important / critical messages are logged)
loglevel notice

指定日志输出文件

logfile ""

设置数据库数量和服务开启时是否显示logo

databases 16

always-show-logo no

快照设置

redis中快照也就是持久化，设置在多长时间内执行了多少次操作就将内存中的数据持久化到.rdb或.aof文件中

以下例子表示在3600秒内至少有一个key被操作就进行持久化，300秒内至少100key，60秒内至少10000key
```
# save 3600 1
# save 300 100
# save 60 10000
```
持久化出错是否让redis继续工作，yes表示继续工作
```
stop-writes-on-bgsave-error yes
```
是否压缩rdb文件，压缩会消耗cpu资源
```
rdbcompression yes
```
保存rdb文件时，进行错误校验，错误会自动修复
```
rdbchecksum yes
```
保存的rdb文件名和目录
```
dbfilename dump.rdb
dir ./
```
REPLICATION 复制配置

SECURITY安全配置

设置密码，我们可以通过配置文件来设置密码，也可以通过命令行的方式来设置，一般通过命令行的方式更多一点

修改配置文件
# requirepass 密码
命令行方式
config set requirepass "123456" #设置密码
auth 123456  #登陆到redis，认证密码
config get requirepass  #获取配置文件中的内容

CLIENTS客户端配置

设置最大客户端连接数

maxclients 10000

配置redis最大内存

maxmemory <bytes>

配置reids内存达到上限之后的处理策略

maxmemory-policy noeviction

#六种过期策略方式
noeviction：不淘汰任何数据，当内存不足时，执行缓存新增操作会报错，这种策略下可以保证数据不丢失，它也是 Redis 默认的内存淘汰策略。
allkeys-lru：淘汰整个键值中最久未使用的键值，这也就是我们常说的LRU算法。
allkeys-random：随机淘汰任意键值。
volatile-lru：淘汰所有设置了过期时间的键值中最久未使用的键值。
volatile-random：随机淘汰设置了过期时间的任意键值。
volatile-ttl：优先淘汰设置了过期时间中更早过期的键值。

APPEND ONLY MODE 也就说aof持久化配置

默认不开启aof持久化方式，大部分情况下，使用rdb就够用了

appendonly no

持久化文件名

appendfilename "appendonly.aof"

配置同步频率

# appendfsync always  #每次修改都进行同步，消耗性能
appendfsync everysec  #每秒执行一次同步，可能会造成数据丢失
# appendfsync no # 不执行同步，操作系统自己会同步数据，速度最快

Redis持久化

redis是基于内存的数据库，如果发生了什么意外情况，导致进程退出或者服务器退出，数据库中的所有数据就会丢失，所以redis也提供了将内存中的数据持久化的功能

RDB（Redis DataBase）

rdb持久化机制，会在指定的时间内将内存中的数据集快照写入磁盘（Snapshot快照），rdb模式下恢复是将快照文件直接读取到内存中。

机制

redis会单独创建一个子进程来进行持久化操作，主进程继续处理来自客户端的请求并且不会进行任何的IO操作以保证子进程能够有很高的性能处理持久化，子进程首先会将内存中的数据写入到一个临时的快照文件中，这个过程就是持久化，等到这个过程结束，会把这个临时文件替换掉上一次持久化产生的文件，到此整个rdb持久化结束。rdb模式下保存的持久化文件为dump.rdb

测试

redis持久化是自动进行的，我们测试需要修改配置文件中的save。并且在规定时间内操作规定数量的key来触发rdb持久化。也可以是手动进行持久化，客户端中执行save即可生成持久化文件，但是save是阻塞的，它会让redis服务器停止接受任何来自客户端的请求，直到持久化过程结束

触发机制

正常关机执行shutdowm，服务器会自动执行save命令，会产生持久化文件
flushall会产生持久化文件
在规定时间内操作规定数量的key

恢复机制

redis会自动检测当前目录下rdb文件，启动时会自动将rdb文件中的数据恢复进数据库

优点

大规模数据恢复

对数据完整性要求不高

缺点

需要一定时间进行持久化操作，如果服务器意外宕机，会丢失最后一次修改的数据

开子进程持久化，会消耗内存

AOF（Append Only File）

开启aof持久化会将我们所有的命令记录下来，恢复就是将我们所有执行过的命令在执行一遍

机制

aof持久化用日志的形式记录每个操作，将redis中所有的非读取数据的操作记录下来，保存到.aof文件中，并且之后的每一次持久化都只会向原本的这个文件追加数据，不会修改原有文件的值。恢复的时候读取该文件重新构建数据。重写：在.aof文件超过设置的文件最大容量（默认为64mb）之后会触发redis重写该文件，重写文件让文件的体积更小

测试

aof持久化是默认不开启的，我们需要手动开启，在配置文件中的appendonly 修改为yes即可。在同时开启aof和rdb持久化的情况下，redis会优先使用aof来恢复数据，因为aof比rdb更为精确

文件损坏修复

在启动redis时，会自动检测aof文件，如果文件损坏则会无法连接到redis服务器，这时候需要使用redis-check-aof来修复aof文件redis-check-aof --fix 目标文件

优点

文件完整性更好

缺点

aof体积远远大于rdb，修复的速度也比rdb慢
aof运行效率比rdb慢

Redis发布订阅

订阅一个频道

subscribe 频道名称

发布消息到频道

publish 频道名称 消息

主从复制

主从复制就是指在reids集群中，将一台redis服务器中的数据复制到其他reids服务器中，前者称为主节点（master/leader），后者被称为从节点（slave/follower）。主节点主要提供写服务，从节点提供读服务。并且数据都是从主节点流向从节点

作用

数据冗余：实现了数据的热备份
故障恢复：当主节点出问题，从节点可继续提供服务
负载均衡
高可用基石

单台redis服务器最大使用内存应该不超过20g

环境配置

搭建redis服务器集群只需要配置从库，不需要配置主库。每个redis服务器默认配置自己为主库

127.0.0.1:6379> info replication  #查看当前库的配置信息 
# Replication
role:master   #当前redis服务器的主从角色
connected_slaves:0   #连接它的从机数
master_failover_state:no-failover
master_replid:68f44949ca12e05e6e5402daa129cffb9adcb01e
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

搭建集群环境

打开四个linux连接，搭建一主二从集群，并且测试

多个redis服务器需要多个配置文件，这里首先做三个配置文件

[root@localhost bin]# cp redis.conf redis6379.conf
[root@localhost bin]# cp redis.conf redis6380.conf
[root@localhost bin]# cp redis.conf redis6381.conf

编辑第一个主机配置文件

设置端口为6379；设置守护进程为yes；配置日志文件名称为6379.log；配置rdb的持久化文件名dump6379.rdb
编辑第从机配置文件

设置端口为6380；开启守护进程，设置后台运行的pid文件redis_6380.pid（此文件需要跟随端口号的改变一起改变）；配置日志文件名logfile6380.log；配置持久化文件名dump6380.rdb。后续从机配置修改的地方相同

这里注意，使用了同一台服务器搭建了 redis集群，所以需要使用不同的端口号，在不同的服务器上搭建集群则不需要需改端口号
reids需要将配置文件中的保护模式关闭才能开启主从复制，也就是protected-mode设置为no，此项所有的redis服务都需要关闭
关闭了保护模式之后容易被攻击，所以建议设置认证密码requirepass 密码
如果redis服务配置了密码，那么需要到配置文件中修改主从认证密码：masterauth，否则主从不能同步，会一直显示从机或者主机为down(下线状态)，并且如果在redis服务开启的状态下修改密码，则需要修改密码后重启redis服务（也是从机的配置中需要设置masterauth认证密码为主机的登陆密码）

测试

在不同的linux会话中启动三个redis服务，并且通过指定端口的方式连接上不同的redis服务redis-cli -p 端口号

设置从机的主机

slaveof 主机地址 服务端口号

查看从机的主从信息

127.0.0.1:6380> slaveof 127.0.0.1 6379
OK
127.0.0.1:6380> info replication
# Replication
role:slave  #角色切换为了从机
master_host:127.0.0.1   #并且展示了主机的地址端口号等信息
master_port:6379
master_link_status:up
master_last_io_seconds_ago:4
master_sync_in_progress:0
slave_read_repl_offset:14
slave_repl_offset:14
slave_priority:100
slave_read_only:1
replica_announced:1
connected_slaves:0
master_failover_state:no-failover
master_replid:4ddb88ecde03b607471385559a8e376263270aa9
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:14
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:14

此时查看主机信息，已经可以看见从机信息了

127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:1   #从机数量变成了1，并且展示了从机信息
slave0:ip=127.0.0.1,port=6380,state=online,offset=126,lag=1
master_failover_state:no-failover
master_replid:4ddb88ecde03b607471385559a8e376263270aa9
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

slaveof no one 切换为主机

通过命令的方式配置主从是暂时性的，如果服务重新启动就会失效，通过配置文件配置的主从配置则是永久性质的，只要开启redis服务就会进入主从模式

配置自动进入主从模式需要找到replication模块下的这两处，取消注释并且配置对应的信息

# replicaof <masterip> <masterport>
# masterauth <master-password>

总结

在主从模式中，主机可以写操作，从机只能读取操作。主机中所有的信息和数据都会被从机保存。出现主从机数据集不一致的情况下，从机自动丢弃自身数据，并且在主机宕机之后，从机还是从机，只能提供读取服务
在主机断开连接的情况下，整个redis集群能够继续提供读取服务，主机连接回来之后仍旧可以进行主从复制
在从机断开连接的情况下，主机进行写操作，操作完毕之后从机重启成功，这时候使用命令行方式配置的主从复制此时拿不到主机中写入的值，重新配置主从复制之后可以拿到刚刚宕机时间段内主机写入的值

复制原理

slave成功连接到master后会发送一个sync命令
master接受到命令之后会收集所有修改过数据的命令，传送整个收集的命令的文件到slave，完成一次完全同步
slave收到数据库文件的数据之后会完整将数据加载到自己的内存数据库中（也称为全量复制）
matser将新的收到的修改数据的命令传递给salve（也称为增量复制）

哨兵模式（Sentinel）

在主从模式，如果主机宕机会造成一段时间的写服务不可用，并且需要手动切换所有的从节点的主机配置，这很麻烦，于是出现了哨兵模式来解决这个问题，当主机宕机之后，所有的哨兵会投票选举出新的主机

机制

哨兵模式会开启一个哨兵的独立进程，这个进程会通过发送命令的方式检测每个redis服务器是否存活。
当哨兵们选举出了新的主机之后，会通过发布订阅模式通知其他所有的从机修改配置文件

哨兵集群

那如果这个哨兵进程也宕机了呢，于是我们会配置一个哨兵集群，也就是多哨兵模式，哨兵们除了检测redis服务器之外还会相互检测，看对方是否活着

如果某一个哨兵检测到主机无法响应命令之后，此时无法判断主机是否真正宕机，因为可能是由于请求过多暂时无法响应哨兵的命令。此时会将主机标记为主观下线状态，其他的哨兵也会发送命令看主机是否响应，如果其他的哨兵也检测主机不可用并且数量到达一定值的时候，哨兵之间会选举出一个正常的哨兵出来发起投票，然后所有的存活的正常的哨兵进行一次投票选举出新的主机。选举出新的主机之后，哨兵会进行故障转移操作（也称为failover），通知被投票出来的从机切换到主机状态，并且通过发布订阅模式通知其他所有的从机切换到该主机，此时的旧主机被标记为客观下线状态

配置哨兵模式

在配置文件目录下新建哨兵配置文件sentinel.conf（这里进行简单配置，实现基本功能）

# matserRedis只是个名字可以随便起，后面的数字1代表启动投票
sentinel monitor masterRedis 127.0.0.1 6379 1

指定配置文件来启动哨兵，哨兵进程信息显示，监测到主机6379并且检测到两台从机6380和6381

[root@localhost bin]# redis-sentinel sentinel.conf 
29068:X 24 Apr 2023 19:17:48.562 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
29068:X 24 Apr 2023 19:17:48.563 # Redis version=7.0.10, bits=64, commit=00000000, modified=0, pid=29068, just started
29068:X 24 Apr 2023 19:17:48.563 # Configuration loaded
29068:X 24 Apr 2023 19:17:48.563 * Increased maximum number of open files to 10032 (it was originally set to 1024).
29068:X 24 Apr 2023 19:17:48.563 * monotonic clock: POSIX clock_gettime
                _._                                                  
           _.-``__ ''-._                                             
      _.-``    `.  `_.  ''-._           Redis 7.0.10 (00000000/0) 64 bit
  .-`` .-```.  ```\/    _.,_ ''-._                                  
 (    '      ,       .-`  | `,    )     Running in sentinel mode
 |`-._`-...-` __...-.``-._|'` _.-'|     Port: 26379
 |    `-._   `._    /     _.-'    |     PID: 29068
  `-._    `-._  `-./  _.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |           https://redis.io       
  `-._    `-._`-.__.-'_.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |                                  
  `-._    `-._`-.__.-'_.-'    _.-'                                   
      `-._    `-.__.-'    _.-'                                       
          `-._        _.-'                                           
              `-.__.-'                                               

29068:X 24 Apr 2023 19:17:48.567 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
29068:X 24 Apr 2023 19:17:48.569 * Sentinel new configuration saved on disk
29068:X 24 Apr 2023 19:17:48.569 # Sentinel ID is 2418da51dc523e9c4abc85ff5695b72ca218be82
29068:X 24 Apr 2023 19:17:48.569 # +monitor master masterRedis 127.0.0.1 6379 quorum 1
29068:X 24 Apr 2023 19:17:48.572 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ masterRedis 127.0.0.1 6379
29068:X 24 Apr 2023 19:17:48.573 * Sentinel new configuration saved on disk
29068:X 24 Apr 2023 19:17:48.573 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ masterRedis 127.0.0.1 6379
29068:X 24 Apr 2023 19:17:48.575 * Sentinel new configuration saved on disk

测试

关闭主机模拟主机宕机情况

127.0.0.1:6379> SHUTDOWN
(1.09s)
not connected> exit

查看从机6380的主从信息

127.0.0.1:6380> info replication
# Replication
role:master   #发现该从机已经被选举为主机并且6381也切换主机为该从机了
connected_slaves:1
slave0:ip=127.0.0.1,port=6381,state=online,offset=50255,lag=1
master_failover_state:no-failover
master_replid:fc5292ee0120b08edaace8ffa7d80549a617de74
master_replid2:4ddb88ecde03b607471385559a8e376263270aa9
master_repl_offset:50255
second_repl_offset:48437
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:50255

查看哨兵报告信息

29068:X 24 Apr 2023 19:20:32.771 # +sdown master masterRedis 127.0.0.1 6379
29068:X 24 Apr 2023 19:20:32.771 # +odown master masterRedis 127.0.0.1 6379 #quorum 1/1
29068:X 24 Apr 2023 19:20:32.771 # +new-epoch 1
29068:X 24 Apr 2023 19:20:32.771 # +try-failover master masterRedis 127.0.0.1 6379
29068:X 24 Apr 2023 19:20:32.775 * Sentinel new configuration saved on disk
29068:X 24 Apr 2023 19:20:32.775 # +vote-for-leader 2418da51dc523e9c4abc85ff5695b72ca218be82 1
29068:X 24 Apr 2023 19:20:32.775 # +elected-leader master masterRedis 127.0.0.1 6379
29068:X 24 Apr 2023 19:20:32.775 # +failover-state-select-slave master masterRedis 127.0.0.1 6379
29068:X 24 Apr 2023 19:20:32.860 # +selected-slave slave 127.0.0.1:6380 127.0.0.1 6380 @ masterRedis 127.0.0.1 6379
29068:X 24 Apr 2023 19:20:32.860 * +failover-state-send-slaveof-noone slave 127.0.0.1:6380 127.0.0.1 6380 @ masterRedis 127.0.0.1 6379
29068:X 24 Apr 2023 19:20:32.935 * +failover-state-wait-promotion slave 127.0.0.1:6380 127.0.0.1 6380 @ masterRedis 127.0.0.1 6379
29068:X 24 Apr 2023 19:20:33.040 * Sentinel new configuration saved on disk
29068:X 24 Apr 2023 19:20:33.040 # +promoted-slave slave 127.0.0.1:6380 127.0.0.1 6380 @ masterRedis 127.0.0.1 6379
29068:X 24 Apr 2023 19:20:33.040 # +failover-state-reconf-slaves master masterRedis 127.0.0.1 6379
29068:X 24 Apr 2023 19:20:33.100 * +slave-reconf-sent slave 127.0.0.1:6381 127.0.0.1 6381 @ masterRedis 127.0.0.1 6379
29068:X 24 Apr 2023 19:20:34.057 * +slave-reconf-inprog slave 127.0.0.1:6381 127.0.0.1 6381 @ masterRedis 127.0.0.1 6379
29068:X 24 Apr 2023 19:20:34.057 * +slave-reconf-done slave 127.0.0.1:6381 127.0.0.1 6381 @ masterRedis 127.0.0.1 6379
29068:X 24 Apr 2023 19:20:34.159 # +failover-end master masterRedis 127.0.0.1 6379
29068:X 24 Apr 2023 19:20:34.159 # +switch-master masterRedis 127.0.0.1 6379 127.0.0.1 6380
29068:X 24 Apr 2023 19:20:34.159 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ masterRedis 127.0.0.1 6380
29068:X 24 Apr 2023 19:20:34.159 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ masterRedis 127.0.0.1 6380
29068:X 24 Apr 2023 19:20:34.161 * Sentinel new configuration saved on disk
29068:X 24 Apr 2023 19:21:04.171 # +sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ masterRedis 127.0.0.1 6380

在已经选举出新的主机的情况下，旧主机连接回来，哨兵检测到旧主机的连接，会将旧主机设置为新主机的从机

优点

哨兵集群基于主从复制模式，继承了主从模式的所有优点
主从切换，故障转移，系统可用性更好
服务健壮性好

缺点

不好在线扩容，集群数量一旦达到上限，在线扩容就十分麻烦
哨兵模式配置复杂

哨兵模式配置文件选项

# Example sentinel.conf
# 哨兵sentinel实例运行的端口 默认26379
port 26379

# 哨兵sentinel的工作目录
dir /tmp

# 哨兵sentinel监控的redis主节点的 ip port
# master-name 可以自己命名的主节点名字 只能由字母A-z、数字0-9 、这三个字符".-_"组成。
# quorum 配置多少个sentinel哨兵统一认为master主节点失联 那么这时客观上认为主节点失联了
# sentinel monitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor mymaster 127.0.0.1 6379 2

# 当在Redis实例中开启了requirepass foobared 授权密码 这样所有连接Redis实例的客户端都要提供密码
# 设置哨兵sentinel 连接主从的密码 注意必须为主从设置一样的验证密码
# sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster MySUPER--secret-0123passw0rd

# 指定多少毫秒之后 主节点没有应答哨兵sentinel 此时 哨兵主观上认为主节点下线 默认30秒
# sentinel down-after-milliseconds <master-name> <milliseconds>
sentinel down-after-milliseconds mymaster 30000

# 这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行 同步，这个数字越小，完成failover所需的时间就越长，但是如果这个数字越大，就意味着越 多的slave因为replication而不可用。可以通过将这个值设为 1 来保证每次只有一个slave 处于不能处理命令请求的状态。
# sentinel parallel-syncs <master-name> <numslaves>
sentinel parallel-syncs mymaster 1

# 故障转移的超时时间 failover-timeout 可以用在以下这些方面：
#1. 同一个sentinel对同一个master两次failover之间的间隔时间。
#2. 当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的master那里同步数据时。
#3.当想要取消一个正在进行的failover所需要的时间。 
#4.当进行failover时，配置所有slaves指向新的master所需的最大时间。不过，即使过了这个超时，slaves依然会被正确配置为指向master，但是就不按parallel-syncs所配置的规则来了
# 默认三分钟
# sentinel failover-timeout <master-name> <milliseconds>
sentinel failover-timeout mymaster 180000

# SCRIPTS EXECUTION
#配置当某一事件发生时所需要执行的脚本，可以通过脚本来通知管理员，例如当系统运行不正常时发邮件通知相关人员。
#对于脚本的运行结果有以下规则：
#若脚本执行后返回1，那么该脚本稍后将会被再次执行，重复次数目前默认为10
#若脚本执行后返回2，或者比2更高的一个返回值，脚本将不会重复执行。
#如果脚本在执行过程中由于收到系统中断信号被终止了，则同返回值为1时的行为相同。
#一个脚本的最大执行时间为60s，如果超过这个时间，脚本将会被一个SIGKILL信号终止，之后重新执行。
#通知型脚本:当sentinel有任何警告级别的事件发生时（比如说redis实例的主观失效和客观失效等等），将会去调用这个脚本，这时这个脚本应该通过邮件，SMS等方式去通知系统管理员关于系统不正常运行的信息。调用该脚本时，将传给脚本两个参数，一个是事件的类型，一个是事件的描述。如果sentinel.conf配置文件中配置了这个脚本路径，那么必须保证这个脚本存在于这个路径，并且是可执行的，否则sentinel无法正常启动成功。

#通知脚本
# shell编程
# sentinel notification-script <master-name> <script-path>
sentinel notification-script mymaster /var/redis/notify.sh

# 客户端重新配置主节点参数脚本
# 当一个master由于failover而发生改变时，这个脚本将会被调用，通知相关的客户端关于master地址已经发生改变的信息。
# 以下参数将会在调用脚本时传给脚本:
# <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>
# 目前<state>总是“failover”,
# <role>是“leader”或者“observer”中的一个。
# 参数 from-ip, from-port, to-ip, to-port是用来和旧的master和新的master(即旧的slave)通信的
# 这个脚本应该是通用的，能被多次调用，不是针对性的。
# sentinel client-reconfig-script <master-name> <script-path>
sentinel client-reconfig-script mymaster /var/redis/reconfig.sh # 一般都是由运维来配置！

缓存穿透和雪崩

缓存穿透

用户想要查询一个数据，发现redis服务器中没有，于是请求就会走持久层数据库，这时候可能也发现没有，当用户数量非常多的时候，缓存没有命中，都走了持久层数据库，就会给持久层数据库带来很大的压力，就有可能造成数据库崩掉

也就说缓存并没有拦截到大部分的请求，这些请求直接走了底层数据库，这就叫缓存穿透

解决方案

布隆过滤器

过滤器层在缓存层之前，客户端想要获取redis的数据，先会经过一层布隆过滤器。布隆过滤器是一种数据结构，对所有可能的查询参数用hash的形式存储，在控制层先进行了校验，不符合规则会丢弃请求，避免了对底层存储系统造成查询压力

缓存空对象

当底层数据库也查不到对应的数据的的时候，返回空对象将其缓存起来，设置一个过期时间，之后的请求都会走redis缓存访问，保护底层数据库，但是会存在一些问题

如果一个空的值都能够被缓存起来，意味着redis需要更多的空间来存储键，并且这些键都是空值，毫无意义
虽然设置了空值的过期时间，但是这仍然会造成缓存和数据库会有一段时间的不一致，这对需要保持一致性的业务会有影响

缓存击穿

缓存击穿就先是大量的访问都集中在一个点上（也就是一个key上），大量并发访问集中对这一个点访问，当这个key失效的一瞬间，持续的大并发就会穿过缓存层直接请求底层数据库，导致底层数据库宕机。当某个key（一般都是热点数据）过期的时候，大量并发请求访问数据库查询最新的数据，并且持续对reids进行数据缓存

解决方案

设置热点数据永不过期

会浪费reids存储空间，并且redis达到内存上限自动清除数据库中部分的key的时候，不清楚是否会清除这部分热点数据

加互斥锁

使用分布式锁，保证在出现缓存无法命中的情况下，只有一个线程拿着锁去后端查询数据，没有拿到锁的其他线程就只能等待。这种方式将高并发的压力转移到了分布式锁中，于是对分布式锁的考验很大

缓存雪崩

缓存雪崩就是指，在某一个时间段，缓存集中过期失效。或者redis集群宕机。所有的请求都直接落在了底层数据库上。reids中的key集中过期都还不是最严重的。比较致命的雪崩是缓存服务器某个节点宕机或者断网。因为自然形成的缓存雪崩一定是在某个时间段内集体创建的缓存，才会导致key集体的在某一个时间段内失效，这个时候底层数据库也是可以承受的住压力的，只是这个情况下会对服务器数据库造成周期性的压力。但是对于缓存服务器节点宕机的这个情况对数据库服务器的压力是不可预知的。很有可能会把数据库压垮

解决方案

redis高可用

多增设redis服务器，只要服务器够多就不害怕整体服务会崩掉，本质上就是搭建集群，还可以采用异地多活

Redis异地多活是指在不同的地理位置上部署多个Redis节点，使得这些节点之间可以互相复制数据并保持同步，从而实现数据的高可用性和容灾性。在Redis异地多活架构中，每个节点都可以读写数据，同时还能将数据同步到其他节点，以保证数据的一致性和可靠性。当某个节点发生故障或网络中断时，其他节点可以接管服务并继续提供服务，从而保证业务的连续性和可用性。