很多站长朋友们都不太清楚redis多个哨兵php，今天小编就来给大家整理redis多个哨兵php，希望对各位有所帮助，具体内容如下：
本文目录一览： 1、 Redis哨兵集群 2、 Redis 学习总结(3) Redis 哨兵模式 3、 Redis哨兵模式搭建（一主二从三哨兵） 4、 redis主从+哨兵 5、 Redis中的哨兵模式 Redis哨兵集群Redis-Sentinel是redis官方推荐的高可用性解决方案，
当用redis作master-slave的高可用时，如果master本身宕机，redis本身或者客户端都没有实现主从切换的功能。
而redis-sentinel就是一个独立运行的进程，用于监控多个master-slave集群，
自动发现master宕机，进行自动切换slave > master
每个Sentinel以每秒钟一次的频率向它所知的Master，Slave以及其他 Sentinel 实例发送一个 PING 命令
如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被 Sentinel 标记为主观下线。
如果一个Master被标记为主观下线，则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。
当有足够数量的 Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认Master的确进入了主观下线状态， 则Master会被标记为客观下线
在一般情况下， 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有Master，Slave发送 INFO 命令
当Master被 Sentinel 标记为客观下线时，Sentinel 向下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次
若没有足够数量的 Sentinel 同意 Master 已经下线， Master 的客观下线状态就会被移除。
若 Master 重新向 Sentinel 的 PING 命令返回有效回复， Master 的主观下线状态就会被移除。
主观下线和客观下线
主观下线：Subjectively Down，简称 SDOWN，指的是当前 Sentinel 实例对某个redis服务器做出的下线判断。
客观下线：Objectively Down， 简称 ODOWN，指的是多个 Sentinel 实例在对Master Server做出 SDOWN 判断，并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后，得出的Master Server下线判断，然后开启failover.
SDOWN适合于Master和Slave，只要一个 Sentinel 发现Master进入了ODOWN， 这个 Sentinel 就可能会被其他 Sentinel 推选出， 并对下线的主服务器执行自动故障迁移操作。
ODOWN只适用于Master，对于Slave的 Redis 实例，Sentinel 在将它们判断为下线前不需要进行协商， 所以Slave的 Sentinel 永远不会达到ODOWN。
Redis主从复制可将主节点数据同步给从节点，从节点此时有两个作用：
但是问题是：
那么这个问题，redis-sentinel就可以解决了
Redis的一个进程，但是不存储数据，只是监控redis
本实验是在测试环境下，因此只准备一台linux服务器用作环境！！
服务器环境，一台即可完成操作
所有配置文件如下
总体redis配置文件如下，6379为master，6380和6381为slave
redis-6380.conf slave配置文件详解，6381端口的配置文件，仅仅和6380端口不一样
在主节点上查看主从通信关系
在从节点上查看主从关系（6380、6379）
此时可以在master上写入数据，在slave上查看数据，此时主从复制配置完成
redis-sentinel-26379.conf配置文件写入如下信息
redis-sentinel-26380.conf和redis-sentinel-26381.conf的配置仅仅差异是port(端口)的不同。
然后启动三个sentinel哨兵
此时查看哨兵是否成功通信
实例的思路
首先查看三个Redis的进程状态
第一个
第二个
第三个
直接干掉master，然后等待其他两个节点是否能自动被哨兵sentienl，切换为master节点
此时查看两个slave的状态
然后会发现slave节点成为master节点！！
Redis 学习总结(3) Redis 哨兵模式在实际开发中不会仅仅部署一个 Redis 服务器，为了获得高可用，Redis 哨兵模式 则是高可用的一种选择。
本文先介绍下 哨兵模式，再介绍了如何在 springboot 项目中使用。
这意味着使用 Sentinel （哨兵模式），您可以创建一个 Redis 部署，它可抵抗某些类型的故障（进行故障迁移）而无需人工干预。
它有这些功能：
Sentinel 的分布式特性
Redis Sentinel 是一个分布式系统，多个 Sentinel 进程协同工作，有这些优势：
部署前需要了解:
三个节点的基本配置
法定人数和仲裁
在配置 哨兵模式时，要指定一个 quorum，它可理解为“法定人数”。
假设有3 个 哨兵，法定人数为2。那么：
哨兵和副本的自动发现
Sentinel 与其他 Sentinel 保持连接，以便相互检查彼此的可用性并交换消息。
但是，您不需要在您运行的每个 Sentinel 实例中配置其他 Sentinel 地址的列表，因为 Sentinel 使用 Redis 实例的 Pub/Sub 功能来发现正在监视相同主节点和副本的其他 Sentinel。
类似地，您不需要配置附加到主服务器的副本地址在哪里，因为 Sentinel 会通过查询 Redis 自动发现它们。
参考我的另一篇文章：
一般需要三个节点，每个节点有一个 redis 和一个哨兵。
下面再分别描述。
我这里按三个 节点，先配置 redis 的主从复制。1个节点作为 master ，2个副本。
配置节点1：master
这里的 redis 作为 master 主redis，其他两个节点作为从节点。
我的文件夹名字叫 box1，这里编辑一个 box1/redis.conf 文件，主要配置内容如下:
配置节点2：副本
编辑一个 box2/redis.conf 文件，主要配置内容如下:
配置节点3：副本
编辑一个 box3/redis.conf 文件，主要配置内容如下:
分别启动这三个redis
命令行执行 redis-server ，并指定 配置文件的路径参数。
如何查看“主从复制”是否配置成功？
使用 info replication 命令，操作如下：
副本节点设置为只读？
从 Redis 2.6 开始，副本已被默认设置为 只读，无需额外配置。.
一般情况下，至少会需要三个哨兵对redis 进行监控，我们可以通过修改端口启动多个sentinel 服务。
第一个哨兵：
哨兵的 默认端口是 26379 ，这里不改。
第二个哨兵：
修改哨兵端口。
第三个哨兵：
修改哨兵端口。
启动哨兵
使用 redis-sentinel 命令，分别启动这三个哨兵
哨兵的自动发现
当三个哨兵都启动后，在各个哨兵的打印日志里可以看到， 三个哨兵已互相发现了彼此的存在 。
至此，配置完毕了，我们有三个 redis，和三个哨兵，看下截图。
模拟 master 宕机
按 ctrl+c 停止 master ，其位于 6379 。停止后，从日志可以看到，哨兵和 redis副本先努力继续连接 6379，反复几次失败后，开始选举出新的 master。截图如下：
至此，配置完毕。
我们看下 springboot 项目的客户端如何配置 以访问 哨兵模式的 redis。
Redis 哨兵支持
对于处理高可用Redis，Spring Data Redis 已经支持Redis Sentinel，使用RedisSentinelConfiguration，如下例所示：
Jedis 和 Lettuce 两种 redis 驱动都可以支持。
RedisSentinelConfiguration 也可以用可以 通过 PropertySource 来设置，它允许您设置以下属性：
配置application.yml
比如我这里修改我的 application.yml 文件如下：
我的配置文件示例：
我的 springboot 配置实例：
Redis官网 sentinel 介绍
spring-data/data-redis
END
Redis哨兵模式搭建（一主二从三哨兵）安装redis
***注意：redis配置文件的bind属性和slaveof 属性要修改成对应的IP地址
***注意：请注意配置文件里面带注释的属性
如果redis因为服务器的cpu过高、内存过高、硬盘存储空间不足而导致的redis服务读取异常，redis哨兵已经切换redis服务，java客户端还是有一直报读取错误，无法切换到其它服务节点，请尝试将springboot版本升级到2.3.0，或者将redis的start jar包升级到更高版本
redis主从+哨兵主从切换技术的方法是：当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用。 这不是一种推荐的方式，更多时候，我们优先考虑 哨兵模式 。
哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是 哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。
这里的哨兵有两个作用
然而一个哨兵进程对Redis服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。
用文字描述一下 故障切换（failover） 的过程。假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行failover过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象成为 主观下线 。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为 客观下线 。这样对于客户端而言，一切都是透明的。
配置3个哨兵和1主2从的Redis服务器来演示这个过程。
首先配置Redis的主从服务器，修改redis.conf文件如下
主从服务器都需要配置
配置3个哨兵，每个哨兵的配置都是一样的。在Redis安装目录下有一个sentinel.conf文件，copy一份进行修改
上述关闭了保护模式，便于测试。
Redis中的哨兵模式哨兵模式是一种自动选择老大的模式，即在老大宕机之后，哨兵模式会根据哨兵们的内部投票，自动的重新选出一个新的老大。哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，如果Redis服务器一直没有响应，说明这个Redis服务器可能已经宕机了，从而监控运行的多个Redis实例。
这里的哨兵有两个作用
1、通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器。
2、当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。
然而一个哨兵进程对Redis服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。
用文字描述一下故障切换(failover)的过程。假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行failover过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象成为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线。这样对于客户端而言，一切都是透明的。如果有三个哨兵，不仅每个哨兵会监视主机和从机，而且哨兵之间也会互相监视，如下图：
配置哨兵配置文件sentinel.conf，如下
当哨兵模式的配置文件配置好之后，就可以启动哨兵模式了，如下图
测试在哨兵模式下如果主机崩了的话会不会从从机中自动选出一个老大，先关闭主机，让主机宕机，如下图：
看看主机宕机之后，哨兵模式中输出日志的新的内容是什么，如下图：
哨兵模式自动选举一个主机这个过程是怎样实现自动化的？哨兵自动选举之前的某个从机为老大，所有的从机都会称新选出的从机为老大，以及原本的老大也会称新选出的老大为老大，这个过程是怎么自动化实现的呢？是通过在对应的redis服务器的配置文件中写内容来实现的，比方说，让我们看一下新老大也即是端口号是6381的redis服务器的配置文件中是怎样改写的，如下图：
再来看一下从机即端口号是6380的redis服务器对应的配置文件是怎样改写的，如下图：
最后看一下原本的主机即端口号是6379的redis服务器的配置文件是怎样改写的。我检查了一下，发现在重新启动原本的老大即重启已经宕机的端口号是6379的redis服务器之前，它对应的配置文件中没有发生任何改变，但是一旦重新启动原本的老大，它对应的配置文件就会发生变化，如下图：
哨兵模式中的主机关闭之后需要特别注意的一个易错点：就是因为现在老大已经换了，所以老大的认证密码也换了，因此需要在现任老大的所有从机里面配置主机的认证密码，这个哨兵模式是不会帮我们自动配置的，需要我们自动配置，如下图：
测试哨兵模式结果，如下图：
1、哨兵集群，基于主从复制模式，所有的主从配置优点，它全有。
2、主从可以切换，故障可以转移，系统的可用性就会更好。
3、哨兵模式就是主从模式的升级，手动到自动，更加健壮。
1、集群容量一旦到达上限，在线扩容十分麻烦。
2、实现哨兵模式的配置其实是很麻烦的，里面有很多选择。
当Redis集群的主节点故障时，Sentinel集群将从剩余的从节点中选举一个新的主节点，有以下步骤：
Sentinel集群的每一个Sentinel节点会定时对Redis集群的所有节点发心跳包检测节点是否正常。如果一个节点在down-after-milliseconds时间内没有回复Sentinel节点的心跳包，则该Redis节点被该Sentinel节点主观下线。
当节点被一个Sentinel节点记为主观下线时，并不意味着该节点肯定故障了，还需要Sentinel集群的其他Sentinel节点共同判断为主观下线才行。
该Sentinel节点会询问其他Sentinel节点，如果Sentinel集群中超过quorum数量的Sentinel节点认为该Redis节点主观下线，则该redis客观下线。
如果客观下线的redis节点是从节点或者是Sentinel节点，则操作到此为止，没有后续的操作了；如果客观下线的Redis节点为主节点，则开始故障转移，从从节点中选举一个节点升级为主节点。
如果需要从redis集群选举一个节点为主节点，首先需要从Sentinel集群中选举一个Sentinel节点作为Leader。
每一个Sentinel节点都可以成为Leader，当一个Sentinel节点确认redis集群的主节点主观下线后，会请求其他Sentinel节点要求将自己选举为Leader。被请求的Sentinel节点如果没有同意过其他Sentinel节点的选举请求，则同意该请求(选举票数+1)，否则不同意。
如果一个Sentinel节点获得的选举票数达到Leader最低票数(quorum和Sentinel节点数/2+1的最大值)，则该Sentinel节点选举为Leader；否则重新进行选举。
当Sentinel集群选举出Sentinel Leader后，由Sentinel Leader从redis从节点中选择一个redis节点作为主节点：
详解redis集群选举机制
关于redis多个哨兵php的介绍到此就结束了，不知道本篇文章是否对您有帮助呢？如果你还想了解更多此类信息，记得收藏关注本站，我们会不定期更新哦。
查看更多关于redis多个哨兵php redis哨兵最少几台的详细内容...