字符串 String

SET KEY VALUE

创建字符串键值

GET KEY

查看字符串对应键的值

DEL KEY

删除字符串对应键的值

EXISTS KEY

查找对应键值是否存在

KEYS pattern

例如：
KEYS * //用于查找所有键
KEYS *me //查找所有以 me 结尾的键

FLUSHALL

删除所有的键

TLL（Time To Live）

查看键多久过期

EXPIRE KEY TIME

给予键过期时间

SETEX KEY TIME VALUE

创建一个一开始就自带过期时间的键

SETNX KEY VALUE

键存在则不做反应，键不存在则创建键

其他：

Redis 中的键、值是区分大小写的。

Redis 中默认是用二进制进行字符串的存储，这也就意味着 Redis 中可以存储许多类型的数据。

因为 Redis 中默认是用二进制进行字符串的存储，默认不支持中文。如果你使用默认打开的 Redis ，中文输出会自动变成十六进制的形式。这时候我们使用 quit 退出 Redis 的命令端口，输入 redis-cli --raw 表示使用原始的形式显示内容开启命令端口，这样就能看到中文了。

列表 List

LPUSH/RPUSH LISTNAME VALUE

将元素添加到头部或者尾部
例如 LPUSH 的新元素会在列表头添加，也就意味着原来在列表的元素全部往后移一位

LRANGE LISTNAME START END

查看列表指定位置区域的元素
例如：
LRANGE NAME 0 -1 //从头开始查看0开始到-1的列表元素，也就是查看列表全部元素

LPOP/RPOP LISTNAME 个数

删除列表内指定数量的元素
例如：
LPOP NAME 2 //删除NAME列表中从开头开始算的两个元素
LPOP NAME //不写数量默认删一个

LLEN LISTNAME

查看列表长度

LTRIM LISTNAME 范围

删除列表指定范围外的元素
例如：
LTRIM NAME 1 3 //只保留位置 1~3 的元素

其他：

列表中的元素是可以重复的。

无序集合 Set

SADD KEY VALUE

向无序集合中添加指定 KEY 的 VALUE

SMEMBERS KEY

查看集合中指定 KEY 中的 VALUE

SISMENBERS KEY VALUE

查看集合中指定 VALUE 是否在指定 KEY 中

SREM KEY VALUE

删除集合中指定 KEY 的指定 VALUE

INCR KEY

让键的值自增
注意：只能用在数字类型

Redis也支持集合的交、并、差集运算。

SINTER、SUNION、SDIFF

例如有这三个集合：
    S1 = { "a", "b", "c", "d" }
    S2 = { "c", "d", "e", "f" }
    S3 = { "d", "e", "f", "g" }
    
SINTER S1 S2        //交集运算
输出：{ "c", "d" }

SUNION S1 S2 S3        //并集运算
输出：{ "a", "b", "c", "d", "e", "f", "g" }

SDIFF S2 S3            //差集预算
输出：{ "c" }

其他：

Set集合中的元素是不可重复的。

有序集合 SortedSet

ZADD KEY SCORE NAME

创建有序集合
例子：
ZADD result 200 张三 300 李四 400 王五 400 赵六

ZRANGE KEY START END

查找对应键内指定区域的值
例子：
ZRANGE result 0 -1 //查找所有键为 result 的值
ZRANGE result 0 -1 WITHSCORES //输出对应的值并且输出值对应的优先级

ZSCORE KEY NAME

查看键值（成员）对应值的优先级

ZRANK KEY NAME

查看指定值（成员）的排名顺序 → 优先级越大排越后面

ZREVRANK KEY NAME

查看指定值（成员）的排名倒序 → 优先级越大排越前面

ZREM KEY NAME

删除对应键中指定的值（成员）

ZINCRBY KEY SCORE NAME

让对应键中指定的某个值（成员）的优先级增大指定大小

ZREMRANGEBYRANK KEY START END

例子：
ZREMRANGEBYRANK result 0 0 //删除排名在 0 到 0 之间的成员（即第一个成员）
ZREMRANGEBYRANK result -2 -1 //删除排名在倒数第二到最后一个之间的成员

其他：

有序集合的成员是唯一的，但是有序集合的优先级可以重复。

哈希 Hash

HSET KEY FIELD VALUE

为哈希表设置字段值
例如：
HSET person name 张三
HSET person age 23

HGET KEY FIELD

获取哈希表中指定字段的值
例如：
HGET person name
HGET person age

HGETALL KEY FIELD

获取哈希中所有字段的值
注意：这个将字段和值作为一对输出

HDEL KEY FIELD

删除哈希中指定字段的值

HEXISTS KEY FIELD

判断哈希中指定字段的值是否存在

HKEYS KEY

获取哈希中所有字段

HLENS KEY

获取哈希中指定字段的键值对的数量

发布/订阅

SUBSCRIBE CHANNEL

订阅指定的频道

PUBILSH CHANNEL MESSAGE

发布消息到指定的频道

其他：

发布/订阅功能有一定的局限性：

消息无法持久化：这意味着如果订阅者在消息发布后离线，它将错过这段时间内的所有消息，因为 Redis 不会保存消息以供稍后重新发送；
消息不可靠：例如在网络分区或节点故障的情况下，可能会出现消息丢失或重复传递的问题；
无法记录历史消息：Redis 的发布/订阅功能设计初衷是实时通信，不需要保留或记录历史消息。因此，默认情况下，Redis 不会保存已发布的消息，而是只将消息发送给当前处于活跃状态的订阅者。
扩展性弱：虽然 Redis 可以通过多个节点实现分布式部署，但在大规模的发布/订阅系统中，可能需要更高级的消息队列系统来实现更好的扩展性和负载均衡。
不支持消息筛选：订阅者只能接收到发布者发送的所有消息，无法按照自定义条件进行筛选。
安全性不高：Redis 的发布/订阅功能在安全性方面可能有局限性，特别是在涉及敏感信息或需要严格身份验证的场景下。

尽管存在这些局限性，但对于一些简单的消息发布和订阅场景，Redis 的发布/订阅功能仍然是一个快速、灵活的解决方案。如果您需要更高级的消息队列功能，可以考虑使用专门的消息队列系统，如 RabbitMQ、Kafka 等。

消息队列 Stream

Steam是一个轻量级的消息队列，是 Redis 5.0 之后新增的一个数据结构。它主要解决了 Redis 中发布/订阅的一些局限性。

XADD KEY ID NAME VALUE

向Stream中添加消息，KEY为消息的名字，NAME为消息的名字
例如：
XADD result * score 100 //向Stream中添加键为 result ，名为 Score 内容为 100 的消息
*号表示自动生成一个消息的ID，Redis 自动保证生成的ID是递增的。
如果要手动赋予 ID 则要注意 ID 是整数-整数第一个整数表示时间戳，第二个整数表示序列号，用-连接起来。

XLEN KEY

查看Stream中指定键的消息数量

XRANGE KEY START END

查看Stream中指定键中消息的详细内容
例如：
XRANGE result - + //使用加减号表示所有的消息

XDLL KEY ID

删除Stream中指定键对应ID的消息

XTRIM KEY MAXLEN NUM

删除Stream中指定范围外的消息
例如：
XTRIM result MAXLEN 0 //删除所有的消息

XREAD COUNT NUM

消费Stream中指定数量的消息
例子：
XREAD COUNT 2 BLOCK 100 STREAMS CHANNEL 0 //消费两条消息，如果没有消息就阻塞100毫秒 STREAMS为固定字符后面接消息名，0表示从头开始，1表示从第二条消息开始读取，以此类推。$为获取从执行开始之后的最新消息。
这些消息可以重复读取。

XGROUP CREATE KEY NAME ID

创建消费者组

XINFO GROUPS KEY

查看消费者组的信息

XGROUP CREATECONSUMER KEY NAME CONSUMERNAME

向组内添加消费者。KEY为消息的名字，NAME为消息组的名字。

XREADGROUP GROUP NAME CONSUMERNAME COUNT NUM BLOCK MS KEY >

指定消费者消费指定组里面的消息，COUNT后面的数字为消费多少条消息，BLOCK后数字为阻塞毫秒数，KEY为指定队列名，>表式从这个消息队列里读取最新的消息。

其他：

这里我们来看一下消息队列的具体概念：

消息队列（Message Queue）是一种用于在应用程序之间传递消息的通信方式，它通常由消息中间件（Message-Oriented Middleware）实现。消息队列充当了消息的缓冲区，使得生产者（Producer）和消费者（Consumer）之间解耦，从而实现异步通信和消息传递。
在消息队列系统中，生产者负责产生消息，并将消息发送到队列中；消费者则从队列中获取消息并进行处理。这种模式被称为“生产-消费模式”（Publish-Subscribe Pattern），它提供了以下几个重要概念：
生产者（Producer）：生产者是消息的发送方，负责创建并发送消息到消息队列中。生产者不需要知道消息将被哪些消费者接收、何时接收等信息，只需将消息发送到队列中即可。
消息队列（Message Queue）：消息队列作为消息的中转站，存储了所有待处理的消息。它保证了消息的顺序性和可靠性，并管理消息的生命周期。消息队列可以是内存中的队列，也可以是持久化存储系统。
消费者（Consumer）：消费者从消息队列中获取消息，并对消息进行处理。消费者可能根据自身的处理能力和速度来决定消息的消费速率，使得生产者和消费者之间解耦。
消息中间件（Message-Oriented Middleware）：消息中间件是实现消息队列功能的软件系统，它负责消息的存储、路由、传递和管理。常见的消息中间件包括 RabbitMQ、Apache Kafka、ActiveMQ 等。
消息队列和消息中间件的使用可以带来诸多好处，例如解耦系统、提高系统可伸缩性、增强系统的弹性和鲁棒性、实现异步处理等。它们在分布式系统、微服务架构、事件驱动架构等场景中被广泛应用。

我们会注意到 Redis 的消息队列理念其实和 Kafka 是有一定区别的：

从设计上讲 Redis 是一个基于内存的键值存储数据库，它提供了发布/订阅功能作为消息队列的一种实现方式。Redis 的发布/订阅功能 适合简单的消息通信和实时性要求高的场。Kafka 是一个分布式流处理平台，专注于高吞吐量、持久性和水平扩展。Kafka 被设计用来处理大规模数据流，支持分区、副本、持久化存储等功能。

也就是说 Redis 提供简单的发布/订阅功能，不支持复杂的分区、副本等特性。适合小规模的消息传递和通信。Kafka 支持主题分区、消息持久化、副本备份、消费者组管理等功能，适合构建大规模的实时数据流处理系统。

地理空间 Geospatial

Geospatial 提供了一种存储地理位置信息的数据结构，同时支持对地理位置进行各种计算操作。（例如计算两个地理位置之间的距离、获取某个地理位置的经纬度等）

GEOADD KEY 经度纬度 NAME

创建一个地理位置信息，KEY一般都是city，NAME是城市名

GEOPOS KEY NAME

获取指定地理位置的经纬度

GEODIST KEY NAME NAME 单位

计算两个地理位置之间的直线距离，默认单位为m，可在单位处设置
例如：
GEODIST city beijing guangzhou KM //获取两地的km制直线距离

GEOSEARCH KEY FROMMEMBER NAME BYRADIUS 半径单位

搜索地理位置以它为中心指定半径画圆范围内的其他地理位置信息。BYRADIUS 也可以是 BYBOX，不过这样搜索的就是矩形范围内的其他地理位置信息。

GEOSEARCH KEY FROMMEMBER 经度纬度 BYRADIUS 半径单位

同上

也可以使用 GEORADIUS 或者 GEORAIDUSBYMEMBER 实现同样的功能

超级对数日志 HyperLogLog

HyperLogLog 是一种用来做基数统计的算法。

什么是基数：当一个集合中的元素都不重复，那么这个集合的基数就是元素的个数，当有重复的时候，集合基数的个数就是集合不重复元素的个数。（怎么说呢，就更像计算集合中各个种类的元素的种类数，重复的元素算一个种类里。）

HyperLogLog 的原理是使用随机算法进行计算，通过牺牲一定的精确度去换取更小的内存消耗，但这也就意味着有一定的误差。

所以 HyperLogLog 适合做一些精确度要求不高而且数据量非常大的统计工作。（例如统计一个文章内某个词的出现次数等）

PFADD KEY VALUE ...

添加基数中的元素

PFCOUNT KEY

查看基数的值

PFMERGE NAME KEY KEY

合并两个基数
注：这里的命令只有两个 KEY 所以是合并两个基数，可以多个 KEY（基数）一起合并。
例如：
PFMERGE result name1 name2 //将 name1 和 name2 合并，并将结果传到 result 内

位图 BitMap

BitMap 是字符串类型的拓展，可以使用 String 类型模拟 Bit数组数组的下标就是偏移量，值只有0 和 1 支持一些位运算。

BitMap 的应用比较广泛，例如用户签到情况的场景就可以用它进行记录。

SETBIT KEY NUM NUM

设置某个偏移量的值
例如：
SETBIT qiandao 0 1 //将位图qiandao 偏移量为0的位置上设置为1

GETBIT KEY NUM

获取某个偏移量上的值

我们也可以通过字符串的命令进行批量设置位图上对应偏移量上的值。

SET KEY VALUE

例如：
SET qiandao "\xF0" //使用十六进制进行设置，会自动转为二进制，即为11110000，这样就快速设置好了八个偏移量上的值。

BITCOUNT KEY

统计位图中指定KEY的偏移量上有多少个1

BITPOS KEY NUM

获取位图中指定KEY的第一个出现0/1的偏移量的位置
注：返回的位置是下标位置

BITPOS KEY NUM START END

获取位图中指定KEY的指定范围内第一个出现0/1的偏移量的位置

位域 BitField

BitField 能够将很多小的整数存储在较大的位图中，更高效的使用内存。

BITFIELD KEY set u8 #0 NUM

创建位域信息
例如：
BITFIELD player set u8 #0 1 //设置一个player 等级为 1
u8表示一个八位的无符号整数，也可以是u32等；#0表示第一个位置，#1表示第二个位置，以此类推。

GET KEY

获取位域信息

BITFIELD KEY get u8 #0 NUM

获取位域信息，和创建位域信息同理

BITFIELD KEY incrby u8 #0 NUM

更新位域信息
和创建、获取位域信息同理
例如：
BITFIELD playerincrby u8 #0 1

事务

Redis 可以通过事务在一个请求中执行多个命令。

其主要通过 MULTI 和 EXEC/DISCARD 进行实现的。

MULTI 用于开启事务，开启后其内所有的命令就会被放进一个队列中，最终由 EXEC 命令执行。

在关系型数据库中，事务一般是一个原子操作，执行要么全成功，要么全失败。

Redis 中的事务不能保证命令全执行成功，但是能保证：在 EXEC 命令执行前，所有的命令都会被放在一个队列中缓存起来。在执行 EXEC 命令后，队列中任何一个命令执行失败了，其他命令也会被执行。在事务执行过程中，其他客户端执行的请求并不会被插进事务中。

MULTI

进入事务模式

EXEC

执行事务中的命令

持久化

Redis 是一个基于内存的数据库，关机断电后清空内存缓存时，所有的数据变回丢失，所以持久化对于 Redis 来说很重要。

持久化的两种方式：

RDB 方式（Redis Database）：指在指定的时间间隔内，将内存中的数据快照写入磁盘。
这个快照是某个时间点上数据的完整副本，可以通过文件中的 save 参数来配置。后面的参数是时间和修改次数的组合。
第一个参数表示秒数，第二个参数表示修改次数
除了使用配置文件来自动触发快照之外，还可以使用 save 命令来手工触发快照，直接在命令行中输入 save 命令就可以了。使用 ls 命令来查看一下文件，会有一个 dump.rdb 的文件，可以通过 xxd dump.rdb 查看文件（xxd是一个可以查看2进制或者16进制文件内容的Linux命令，可以查看rdb后缀文件的内容）
快照文件有个缺点就是不能实时更新实时保存，如果服务器在保存快照之后的一段时间内宕机，那在保存快照后的这段时间内的数据会因为没保存到而丢失。
所以一般用快照来做备份。
而且实际用 Redis 的时候给的内存空间大，这也就意味着内容多，将数据同步到硬盘所消耗的时间久长，这个过程中 Redis 一直都在阻塞的状态，不能接受任何请求。
所以又有一个 bgsave 命令，这条命令单独创出一个子进程负责将数据同步到硬盘中。这样 Redis 的主进程就可以接着干事情，但创建子进程也要消耗一定的时间和资源，也就意味着即便这样 Redis 也会因为创建子进程而阻塞一段时间。
AOF 方式（Append Only File）：指追加文件。
它的原理是执行写命令的时候，不仅会将命令写入内存中，也会将命令写入到一个追加文件中，这个文件便是 AOF 文件，它会以日志的形式记录命令。
当 Redis重启时，就会重新读取 AOF 中的命令内容，进行内存数据库的重建。
需要开启的话在配置文件中将 Appendonly 这个参数的值改成 yes 即可。

主从复制

主从复制指一条 Redis 服务器复制到另一台 Redis 服务器，这也叫主节点（master）和从节点（slave）。

一个主节点可以有多个从节点，而每个从节点只能有一个主节点。

数据的复制是单向的，子节点复制主节点的数据。

一般主节点负责写操作，从节点负责读操作。主节点通过异步的方式将数据发送到从节点，从节点收到数据后更新自己的数据。

主节点不需要修改配置，修改从节点的配置即可。

修改的方式有两种：①命令行修改。②配置文件修改。

命令行修改：命令行通过 slaveof 命令来直接指定主节点的 IP 和端口，这种方式不常用。

配置文件修改：一般在 Redis 的目录下有一个 redis.conf 文件。

接下来我们来看如何配置文件实现主从节点：
将 Redis 的目录的 redis.conf 文件复制一份到根目录下作为主节点的配置文件。再将一份 redis_6380 文件复制到根目录上作为从节点的配置文件。6380 为从节点的端口号。进入文件后将端口号和 pidfile 的也改成6380。
因为Redis 是以守护进程的方式运行，系统默认将pid写到文件中。如果启动多个 Redis 服务，需要将两个 Redis 的 pid 文件区分开。
在找到 dbfilename 这个配置项，将它加上刚刚的端口号。这个是快照的文件名。
为了区分开主从节点的快照，记得也加上端口号。
再找到 replicaof ，它是用来指定主节点的，将它的 ip地址改成主节点的地址，并将端口改成主节点的端口，用来表示配置的这个从节点是依赖于修改ip和端口的主节点。
然后再控制台输入 redis-server redis-6380.conf 回车之后就启动成功了。在启动另一个客户端 redis-cli -p 6380 进行指定从节点，连接成功后可以使用 info replication 查看客户端信息。再打开一个新的客户端作为主节点 redis-cli，就可以愉快的进行测试了。
当然也可以多个从节点，只需要将刚刚的 6380 端口的 conf 文件复制一份，将文件中的 6380 改成你想要的子节点端口，就可以按同样的操作进行连接了。

主从复制流程

第一阶段

从节点发送命令 psync 给主库，这个命令有两个参数。

runId：Redis 启动的随机 id ，但是一开始从库并不知道这个值，所以传 ？。

offset：设置 -1，表示第一次复制。

主库收到命令后，会返回 FULLRESYNC 响应命令，并带上上面两个参数。

第二阶段

主库执行 bgsave 命令，生成 RDB 文件，接着将文件发给从库。

在主库生成 RDB 文件并开始将数据同步给从库的过程中，主库不会被阻塞，仍然可以正常接收请求，不会停止响应其他客户端的命令请求，保持了服务的连续性和可用性。

这个过程中，主库会在内存中维护一个专门的复制缓冲区（replication buffer）。这些请求中的写操作并没有记录到刚刚生成的 RDB 文件中。而是为了保证主从库的数据一致性，主库会在内存中用 replication buffer记录 RDB 文件生成后收到的所有写操作。

一旦从库完成数据同步，主库就会将复制缓冲区中的写操作应用到新的 RDB 文件中，以确保主从库的数据一致性。

这样，即使在生成 RDB文件期间有新的写操作，也能被安全地同步到从库，从而保证整个系统的数据一致性和可用性（保证主从数据一致，也就是第三阶段干的事）。

第三阶段

主库会把第二阶段执行过程中新收到的写命令，再发送给从库。具体的操作是，当主库完成 RDB 文件发送后，就会把此时 replication buffer 中的修改操作发给从库，从库再重新执行这些操作，更新从库自身的数据变得与主库一样。这样一来，主从库就实现同步了。

主从复制的架构很简单，但是有一个很明显的弊端，如果主库挂了，整个服务职能提供读请求，写请求无法处理了，这是业务不能接受的，所以我们来介绍下一种模式：哨兵模式。

哨兵模式

前面主从模式的时候我们可以实现主从节点集群，实现了一定程度上的高可用。

但是这也有一定的缺陷：如果主节点当寄了，我们需要手动将一个从节点上升为主节点，需要人工干预，这样也不能算纯正高可用。

Redis 的哨兵模式可以自动的将故障转移。哨兵会以一个独立的进程去运行在 Redis 集群中，用于监控集群中各个节点是否运行正常。

功能与过程

哨兵模式的功能有：

监控：通过不断向节点发送命令以此来检测节点是否正常。
自动故障转移/选主（选择主库）：主节点不能工作时，哨兵会自动将主节点的故障转移，将一个从节点自动上升为一个主节点，再将其他从节点指向这个新的主节点。
通知：如果发现某个节点出现问题，哨兵就会发布订阅模式来通知其他节点。

根据哨兵模式的功能，我们接下来讲讲这些功能的详细作用和运行流程。

监控

监控是指哨兵进程在运行时，周期性地给所有的主从库发送 PING 命令，检测它们是否仍然在线运行。如果从库没有在规定时间内响应哨兵的 PING 命令，哨兵就会把该从库标记为下线状态。

同样，如果主库也没有在规定时间内响应哨兵的 PING 命令，哨兵就会判定主库变为下线状态，然后开始自动切换主库的流程。

选主

一旦主节点/主库被标记为客观下线状态，哨兵节点开始执行选举新主节点的流程。

哨兵进程节点会从所有可用的从节点/从库中选举一个新的主节点。它会评估每个从节点的性能和复制偏移量等指标，并选择最适合的节点作为新的主节点。
如果有多个从节点符合条件，则哨兵进程节点可能会使用一些额外的逻辑来选择最合适的节点。例如，它可能会考虑节点的复制延迟、磁盘使用率等因素。
一旦选举出新的主节点，哨兵进程节点会更新集群的配置信息，并通知其他哨兵节点和客户端进行相应的调整。

通知

一旦新的主节点选举出来，哨兵进程节点会更新集群的配置信息，并通知客户端重新连接到新的主节点。客户端重新连接到新的主节点后，继续进行数据操作。

所以使用 哨兵模式 与 主从模型 的 Redis 流程架构图大概如下：

请输入图片描述

主观下线和客观下线

为了增加判断的准确性，一般会采用多实例组成的集群模式进行部署，这也被称为哨兵集群。引入多个哨兵实例一起来判断，就可以避免单个哨兵因为自身网络状况不好，而误判主库下线的情况。同时，多个哨兵的网络同时不稳定的概率较小，由它们一起做决策，误判率也能降低。

因此在判断主库是否下线时，不能由一个哨兵说了算，只有大多数的哨兵实例，都判断主库已经主观下线，主库才会被标记为客观下线，这个叫法也是表明主库下线成为一个客观事实了。这个判断原则就是：少数服从多数。少数判断是下线状态为主观下线，多数判断是下线状态为客观下线。同时，这会进一步触发哨兵开始主从切换流程。

主库切换

因为哨兵节点也是一个进程节点，所以它也会出现单节点故障问题，我们在实际使用中一般会使用 3 个哨兵节点作为一个哨兵集群去进行监控，保证高可用。

如果哨兵集群只有 2 个实例，此时，一个哨兵要想成为 Leader，必须通过选举。
选举方式：
拿到半数以上的赞成票；
拿到的票数同时还需要大于等于哨兵配置文件中的 quorum 值。
所以，如果有个哨兵挂掉了，那么，此时的集群是无法进行主从库切换的。

三个哨兵会采用选举的方式让一个哨兵成为Leader去监控节点，如果领导者出问题，其余两个会自动选举出一个新的去顶替旧的，以保证哨兵节点的高可用。

引用一下别人的文章：
作者：东东拿铁
链接：https://juejin.cn/post/7342427121665474579
来源：稀土掘金
任何一个实例只要自身判断主库“主观下线”后，就会给其他实例发送 is-master-down-by-addr 命令。接着，其他实例会根据自己和主库的连接情况，做出Y或N的响应，Y同意，N反对。
一个哨兵获得了仲裁所需的赞成票数后，就可以标记主库为“客观下线”。这个所需的赞成票数是通过哨兵配置文件中的 quorum 配置项设定的。
Leader选举，这个哨兵就可以再给其他哨兵发送命令，表明希望由自己来执行主从切换，并让所有其他哨兵进行投票。因为最终执行主从切换的哨兵
任何一个实例只要自身判断主库“主观下线”后，就会给其他实例发送 is-master-down-by-addr 命令。接着，其他实例会根据自己和主库的连接情况，做出Y或N的响应，Y同意，N反对。
一个哨兵获得了仲裁所需的赞成票数后，就可以标记主库为“客观下线”。这个所需的赞成票数是通过哨兵配置文件中的 quorum 配置项设定的。
Leader选举，这个哨兵就可以再给其他哨兵发送命令，表明希望由自己来执行主从切换，并让所有其他哨兵进行投票。因为最终执行主从切换的哨兵

哨兵通信

哨兵模式使用发布/订阅（Pub/Sub）功能来实现节点之间的通信和事件通知。

订阅频道：

哨兵节点可以通过订阅一个或多个频道来接收消息。在哨兵模式中，通常会使用特定的频道来发布各种事件，比如 +switch-master 用于通知主节点切换，这样哨兵节点就能及时获取这类关键事件的信息，从而进行相应的处理和调整；+sdown 用于通知节点下线等，当前 Redis 连接就会订阅 +sdown 频道，一旦有节点下线的事件发生，订阅了该频道的节点就会接收到相应的通知消息。

SUBSCRIBE +switch-master

执行上面的指令，这样哨兵节点就能及时获取这类关键事件的信息，从而进行相应的处理和调整。

SUBSCRIBE +sdown

执行上面的指令后，当前 Redis 连接就会订阅 +sdown 频道，一旦有节点下线的事件发生，订阅了该频道的节点就会接收到相应的通知消息。

发布消息：

当发生某些事件时，比如主节点故障或故障转移，哨兵节点可以使用 PUBLISH 命令向订阅者发送消息。消息内容包括了①新主节点的名称、②IP 地址和端口号，这样其他节点就能根据接收到的消息做出相应的调整，以维护集群的正常运行。

PUBLISH +switch-master master-name new-ip new-port

执行上面的指令，这条命令会向订阅了 +switch-master 频道的所有节点发送一条消息，通知它们主节点切换的情况。

PUBLISH +sdown <node-ip> <node-port>

执行以上指令后，当前 Redis 连接就会订阅 +sdown 频道，一旦有节点下线的事件发生，订阅了该频道的节点就会接收到相应的通知消息。

配置

哨兵需要 redis-sentinel sentinel.conf 命令，同时我们需要先创建一个 sentinel.conf 的文件。
sentinel monitor name IP 端口号 Num（1的话意味着只需要一个哨兵同意就可以进行转移）
执行命令后会发现执行了一个哨兵模式客户端。
用之前主从模式的执行例子，我们有一个6380的从节点，如果我们创建并执行一个6381的从节点，将执行着的主节点结束，我们看哨兵客户端会发现提示主节点宕机，自动故障转移到6380从节点作为主节点，并将6381从节点指向了6380主节点。我们可以去6380节点输入 info replication 会发现它从 slave 变成了 master。

[Redis学习] Redis基础一条龙