Redis基础知识点

Redis基础

一级目录

二级目录

三级目录

一、什么是Redis?

​ Redis 是用C语言开发的一个开源的、高性能、基于内存运行的、非关系型的键值对NoSQL数据库。可以存储键和五种不同类型的值之间的映射（键的类型只能为字符串，值支持五种），传统数据库的数据存储是在硬盘上的，而redis的数据存储在内存中，所以读写速度很快。

特点

• 支持数据持久化，可以将数据保存在磁盘中，重启之后可以再次加载到内存中使用；
• 支持多种数据类型，除了支持KV类型的数据，还支持list、set、hash等数据结构；
• 支持master-slave模式（主从模式 ）的数据备份。

二、Redis应用场景

1. 热点数据加速查询（主要场景），如热点商品、热点信息等访问量较高的数据；
2. 即时信息查询，如公交到站信息、在线人数信息等等；
3. 时效性信息控制，如验证码控制、投票控制等等；
4. 分布式数据共享，如分布式集群架构中的session分离消息队列。

三、Redis的下载和安装

1. 去官网https://redis.io/download下载redis-6.2.6.tar.gz的安装包，并放入Linux中的/usr/local的目录中；

   

   

2. 在/usr/local目录下，执行解压命令；

   tar-zxvf redis-6.2.6.tar.gz -C /usr/local/
   

3. 解压完成后出现文件夹redis-6.2.6，并进行修改名字；

   mv redis-6.2.6/redis6.2
   

4. 进入文件夹redis6.2，在此目录下执行make && make install命令，如果出现以下错误，是因为没有安装gcc环境，用 yum -y install gcc 来安装。

   如下图所示，未找到命令，因为没有gcc环境：

   

   如果再出现以下致命错误，执行此命令可完成安装 ；

   make MALLOC=libc
   

   

5. 进入默认安装目录cd /usr/local/bin，此目录中有如下文件

6. 

四、Redis服务的启动

1. 修改redis配置文件，将它设置为后台运行，进入/usr/local/redis6.2目录下：

vi redis.conf

通过vim查找语句查找daemonize：进入命令模式 shift+：，输入以下查找命令：/daemonize；然后被no改成yes，保证后台可以自行运行；

linux下vim 查找命令：

/text --查找text, 按n查找下一个, N查找上一个

?text --查找text(反向查找), 按n查找下一个, N查找上一个

*/# --查找光标当前的单词,相当于/text

:set ignorecase --查找忽略大小写

:set noignorecase --查找不忽略大小写

:nohlsearch --关闭当前的高亮显示,当再次查找时恢复高亮

:set incsearch --逐步搜索模式,对当前键入的字符进行查找,不必等输入完成

:set wrapscan --重新搜索,当搜索到文件头或尾时,返回重新搜索

2. 启动redis服务

cd /usr/local/redis6.2 //进入该目录
redis-server /redis6.2/redis.conf //启动服务
或者在 cd /usr/local/bin //进入该目录
./redis-server redis.conf //启动服务

不过按下ctrl+c就中断了

3. 查看服务是否启动

ps aux|grep redis-server
或者 ps ef|grep redis

4. 如果启动不了

需要修改配置文件里的 bind 127.0.0.1 ::1

删除 ::1 保存退出

假如在配置文件中 的内容是：bind x.x.x.x ::1

那么再使用redis-cli连接redis-server时，应该使用 ：

redis-cli -h x.x.x.x -p 6379 或者 redis-cli -h x.x.x.x -p port(配置文件中指定的端口号)

5. 再次启动查看是否启动

使用redis命令行工具

五、Redis命令行工具

redis-cli ：一般都会使用 redis-cli 进入交互模式，然后一问一答来读写服务器

六、Redis基础知识

1. Redis 采用单线程机制进行工作；
2. Redis 默认拥有16个数据库，数据库编号从0开始，默认使用0号数据库；
3. 使用 select 数据库编号 可以切换使用的数据库；
4. dbsize 命令 是查看当前数据库key的数量；
5. **keys *** 命令 是查看当前数据库所以的key；
6. flushdb 命令 是清空当前的数据库；
7. flushall 命令 是清空所有的数据库；
8. Redis 中所有数据库使用同一个密码，默认没有密码，Redis认为安全层面应该有Linux来保证
9. Redis 中所有索引都是从0开始；
10. Redis 默认端口号是6379；

七、Redis数据类型

1. key（键）

Redis有五大数据类型：String、List、Set、Zset、Hash；

注意：Redis采用键值（key-value）对存储数据，key永远是String类型，五大数据类型指的是value部分

2. String（字符串）

• 一个key对象一个value；

• String可以包含任何数据，比如jpg图片等等；

• String是Redis最基本的数据类型，一个String最大可以支持M；

3.List（列表）

• 底层是一个字符串链表，可以从头或尾添加元素；
• 注意：添加元素时：
• • 如果key不存在，创建新的链表；
  • 如果key已存在，添加内容；
  • 如果key的所有值全部删除。则对应的key也会随之消失；
• 在链表的头尾操作时效率较高，但是对中间元素的操作效率较低。

4.Set（无序集合）

• 底层是通过HashTable实现的；
• 是String类型的无重复值的无序集合。

5.Zset（有序集合）

• 类似Set；
• 每个元素都会关联一个double类型的分数（score）；
• Redis通过分数自动的为集合中的成员进行从小到大的排序；
• 成员不可重复，分数可以重复。

6.Hash（哈希）

• 类似Java中的Map<String,Object>;
• 是一个键值对集合
• 适合存储对象。

7.单指令（set）与多指令（mset）的选择

对于set与mset两个指令，应该使用哪一个由具体的业务场景决定；

(1) set指令的执行过程

​ set指令发送给Redis服务器需要一个网络时间；Redis服务器执行该指令需要一个处理时间； Redis服务器将结果返回需要一个网络时间；故需要2个网络时间 + 1个处理时间

(2) 使用set存储n个值

​ n个网络时间(发送) + n个处理时间(处理) + n个网络时间(返回)

(3) 使用mset存储n个值

​ 1个网络时间(发送) + n个处理时间(处理) + 1个网络时间(返回)

​ 注：每次携带的数据增多，网络时间会相应的延长

​ **综上所述，当需要处理的数据较少时，使用单指令；当处理的数据较多时，使用多指令 **

八、Redis常用查询指令

九、持久化概念

1.意外断电或者重启之后，内存中的数据将会丢失，故应当将内存中的数据保存在磁盘中。

2.概念

​ 利用磁盘等将数据进行保存，在特定的时间将保存的数据进行恢复的工作机制称为持久化。

为什么要进行持久化

• 防止数据的意外丢失，确保数据安全性

3.持久化的两种方式

• 快照：将某个时间点的工作状态保存下来，恢复时可直接恢复指定时间点的工作状态，Redis中这种方式称为RDB。

• 日志：将对数据的所有操作过程记录下来，恢复数据时重新执行这些操作，Redis中这种方式称为AOE。

Redis 分别提供了 RDB 和 AOF 两种持久化机制：

• RDB 将数据库的快照（snapshot）以二进制的方式保存到磁盘中。
• AOF 则以协议文本的方式，将所有对数据库进行过写入的命令（及其参数）记录到 AOF 文件，以此达到记录数据库状态的目的。

9.1 RDB

1. save指令

（1）RDB启动方式 —— save指令，作用：手动执行一次保存操作

save

save保存数据：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-7nQy41uh-1650343462262)(C:/Users/xxy/AppData/Roaming/Typora/typora-user-images/image-20220324150823315.png)]

查看数据存储文件目录下的rdb文件，配置文件中指定的存储目录：

（2）RDB启动方式 —— save指令相关配置

对redis.conf配置文件进行修改（修改配置文件后需要进行重新Redis）

（3）RDB启动方式 —— save指令工作原理

​ Redis是单线程的，故执行save指令会阻塞其之后的命令的执行(可能多人操作同一个Redis 服务器)，如果要保存的数据较多时，会导致之后的命令长时间阻塞，故一般不使用save指令。

​ **注意：**save指令的执行会阻塞当前Redis服务器，直到当前RDB过程完成为止，有可能会造成长时间阻塞，线上环境不建议使用。

2.bgsave指令

（1）RDB启动方式 —— bgsave指令，作用：手动启动后台保存操作，但不是立即执行。

bgsave

（2）RDB启动方式 —— bgsave指令工作原理

注意： bgsave命令是针对save阻塞问题做的优化。Redis内部所有涉及到RDB操作都采用bgsave的方式，save命令可以放弃使用。

查看日志中bgsave命令执行成功后返回的信息：

（3）RDB启动方式 —— bgsave指令相关配置

自动执行：

• 谁：redis服务器发起指令（基于条件）
• 什么时间：满足条件
• 干什么事情：保存数据

（4）配置自动保存 RDB启动方式 ——save配置（修改配置文件后需要重启Redis）

save second changes

• 作用

• • 满足限定时间范围内key的变化数量达到指定数量即进行持久化

• 参数

• • second：监控时间范围
• • changes：监控key的变化量

• 位置

• • 在conf文件中进行配置

实例：

（5）RDB启动方式 ——save配置原理

注意：

• save配置要根据实际业务情况进行设置，频度过高或过低都会出现性能问题，结果可能是灾难性的；
• save配置中对于second与changes设置通常具有互补对应关系，尽量不要设置成包含性关系；
• save配置启动后执行的是bgsave操作。

（6）RDB启动方式对比

（7）RDB特殊启动形式

• 全量复制
  • 在主从复制中详细讲解
• 服务器运行过程中重启

debug reload

• 关闭服务器时指定保存数据

shutdown save

• 默认情况下执行shutdown命令时，自动执行bgsave(如果没有开启AOF持久化功能)

3.RDB优缺点

RDB优点：

• RDB是一个紧凑压缩的二进制文件，存储效率较高；
• RDB内部存储的是redis在某个时间点的数据快照，非常适合用于数据备份，全量复制等场景；
• RDB恢复数据的速度要比AOF快很多；
• 应用：服务器中每X小时执行bgsave备份，并将RDB文件拷贝到远程机器中，用于灾难恢复。

RDB缺点：

• RDB方式无论是执行指令还是利用配置，无法做到实时持久化，具有较大的可能性丢失数据；
• bgsave指令每次运行要执行fork操作创建子进程，要牺牲掉一些性能；
• Redis的众多版本中未进行RDB文件格式的版本统一，有可能出现各版本服务之间数据格式无法兼容现。

参考文献：

https://blog.youkuaiyun.com/baidu_41388533/article/details/108936459

9.2 AOF

1.概念

• AOF(append only file)持久化
  • 以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中命令达到恢复数据的目的。
  • 与RDB相比可以简单描述为改记录数据为记录数据产生的过程
• AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式

2.AOF写数据过程

3.AOF写数据三种策略(appendfsync)

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Ey4id8Ft-1650343462272)(C:/Users/xxy/AppData/Roaming/Typora/typora-user-images/image-20220324161312073.png)]

Redis 目前支持三种 AOF 保存模式，它们分别是：

1. AOF_FSYNC_NO ：不保存。
2. AOF_FSYNC_EVERYSEC ：每一秒钟保存一次。
3. AOF_FSYNC_ALWAYS ：每执行一个命令保存一次。

4.AOF功能开启

5.AOF相关配置

6.AOF重写

AOF写数据遇到的问题：如果连续执行如下指令该如何处理

所以就引入了AOF重写：

（1）概念

​ 随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入了AOF重写机制压缩文件体积。AOF文件重写是将Redis进程内的数据转化为写命令同步到新AOF文件的过程。

​ 简单说就是将对同一个数据的若干个条命令执行结果转化成最终结果数据对应的指令进行记录。

（2）AOF重写作用

• 降低磁盘占用量，提高磁盘利用率；
• 提高持久化效率，降低持久化写时间，提高IO性能；
• 降低数据恢复用时，提高数据恢复效率。

（3）AOF重写规则

• 进程内已超时的数据不再写入文件；
• 忽略无效指令，重写时使用进程内数据直接生成，这样新的AOF文件只保留最终数据的写入命令；
  如del key1、 hdel key2、srem key3、set key4 111、set key4 222等
• 对同一数据的多条写命令合并为一条命令
  • 如lpush list1 a、lpush list1 b、 lpush list1 c 可以转化为：lpush list1 a b c。
  • 为防止数据量过大造成客户端缓冲区溢出，对list、set、hash、zset等类型，每条指令最多写入64个元素。

（4）AOF重写方式

bgrewriteaof  //手动重写

auto-aof-rewrite-min-size size
auto-aof-rewrite-percentage percentage //手动重写
bgrewriteaof
自动重写

• 配置文件

• 重写操作

• 查看日志

（5）AOF手动重写 —— bgrewriteaof指令工作原理

（6）AOF自动重写方式

• 自动重写触发条件设置

  auto-aof-rewrite-min-size size
  auto-aof-rewrite-percentage percent
  

• 自动重写触发比对参数（ 运行指令info Persistence获取具体信息 ）

  aof_current_size
  aof_base_size
  

• 自动重写触发条件

示例

• 输入info查看信息

7.AOF工作流程

注：执行重写自己开启一个主进程

• AOF缓冲区同步文件策略，由参数appendfsync控制
• 系统调用write和fsync说明：
  • **write操作会触发延迟写（delayed write）机制，**Linux在内核提供页缓冲区用来提高硬盘IO性能。
    • write操作在写入系统缓冲区后直接返回。
    • 同步硬盘操作依赖于系统调度机制，列如：缓冲区页空间写满或达到特定时间周期。同步文件之前，如果此时系统故障宕机，缓冲区内数据将丢失。
  • fsync针对单个文件操作（比如AOF文件），做强制硬盘同步，fsync将阻塞知道写入硬盘完成后返回，保证了数据持久化。
    • 除了write、fsync、Linx还提供了sync、fdatasync操作：

9.3 RDB与AOF的选择与区别

区别：

RDB与AOF的选择：

• 对数据非常敏感，建议使用默认的AOF持久化方案

  • AOF持久化策略使用everysecond，每秒钟fsync一次。该策略redis仍可以保持很好的处理性能，当出现问题时，最多丢失0-1秒内的数据。

  • 注意：由于AOF文件存储体积较大，且恢复速度较慢。

• 数据呈现阶段有效性，建议使用RDB持久化方案

  • 数据可以良好的做到阶段内无丢失（该阶段是开发者或运维人员手工维护的），且恢复速度较快，阶段点数据恢复通常采用RDB方案
  • 注意：利用RDB实现紧凑的数据持久化会使Redis降的很低，慎重总结。

• 综合比对

  • RDB与AOF的选择实际上是在做一种权衡，每种都有利有弊；
  • 如不能承受数分钟以内的数据丢失，对业务数据非常敏感，选用AOF；
  • 如能承受数分钟以内的数据丢失，且追求大数据集的恢复速度，选用RDB；
  • 灾难恢复选用RDB；
  • 双保险策略，同时开启 RDB 和 AOF，重启后，Redis优先使用 AOF 来恢复数据，降低丢失数据的量；

参考文献：https://blog.youkuaiyun.com/baidu_41388533/article/details/108937181

9.4 面试官都爱问的Redis持久化(RDB)、面试官都爱问的Redis持款化(AOF)

​ RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储；
​ AOF持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据, AOF命令以redis协议追加保存每次写的操作到文件末尾, redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大只做缓存:如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式，同时开启两种持久化方式。
​ 在这种情况下，当redis重启的时候会优先载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。
​ RDB的数据不实时,同时使用两者时服务器重启也只会找AOF文件,那要不要只使用AOF呢?作者建议不要,因为RDB更适合用于备份数据库(AOF在不断变化不好备份) ,快速重启,而且不会有AOF可能潜在的bug ,留着作为一个万一的手段。
性能建议：
​ 因为RDB文件只能做后备用途,建议只在Slave上持久化RDB文件,而且只要15分钟备份- -次就够了,只保留save 900 1这条规则。
​ 如果开启AOF ,好处是在最恶劣的情况下也只会丢失不超过两秒的数据,启动脚本简单只加载自己的AOF文件就可以了,代价一是带来了持续的IO，二是AOF重写的最后将重写过程中产生的新数据写到新文件造成的堵塞几乎是不可避免的,只要硬盘许可,应该尽量减少AOF重写的频率，AOF重写的基础大小默认值64M太了，可以设置到5GB以上,默认超过原大小100%大小时重写可以改到适当的数值。如果不开启AOF ,仅靠Master- Slave Replication 实现高可用性也可以,能省掉一大笔I0也减少了重弓时带来的系统波动，代价是如果Master/Slave同时倒掉,会丢失十几分钟的数据,启动脚本也要比较两个Master/Slave中的RDB文件,载入较新的那个，新浪微博就选用了这种架构。

十、事务

1.什么是事务？

​ 在Redis执行指令过程中，多条连续执行的指令被干扰，打断，插队**，redis事务就是一个命令执行的队列，将一系列预定义命令包装成一个整体（一个队列）**。当执行时，一次性按照添加顺序依次执行，中间不会被打断或者干扰。一个队列中，一次性、顺序性、排他性的执行一系列命令

2.事务的基本操作

watch

（1）开启事务

multi

​ 作用：设定事务的开启位置，此指令执行后，后续的所有指令均加入到事务中

（2）执行事务

exec

​ 作用：设定事务的结束位置，同时执行事务。与multi成对出现，成对使用。

​ 注意：加入事务的命令暂时进入到任务队列中，并没有立即执行，只有执行exec命令才开始执行。

（3）取消事务

discard

​ 作用：终止当前事务的定义，发生在multi之后，exec之前

实例：

3.事务的工作流程

4.事务的注意事项

定义事务的过程中，命令格式输入错误怎么办？

• 语法错误：指命令书写格式有误
• 处理结果：如果定义的事务中所包含的命令存在语法错误，整体事务中所有命令均不会执行。包括那些语法正确的命令。

定义事务的过程中，命令执行出现错误怎么办？

• 运行错误：指命令格式正确，但是无法正确的执行。例如对list进行incr操作
• 处理结果：能够正确运行的命令会执行，运行错误的命令不会被执行。
• 注意：已经执行完毕的命令对应的数据不会自动回滚，需要程序员自己在代码中实现回滚。

手动进行事务回滚

• 记录操作过程中被影响的数据之前的状态
  • 单数据：string
  • 多数据：hash、list、set、zset
• 设置指令恢复所有的被修改的项
  • 单数据：直接set（注意周边属性，例如时效）
  • 多数据：修改对应值或整体克隆复制

十一、锁

十二、主从复制

​ 通过部署多台redis，并在配置文件中指定这几台redis之间的主从关系，主负责写入数据，同时把写入的数据实时同步到从机器，这种模式就叫做主从复制，即master/slave，并且redis默认master（主）用于写，slave（从）用于读。

【多台服务器连接方案】

• 提供数据方：master
  • 主服务器，主节点，主库
  • 主客户端
• 接收数据方：slave
  • 从服务器，从节点，从库
  • 从客户端
• 需要解决的问题：
  • 数据同步
• 核心工作：
  • master的数据复制到slave中

主从复制

• 主从复制即将master中的数据即时、有效的复制到slave中
• 特征：一个master可以拥有多个slave，一个slave只对应一个master
• 职责：
  • master
    • 写数据
    • 执行写操作时，将出现变化的数据自动同步到slave
    • 读数据（可忽略）
  • slave
    • 读数据
    • 写数据（可忽略）

【主从复制的作用总结】

• **读写分离：**master写、slave读，提高服务器的读写负载能力
• **负载均衡：**基于主从结构，配合读写分离，由slave分担master负载，并根据需求的变化，改变slave的数量，通过多个从节点分担数据读取负载，大大提高Redis服务器并发量与数据吞吐量
• **故障恢复：**当master出现问题时，由slave提供服务，实现快速的故障恢复
• **数据冗余：**实现数据热备份，是持久化之外的一种数据冗余方式
• **高可用基石：**基于主从复制，构建哨兵模式与集群，实现Redis的高可用方案

redis replication（复制）的核心机制：

​ redis 采用异步方式复制数据到 slave 节点，不过 redis2.8 开始后，slave node 会周期性地确认自己每次复制的数据量；

• 一个 master node 是可以配置多个 slave node 的；

• slave node 也可以连接其他的 slave node；

• slave node 做复制的时候，不会 block（阻塞） master node 的正常工作；

• slave node 在做复制的时候，也不会 block（阻塞）对自己的查询操作，它会用旧的数据集来提供服务；但是复制完成的时候，需要删除旧数据集，加载新数据集，这个时候就会暂停对外服务了；

• slave node 主要用来进行横向扩容，做读写分离，扩容的 slave node 可以提高读的吞吐量。

redis 主从复制的核心原理：

1. 当启动一个 slave node 的时候，它会发送一个 PSYNC 命令给 master node；

2. 如果这是 slave node 初次连接到 master node，那么会触发一次 full resynchronization 全量复制；

3. 此时 master 会启动一个后台线程，开始生成一份 RDB 快照文件，同时还会将从客户端 client 新收到的所有写命令缓存在内存中；RDB 文件生成完毕后， master 会将这个 RDB 发送给 slave；

4. slave 会先写入本地磁盘（持久化）；

5. 然后再从本地磁盘加载到内存中；接着 master 会将内存中缓存的写命令发送到 slave，slave 也会同步这些数据。

6. slave node 如果跟 master node 有网络故障，断开了连接，会自动重连，连接之后 master node 仅会复制给 slave 部分缺少的数据。

如下图所示：

过程原理：

• 当从库和主库建立MS关系后，会向主数据库发送SYNC命令；

• 主库接收到SYNC命令后，会开始在后台保存快照(RDB持久化过程)，并将期间接收到的写命令缓存起来；

• 当快照完成后，主Redis会将快照文件和所有缓存的写命令发送给从Redis；

• 从Redis接收到后，会载入快照文件并且执行收到的缓存的命令；

• 之后，主Redis每当接收到写命令时就会将命令发送从Redis，从而保证数据的一致。

十三、哨兵机制

​ 给三个结点去做集群，加入第四个服务器。

​ **作用：**当做哨兵来使用，用第四台服务器去监控3个节点的状态，一旦主节点挂掉了，那么会在从节点中进行选举投票，看那台服务器的性能比较好，指定这台机器升级为主节点，当主节点修复好以后，原来的主节点就会变成从节点。

【主机“宕机”处理】

• 关闭master和所有slave
• 找一个slave作为master
• 修改其他slave的配置，连接新的主
• 启动新的master与slave
• 可能出现全量复制N+部分复制N

【思考】

• 关闭期间的数据服务谁来承接？
• 找一个主？怎么找法？
• 修改配置后，原始的主恢复了怎么办？

1.哨兵基本概念

​ 哨兵(sentinel) 是一个分布式系统，用于对主从结构中的每台服务器进行监控，当出现故障时通过投票机制选择新的master并将所有slave连接到新的master。

2.哨兵的作用

• 监控
  • 不断的检查master和slave是否正常运行。
  • master存活检测、master与slave运行情况检测。
• 通知（提醒）
  • 当被监控的服务器出现问题时，向其他（哨兵间，客户端）发送通知。
• 自动故障转移
  • 断开master与slave连接，选取一个slave作为master，将其他slave连接到新的master，并告知客户端新的服务器地址。
• 注意：
  • 哨兵也是一台redis服务器，只是不提供数据服务；
  • 通常哨兵配置数量为单数；

​ **作用：**当做哨兵来使用，用第四台服务器去监控3个节点的状态，一旦主节点挂掉了，那么会在从节点中进行选举投票，看那台服务器的性能比较好，指定这台机器升级为主节点，当主节点修复好以后，原来的主节点就会变成从节点。

【主机“宕机”处理】

• 关闭master和所有slave
• 找一个slave作为master
• 修改其他slave的配置，连接新的主
• 启动新的master与slave
• 可能出现全量复制N+部分复制N

【思考】

• 关闭期间的数据服务谁来承接？
• 找一个主？怎么找法？
• 修改配置后，原始的主恢复了怎么办？

1.哨兵基本概念

​ 哨兵(sentinel) 是一个分布式系统，用于对主从结构中的每台服务器进行监控，当出现故障时通过投票机制选择新的master并将所有slave连接到新的master。

[外链图片转存中…(img-EOOWy831-1650343462282)]

2.哨兵的作用

• 监控
  • 不断的检查master和slave是否正常运行。
  • master存活检测、master与slave运行情况检测。
• 通知（提醒）
  • 当被监控的服务器出现问题时，向其他（哨兵间，客户端）发送通知。
• 自动故障转移
  • 断开master与slave连接，选取一个slave作为master，将其他slave连接到新的master，并告知客户端新的服务器地址。
• 注意：
  • 哨兵也是一台redis服务器，只是不提供数据服务；
  • 通常哨兵配置数量为单数；