一、持久化
1.1 介绍
Redis 持久化是内存中的数据保存到硬盘上，持久化功能可以有效的避免因进程退出造成数据丢失的问题。Redis本身支持RDB和AOF两种持久化方式。
1.2 RDB
RDB 持久化是把当前进程数据生成快照保存到硬盘的过程，触发RDB持久化过程分为：手动触发和自动触发
1.2.1 触发机制
-
手动触发
-
save执行该命令，会阻塞当前Redis服务器，直到当前进程中的数据存储到硬盘后则结束。若内存中存在较多的数据时，会造成服务器长时间阻塞，故线上环境不建议使用。
-
bgsave该命令会使
redis进程执行fork创建子进程，通过调用子进程去对当前中的数据进行存储，完成后自动结束。阻塞只发生在fork阶段，即创建子进程的这个过程。
-
-
自动触发
- 使用save相关配置，如
save m n：表示在m秒的时间内，数据集修改了n次，则触发bgsave命令自动保存数据。 - 如果从节点执行全量复制操作，主节点自动执行
bgsave生成RDB文件并发送给从节点。 - 执行
debug reload命令重新加载Redis时也会触发bgsave - 执行
shutdown时，如果未开启AOF则会自动执行bgsave
- 使用save相关配置，如
1.2.2 RDB文件处理
-
文件保存
-
查看默认文件保存路径
127.0.0.1:6379> config get dir 1) "dir" 2) "/var/lib/redis" -
执行save默认保存在默认目录下
redis 127.0.0.1:6379> SAVE [root@centos8-106 redis]# pwd /var/lib/redis [root@centos8-106 redis]# ll total 4 -rw-r--r-- 1 redis redis 118 Jun 1 22:30 dump.rdb -
配置RDB文件保存到指定目录下
config set dir {newDir} # 指定存储的目录 config set dbfilename {newFileName} # 指定存储的文件名称
-
-
校验
如果加载了已经损坏的RDB文件，可以使用
redis-check-dump工具进行检测 -
优缺点
-
优点
- RDB是一个紧凑压缩的二进制文件，代表Redis在某个时间节点上的数据快照。适用于备份，全量复制。
- Redis加载RDB文件恢复数据比加载AOF文件要快很多。
-
缺点
- RDB无法做到
实时持久化 / 秒级持久化 - 存在一些老版本Redis服务器无法兼容新版本RDB文件的问题
- RDB无法做到
-
1.3 AOF
AOF(Append Only File) 持久化：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中的命令来实现数据恢复的目的。 AOF的主要作用是解决了数据持久化实时性问题。
1.3.1 使用AOF
-
**redis.conf 配置 AOF **
appendonly：默认值为no，也就是说redis 默认使用的是rdb方式持久化，如果想要开启 AOF 持久化方式，需要将 appendonly 修改为 yes。appendfilename ：aof文件名，默认是"appendonly.aof"appendfsync：aof持久化策略的配置； no表示不执行fsync，由操作系统保证数据同步到磁盘，速度最快，但是不太安全； always表示每次写入都执行fsync，以保证数据同步到磁盘，效率很低； everysec表示每秒执行一次fsync，可能会导致丢失这1s数据。通常选择 everysec ，兼顾安全性和效率。no-appendfsync-on-rewrite：在aof重写或者写入rdb文件的时候，会执行大量IO，此时对于everysec和always的aof模式来说，执行fsync会造成阻塞过长时间，no-appendfsync-on-rewrite字段设置为默认设置为no。如果对延迟要求很高的应用，这个字段可以设置为yes，否则还是设置为no，这样对持久化特性来说这是更安全的选择。 设置为yes表示rewrite期间对新写操作不fsync,暂时存在内存中,等rewrite完成后再写入，默认为no，建议yes。Linux的默认fsync策略是30秒。可能丢失30秒数据。默认值为no。auto-aof-rewrite-percentage：默认值为100。aof自动重写配置，当目前aof文件大小超过上一次重写的aof文件大小的百分之多少进行重写，即当aof文件增长到一定大小的时候，Redis能够调用bgrewriteaof对日志文件进行重写。当前AOF文件大小是上次日志重写得到AOF文件大小的二倍（设置为100）时，自动启动新的日志重写过程。auto-aof-rewrite-min-size：64mb。设置允许重写的最小aof文件大小，避免了达到约定百分比但尺寸仍然很小的情况还要重写。aof-load-truncated：aof文件可能在尾部是不完整的，当redis启动的时候，aof文件的数据被载入内存。重启可能发生在redis所在的主机操作系统宕机后，尤其在ext4文件系统没有加上data=ordered选项，出现这种现象 redis宕机或者异常终止不会造成尾部不完整现象，可以选择让redis退出，或者导入尽可能多的数据。如果选择的是yes，当截断的aof文件被导入的时候，会自动发布一个log给客户端然后load。如果是no，用户必须手动redis-check-aof修复AOF文件才可以。默认值为 yes -
AOF执行流程
-
所有的写入命令会追加到aof_buf（缓冲区）中。
-
AOF缓冲区根据对应的策略向磁盘做同步策略
-
随着AOF文件越来也大，需要定期对AOF文件进行重写，达到压缩文件的目的。
-
当Redis服务器重启时，加载AOF文件进行数据恢复。
-
1.3.2 AOF写入
AOF命令写入的内容直接是文本协议格式。例如set hello world 这条命令，在AOF缓冲区会追加如下内容：
*3\r\n$3\r\nset\r\n$5\r\nhello\r\n$5\r\nworld\r\n
# 上述格式就等于（RESP redis序列化协议）
*3 # 表示3个参数
$3 # 第一个参数有3个字符
set
$5 # 第二条参数有5个字符
hello
$5 # 第三条参数有5个字符
world
1.3.3 重写机制
随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入了AOF重写机制压缩文件体积。AOF文件重写是把Redis进程内数据转化为写命令同步到新AOF文件的过程。
为什么重写后的AOF文件可以变小？
- 进程内已经超时的数据不会再写入文件
- 旧的AOF文件含有一些无效命令，如
del 、hdel、srem、等。重写使用进程内数据直接生成 ，去掉了一些无效数据。 - 多条写命令合并为一条
1.3.4 触发机制
AOF重写过程分为自动触发和手动触发：
-
手动触发
直接执行
bgrewriteaof命令 -
手动触发
根据
auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数来确定自动触发时机配置文件redis.conf 中的默认配置：
auto-aof-rewrite-min-size : 表示运行AOF重写文件时文件最小体积，默认为64MB
auto-aof-rewrite-percentage : 代表当前AOF文件空间(aof_current_size)和上一次重写之后AOF文件空间(aof_base_size)的比值
# 自动触发机制：
aof_current_size > auto-aof-rewrite-min-size && (aof_current_size - aof_base_size ) / aof_base_size
>= auto-aof-rewrite-percentage
查看当前AOF文件空间(aof_current_size) 和 AOF文件空间(aof_base_size)
127.0.0.1:6379> info Persistence
# Persistence
loading:0
rdb_changes_since_last_save:0
rdb_bgsave_in_progress:0
rdb_last_save_time:1654137038
rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:-1
rdb_current_bgsave_time_sec:-1
rdb_last_cow_size:0
aof_enabled:0
aof_rewrite_in_progress:0
aof_rewrite_scheduled:0
aof_last_rewrite_time_sec:-1
aof_current_rewrite_time_sec:-1
aof_last_bgrewrite_status:ok
aof_last_write_status:ok
aof_last_cow_size:0
- 重写机制内部流程
我们知道 Redis 是单线程工作，如果 重写 AOF 需要比较长的时间，那么在重写 AOF 期间，Redis将长时间无法处理其他的命令，这显然是不能忍受的。Redis为了克服这个问题，解决办法是将 AOF 重写程序放到子程序中进行，这样有两个好处：
-
子进程进行 AOF 重写期间，服务器进程（父进程）可以继续处理其他命令。
-
子进程带有父进程的数据副本，使用子进程而不是线程，可以在避免使用锁的情况下，保证数据的安全性。
使用子进程解决了上面的问题，但是新问题也产生了：
因为子进程在进行 AOF 重写期间，服务器进程依然在处理其它命令，这新的命令有可能也对数据库进行了修改操作，使得当前数据库状态和重写后的 AOF 文件状态不一致。
为了解决这个数据状态不一致的问题：
Redis 服务器设置了一个 AOF 重写缓冲区，这个缓冲区是在创建子进程后开始使用，当Redis服务器执行一个写命令之后，就会将这个写命令也发送到 AOF 重写缓冲区。当子进程完成 AOF 重写之后，就会给父进程发送一个信号，父进程接收此信号后，就会调用函数将 AOF 重写缓冲区的内容都写到新的 AOF 文件中。
这样将 AOF 重写对服务器造成的影响降到了最低。
-
文件校验
redis-check-aof --fix # 修改aof文件 diff -u # 对比修改后数据的差异
1.3.5 重启加载
Redis重启时，AOF文件和RDB文件执行的流程
二、主从复制
2.1 简介
复制的Redis实例划分为主节点（master）和从节点（slave）。默认情况下，redis都是主节点。每个主节点对应多个从节点，每个从节点只能对应一个主节点。
主从复制可以有效的实现读写分离，容灾快速恢复。
2.2 配置主从复制
2.2.1 如何配置
1）slaveof 配置
-
配置文件设置slaveof
# redis.conf slaveof {masterHost} {masterPort}跟随Redis启动生效
-
redis-server 启动命令加参数slaveof
redis-server --slaveof {masterHost} {masterPort} -
直接使用 slaveof
slaveof {masterHost} {masterPort}
slaveof 本身是异步命令，可以通过
info replication来查看复制相关状态
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:0
master_replid:f947e8da52c4cdbd2c655b5b0f624edc261bf449
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
2）安全配置
若主节点设置了密码，从节点需要配置masterauth 参数与主节点密码一致，这样才能进行主从复制
3）只读模式
默认情况下，从节点只能进行读模式，通过slave-read-only=yes 设置，复制过程是主节点到从节点的过程，所以主节点无法感知从节点的复制修改等，故不建议开启从节点可以修改。
2.2.2 主从操作
-
启动并连接三个不同的redis服务
-
配置三份 redis配置文件
创建
myredis文件夹，该目录下配置三份redis启动配置文件。注意：源redis.conf 建议开启daemonize yes 为后台启动[root@centos8-106 myredis]# cat redis-6379.conf && cat redis-6380.conf && cat redis-6381.conf include /home/software/myredis/redis.conf # 包含原来的redis配置文件 pidfile /var/run/redis_6379.pid port 6379 dbfilename dump6379.rdb include /home/software/myredis/redis.conf pidfile /var/run/redis_6380.pid port 6380 dbfilename dump6380.rdb include /home/software/myredis/redis.conf pidfile /var/run/redis_6381.pid port 6381 dbfilename dump6381.rdb -
启动服务并进行连接
- 启动
redis-server redis-6379.conf redis-server redis-6380.conf redis-server redis-6381.conf- 查看启动情况
[root@centos8-106 myredis]# ps -ef | grep redis root 1520 1 0 03:57 ? 00:00:00 redis-server 127.0.0.1:6380 root 1527 1 0 03:57 ? 00:00:00 redis-server 127.0.0.1:6381 root 1551 1 0 03:58 ? 00:00:00 redis-server 127.0.0.1:6379 ......- 连接
[root@centos8-106 ~]# redis-cli -h 127.0.0.1 -p 6379 127.0.0.1:6379> ... 另2个客户端连接同理...
-
-
设置主从服务器
在配置主从服务器时，因为redis默认为主节点，所以只需要配置从节点即可。我们直接使用命令来设置从节点，设置从节点的方式参照 2.2.1 小节。
主从节点情况 IP 端口号 master（主节点） 127.0.0.1 6379 slave（从节点） 127.0.0.1 6380 slave（从节点） 127.0.0.1 6381 -
未配置从节点前查看主节点的节点信息
127.0.0.1:6379> info replication # Replication role:master connected_slaves:0 # 连接的从节点为 0 ...... -
配置从服务器
127.0.0.1:6380> slaveof 127.0.0.1 6379 OK 127.0.0.1:6381> slaveof 127.0.0.1 6379 OK -
配置从节点后参看主节点的节点信息
127.0.0.1:6379> info replication # Replication role:master connected_slaves:2 slave0:ip=127.0.0.1,port=6380,state=online,offset=98,lag=1 slave1:ip=127.0.0.1,port=6381,state=online,offset=98,lag=1发现主节点存在2个从节点
-
配置从节点后参看从节点的节点信息
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_repl_offset:168 slave_priority:100 slave_read_only:1 connected_slaves:0 master_replid:c633e8962ac6e8fa0c3456b5ab5135c43ee65e49发现6380服务器的role已经变成 slave ,表示该redis服务为从节点
-
-
主从操作
-
主节点写入新的key-value，发现从节点可以查询到主节点设置的key-value
127.0.0.1:6379> set k100 v100 OK 127.0.0.1:6380> get k100 "v100" -
从节点写入新的key-value
127.0.0.1:6380> set k101 v101 (error) READONLY You can't write against a read only replica.显示写入错误，从节点只能进行读操作，如果从节点也可以写入数据，将会造成主从节点之间的数据不一致。
-
2.2.3 slaveof 命令详解
slaveof 命令可以建立主从复制，也可以断开主从复制。在从节点执行slaveof no one 来断开与主节点复制关系。
-
断开复制的主要流程
- 断开与主节点复制关系
- 从节点晋升为主节点
从节点断开复制后并不会抛弃原有的数据，只是无法再获取主节点的数据
-
切主操作
主从切换就是把当前的从节点对主节点复制切换到另一个主节点。
slaveof {newmasterIp} {newMasterPort}
- 切主操作流程
- 断开与旧主节点复制关系
- 与新主节点建立复制关系
- 删除从节点当前的所有数据
- 对新主节点进行复制操作
注意：
切主后从节点会清空之前所有的数据，故进行线上操作时需要小心执行slaveof。
2.3 主从拓扑
2.3.1 一主一从
一个主节点对应一个从节点，当应用写入命令并发量较高时且需要进行持久化时，可以只在从节点开启AOF，这样既能保障数据安全也能避免持久化对主节点的性能干扰。
注意：若主节点关闭了AOF，一定要避免主节点脱机后自动重启的操作，因为AOF文件在从节点上，主节点上面没有AOF文件，故主节点重启后数据集将会被清空，此时从节点继续复制主节点中的数据集，则从节点中的数据也会被清空。这样就丧失了持久化的意义
安全做法：在从节点上执行slaveof no one ，使之成为主节点，这样数据就可以有效的保留。
2.3.2 一主多从
一主多从可以使得应用端利用从节点进行读取，主节点写入，实现读写分离。当从节点过多时会造成主节点压力过大
2.3.3 树状主从结构
通过引入复制中间层，可以有效减低主节点负载和需要传输给其他从节点的数据量
- 优点
- 有效减低主节点的负载和复制数据时的压力
- 缺点
- 主节点无法对底层从节点进行管制，一旦中间层从节点发生宕机，则底层主节点无法连接底层从节点
2.4 主从复制原理
2.4.1 复制过程
在从节点执行slaveof 后，复制过程便开始执行。
-
主从复制过程
-
保存主节点信息
保存主节点的IP和Port，但是主节点的状态还是下线状态（即未建立连接）
-
主从建立socket连接
从节点内部通过每秒运行定时任务维护复制相关逻辑，当定时任务发现存在新的主节点后会尝试与该节点建立连接
若无法建立连接，则定时任务会无限重试直到连接成功或执行
slaveof no one -
发送ping命令
建立连接成功后从节点会发送ping请求进行首次通信，目的如下：
- 检测主从之间网络是否可用
- 检测主节点当前是否可以接受处理命令
若发送ping命令后，从节点未收到主节点的pong回复或者发送超时了，从节点会断开，直到下一次定时任务执行会发起重连
-
权限验证
若主节点设置了
requirepass参数，从节点需要配置masterauth参数进行验证（注意从节点与主节点的密码必须一致） -
同步数据集
在正常通信后，对于首次建立复制场景，主节点会把全有的数据全部发给从节点，这部分操作是相当耗时的，不过在redis 2.8 之后的版本中对其进行了优化，采用了新的命令
psync进行数据同步，原命令sync依旧支持，保证了兼容性。psync数据同步分为全量同步和部分同步，下一节会详细述说。 -
命令持续复制
建立复制流程后，主节点会持续的把写命令发送给从节点
-
2.4.2 数据同步
psync 命令完成主从之间的数据同步，主要分为：全量复制和部分复制
-
全量复制
一般发生在初次建立复制场景，当数据量较大时会对主节点的网络造成较大的开销
-
部分复制
主从节点会维护自身的偏移量，主节点在处理完写入命令后，会把命令的直接长度进行累加，在
info replication中的master_repl_offset可以看见。从节点每秒上报自己的偏移量给主节点，主节点通过偏移量来确定发给从节点的数据，同时从节点在接收主节点发送过来的数据时，也会进行累加到自身的偏移量。
通过主从的偏移量来判断主从节点复制相差的数据量来确定主从数据是否一致
-
复制积压缓冲区
复制积压缓冲区是主节点上一个固定长度的队列，默认为1MB，当主节点有从节点时被创建，主节点在发送写命令给从节点时，也会把写命令加入到积压缓冲区中。
缓冲区本身是一个先进先出的定长队列，可以保存最近已复制的数据，这样做的好处就是：若从节点在接收主节点的写命令时发生意外导致接收失败，此时主节点可以通过缓冲区内的数据再次发送给从节点，实现数据的安全传输。
2.5 主从复制情况说明
2.5.1 一主二仆
即表示一个主节点，二个从节点
-
若主节点宕机，从节点还是从节点嘛
是的，从节点还是从节点
-
若主节点重新恢复后，主机新增记录，从机还能否顺利复制？
可以的
-
其中一台从机down后情况如何？依照原有它能跟上大部队吗？
从节点依旧可以复制主节点全部数据
2.5.2 薪火相传
上一个Slave可以是下一个slave的Master，Slave同样可以接收其他 slaves的连接和同步请求，那么该slave作为了链条中下一个的master, 可以有效减轻master的写压力,去中心化降低风险。
用 slaveof <ip> <port>
中途变更转向:会清除之前的数据，重新建立拷贝最新的
风险是一旦某个slave宕机，后面的slave都没法备份
主机挂了，从机还是从机，无法写数据了
2.5.3 反客为主
当一个master宕机后，后面的slave可以立刻升为master，其后面的slave不用做任何修改。
用 slaveof no one 将从机变为主机。底层从节点将自动依赖新的主节点。
当原来的主节点重新恢复后，它只是一个主节点，不会有从节点。
三、哨兵（sentinel）
3.1 概念
当主键发生故障时，Redis Sentinel可以自动完成故障发现和故障转移，并通知应用方，从而实现真正的高可用。
主从复制存在一些问题：
- 一旦主节点发生故障，需要手动将一个节点晋升为主节点
- 主节点的写能力受到单机的限制
- 主节点的存储能力受到单机的限制
上述的这些问题对于公司来说需要人为处理，故障的实时性和准确性都无法得到有效的保障。
所以：哨兵的出现就是为了解决主从复制所出现的这些问题
3.2 部署哨兵及测试
3.2.1 部署主从拓扑与哨兵
-
部署一主二从拓扑结构
通过前面2.2 小节设置了一主二仆主从节点
-
部署sentinel节点
在自定义目录下创建
sentinel.conf文件，在文件中写入：sentinel monitor mymaster 127.0.0.1 6379 1 # 其中mymaster为监控对象（主节点）起的别名， 1 为至少有多少个哨兵同意迁移的数量。
3.2.2 启动哨兵
-
方式一
redis-sentinel /home/software/myredis/sentinel.conf -
方式二
redis-server /home/software/myredis/sentinel.conf --sentinel上述两种启动方式本质是一样的，个人比较喜欢用第一种
-
启动
[root@centos8-106 myredis]# redis-sentinel /home/software/myredis/sentinel.conf
2219:X 03 Jun 2022 07:32:33.392 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
2219:X 03 Jun 2022 07:32:33.392 # Redis version=6.0.8, bits=64, commit=00000000, modified=0, pid=2219, just started
2219:X 03 Jun 2022 07:32:33.392 # Configuration loaded
2219:X 03 Jun 2022 07:32:33.393 * Increased maximum number of open files to 10032 (it was originally set to 1024).
_._
_.-``__ ''-._
_.-`` `. `_. ''-._ Redis 6.0.8 (00000000/0) 64 bit
.-`` .-```. ```\/ _.,_ ''-._
( ' , .-` | `, ) Running in sentinel mode
|`-._`-...-` __...-.``-._|'` _.-'| Port: 26379
| `-._ `._ / _.-' | PID: 2219
`-._ `-._ `-./ _.-' _.-'
|`-._`-._ `-.__.-' _.-'_.-'|
| `-._`-._ _.-'_.-' | http://redis.io
`-._ `-._`-.__.-'_.-' _.-'
|`-._`-._ `-.__.-' _.-'_.-'|
| `-._`-._ _.-'_.-' |
`-._ `-._`-.__.-'_.-' _.-'
`-._ `-.__.-' _.-'
`-._ _.-'
`-.__.-'
2219:X 03 Jun 2022 07:32:33.394 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
2219:X 03 Jun 2022 07:32:33.395 # Sentinel ID is edd273a0333d22da09c5497f7e10600b97897996
2219:X 03 Jun 2022 07:32:33.395 # +monitor master mymaster 127.0.0.1 6379 quorum 1
3.2.3 哨兵测试
当主节点宕机后，查看哨兵监控终端。
大约经过20秒左右，哨兵终端输出了信息
2219:X 03 Jun 2022 07:37:27.117 # +sdown master mymaster 127.0.0.1 6379
2219:X 03 Jun 2022 07:37:27.117 # +odown master mymaster 127.0.0.1 6379 #quorum 1/1
2219:X 03 Jun 2022 07:37:27.117 # +new-epoch 1
2219:X 03 Jun 2022 07:37:27.117 # +try-failover master mymaster 127.0.0.1 6379
2219:X 03 Jun 2022 07:37:27.118 # +vote-for-leader edd273a0333d22da09c5497f7e10600b97897996 1
2219:X 03 Jun 2022 07:37:27.118 # +elected-leader master mymaster 127.0.0.1 6379
2219:X 03 Jun 2022 07:37:27.118 # +failover-state-select-slave master mymaster 127.0.0.1 6379
2219:X 03 Jun 2022 07:37:27.205 # +selected-slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
2219:X 03 Jun 2022 07:37:27.205 * +failover-state-send-slaveof-noone slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
2219:X 03 Jun 2022 07:37:27.290 * +failover-state-wait-promotion slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
2219:X 03 Jun 2022 07:37:27.381 # +promoted-slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
2219:X 03 Jun 2022 07:37:27.381 # +failover-state-reconf-slaves master mymaster 127.0.0.1 6379
2219:X 03 Jun 2022 07:37:27.470 * +slave-reconf-sent slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
2219:X 03 Jun 2022 07:37:28.437 * +slave-reconf-inprog slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
2219:X 03 Jun 2022 07:37:28.437 * +slave-reconf-done slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
2219:X 03 Jun 2022 07:37:28.505 # +failover-end master mymaster 127.0.0.1 6379
2219:X 03 Jun 2022 07:37:28.505 # +switch-master mymaster 127.0.0.1 6379 127.0.0.1 6381
# 此处切换6381从节点晋升为主节点。
2219:X 03 Jun 2022 07:37:28.505 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6381
2219:X 03 Jun 2022 07:37:28.505 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6381
2219:X 03 Jun 2022 07:37:58.553 # +sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6381
3.2.4 测试总结
哨兵可以自动实现监控主节点的状态，若主节点宕机，哨兵会自动选取一个从节点晋升为主节点，实现可以自动数据保障。
-
特点
- 监控：哨兵节点会定期检测redis数据节点是否可达
- 通知：若出现故障转移的结果会通知给应用方
- 主节点故障转移：实现从节点晋升为主节点
- 配置提供者：初始化时的一些配置
3.3 实现原理
哨兵是如何选取从节点作为主节点的？
优先级在redis.conf中默认：slave-priority 100，值越小优先级越高
偏移量是指获得原主机数据最全的
每个redis实例启动后都会随机生成一个40位的runid
3.4 sentinel配置文件详解
在上述测试中，sentinel.conf配置文件只写了短短的一行，其实还存在一些其他的配置
# sentinel.conf
sentinel monitor mymaster 127.0.0.1 6379 1
# 为一个节点指定别名，指定IP和端口，数字1表示：若该主节点挂了，需要几个哨兵节点投票是否开始选取新的主节点
sentinel down-after-milliseconeds mymaster 30000
# 超过了30秒，数据节点没有回复，则判断为该节点不可达，将进行主节点选取。
sentinel parallel-syncs mymaster 1
# parallel-syncs 用来限制在一次故障转移之后，每次向新的主节点发起复制操作的从节点个数
sentinel failover-timeout mymaster 180000
# failover-timeout 故障转移超时时间（3分钟），作用域故障转移的各个阶段
sentinel auth-pass mymaster 123456
# 若监控的主节点设置了密码，哨兵也需要输入密码才能进行监控（此处密码为123456）
sentinel notification-script <master-name> <script-path>
# 故障转移期间，出现一个警告级别的sentinel事件发生，就会触发对应路径的脚本
sentinel client-reconfig-script <master-name> <script-path>
# 故障转移之后触发的脚本
398
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
