出于学习目的，您可以很轻松地在docker环境下运行redis的单个实例，但是如果您需要在生产环境中运行它，那么必须将Redis部署为HA(High Avaliable)模式。
本文基于上一篇主从模式文章docker-compose搭建redis集群之主从复制
Redis是一款开源的、高性能的键-值存储（key-value store）。它常被称作是一款数据结构服务器（data structure server）。
可以做故障判断，故障转移，通知客户端（其实是一个进程），客户端直接连接sentinel的地址
我们知道Redis主从模式下，一旦主节点由于故障不能提供服务，需要人工将从节点晋升为主节点，同时还要通知应用方更新主节点的地址。然后在很多应用场景下这种故障处理的方式是无法接受的，应用程序需要实时感知当前的可用节点。为了解决这个问题，Redis Sentinel应运而生，也称之为"哨兵"。
sentinel 哨兵是特殊的 redis 服务，哨兵不提供读写服务，主要用来监控、提醒和自动故障转移；
在现代应用中，无法容忍系统中断或数据丢失。Redis 作为一种高性能的内存数据库，被广泛应用于缓存、会话管理等场景。然而，即使我们拥有可伸缩的 Redis Cluster 集群，也需要考虑在主节点故障时自动切换到从节点的机制。这时候 Redis Sentinel 就派上用场了。高可用性是分布式应用的核心需求之一。我们在之前的文章中介绍了redis cluster 3主3从集群的搭建，本文将为您介绍如何在现有的 Redis 3 主 3 从 Cluster 集群基础上，使用 Docker Compose 部署 Redis Sentinel，为您的应用构建一个强大的高可用性方案。
[喵咪Redis]Redis-Sentinel 前言 redis-Sentinel 是我们这次来一同学习 redis 的重点,在我们现在的系统已经离不开 redis 的时候 , redis 挂掉了或者
Redis 的 主从复制 模式下，一旦 主节点 由于故障不能提供服务，需要手动将 从节点 晋升为 主节点，同时还要通知 客户端 更新 主节点地址，这种故障处理方式从一定程度上是无法接受的。Redis 2.8 以后提供了 Redis Sentinel 哨兵机制 来解决这个问题。
由于无法进行主动恢复，因此主从模式衍生出了哨兵模式。哨兵模式基于主从复制模式，只是引入了哨兵来监控与自动处理故障。Redis Sentinel是社区版本推出的原生高可用解决方案，Redis Sentinel部署架构主要包括两部分：Redis Sentinel集群和Redis数据集群，其中Redis Sentinel集群是由若干Sentinel节点组成的分布式集群，可以实现故障发现、故障自动转移、配置中心和客户端通知。Redis Sentinel的节点数量要满足2n+1（n>=1）的奇数个。
sentinel是一个分布式系统，可以在一个架构中运行多个sentinel进程，这些进程使用流言协议（gossip protocols）来接收关于rdis主服务器是否下线的信息，并使用投票协议（agreement protocols）来决定是否执行自动故障迁移，以及选举哪个从服务器成为新的主服务器。
Sentinel(哨兵)，顾名思义就是站岗放哨的，是redis提供的高可用解决方案，它是对主从模式的优化升级，在主从模式下，如果主库发生宕机，需要人工介入将某个从节点提升为主库，同时需要修改应用配置的主节点地址，而在Sentinel模式下，每个哨兵(Sentinel)进程会向其它哨兵(Sentinel)、Master、Slave定时发送消息，以确认对方是否”活”着，如果发现对方在指定时间内未得到回应，会对节点做下线标识，如果被标识的是主节点，它还会与其他Sentinel节点进行协商，当多数派都认为主节点不可达时，它们会选举出一个Sentinel节点来完成故障转移的工作，同时会通知应用方主节点已经发生转移。下面我们就来搭建一个Sentinel集群。
此篇的前置原理为,需要能安装REDIS 服务器,并且配置主从关系, Redis 有两种高可用, redis cluster 和 redis sentinel , 今天要说的是redis 的 sentinel, redis sentinel 是从redis 2.8开始提供的一个redis 高可用的功能,这里有几个问题
实现了Redis的主从复制，在一定程度上保证了数据的可用性，但是如果主从复制中的master 节点挂掉，Redis将不再对外提供读写操作。假设当主从复制中的master节点挂掉后，如果能够从它的slave节点中重新选举一个节点作为master节点，那么系统就可以恢复了，因此就有了Redis的哨兵（sentinel）模式。
Sentinel是Redis的高可用性（HA）解决方案，由一个或多个Sentinel实例组成的Sentinel系统可以监视任意多个主服务器，以及这些主服务器属下的所有从服务器，并在被监视的主服务器进行下线状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器，然后由新的主服务器代替已下线的主服务器继续处理命令请求。
Redis的哨兵机制存在的意义就是当主从架构中，master发生宕机，无需人工干预，自动实现故障转移。 官方文档 Redis哨兵能干什么？
Redis-Sentinel是Redis官方推荐的针对主从结构的高可用性解决方案，当master不可用，sentinel能监控多个master-slave集群，发现master宕机后能进行自动切换。
在实际开发中不会仅仅部署一个 Redis 示例，为了获得高可用，Redis 哨兵模式 则是高可用的一种选择。
哨兵 + Redis主从的部署架构不保证数据零丢失，只保证redis集群的高可用性。
一、sentinel哨兵模式介绍 Sentinel(哨兵)是用于监控redis集群中Master状态的工具，是Redis 的高可用性解决方案，sentinel哨兵模式已经被集成在redis2.4之后的版本中。sentinel是redis高可用的解决方案，sentinel系统可以监视一个或者多个redis master服务，以及这些master服务的所有从服务；当某个master服务下线时，自动将该master下的某个从服务升级为master服务替代已下线的master服务继续处理请求。
然后执行下面make命令编译安装到目录/usr/local/redis/ （放执行文件）。
Redis 是一个开源的使用 ANSI C 语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value 数据库，并提供多种语言的 API。
首先，要有一个主备集群。假设有3台电脑分别是MASTER、SLAVE1、SLAVE2。分别在这3台电脑上安装好Redis，并在SLAVE1、SLAVE2上设置为从MASTER同步（replicaof ***），那么它们就组成了主备集群，但是如果主节点出现故障了，从节点并不能提升为主节点，依然不能写入。为了解决这个问题，就要用到哨兵了。
RDB全称Redis Database Backup file（Redis数据备份文件），也被叫做Redis数据快照。简单来说就是把内存中的所有数据都记录到磁盘中。当Redis实例故障重启后，从磁盘读取快照文件，恢复数据。快照文件称为RDB文件，默认是保存在当前运行目录。
我们知道，Redis的集群方案大致有三种：1）redis cluster集群方案；2）master/slave主从方案；3）哨兵模式来进行主从替换以及故障恢复。
新部署前可以从仓库（repository）下载 redis 镜像，或者从已有部署中的镜像生成文件：
版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/wzy0623/article/details/82013226
之前介绍了用docker来搭建redis主从环境，但这只是对数据添加了从库备份(主从复制)，当主库down掉的时候，从库是不会自动升级为主库的，也就是说，该redis主从集群并非是高可用的。 目前来说，高可用(主从复制、主从切换)redis集群有两种方案，一种是redis-sentinel，只有一个master，各实例数据保持一致；一种是redis-cluster，也叫分布式redis集群，可以有多个master，数据分片分布在这些master上。 本文介绍基于docker和redis-sentinel的高可用redis集群搭建，大多数情况下，redis-sentinel也需要做高可用，这里先对redis搭建一主二从环境，另外需要3个redis-sentinel监控redis master。
Redis作为内存数据库，需要具备高可用的特点，不然如果服务器宕机，还在内存里的数据就会丢失。我们最常用的高可用方法就是搭建集群，master机器挂了，可以让slave机器顶上，继续提供服务。但是Redis集群是不会自动进行主从切换的，也就是说，如果主节点非常不争气的在凌晨3点挂了，那么运维同学就要马上起床，把从节点改成主节点，这样的操作是非常繁琐低效的。为此，Redis官方提供了一种解决方案：Redis Sentinel
哨兵是一个分布式系统，你可以在一个架构中运行多个哨兵进程，这些进程使用流言协议来接收关于Master主服务器是否下线的信息，并使用投票协议来决定是否执行自动故障迁移，以及选择哪个Slave作为新的Master。
redis sentinel（redis哨兵） 一、redis哨兵简介 特殊的redis节点，不是数据节点。用来监控数据节点，如果数据节点故障，能够对该节点进行下线标识，如果故障的节点是主节点，sentinel可以实现自动的故障切换。
目前企业生产环境用的主流版本还是3.x，这里我就以redis 3.2.8稳定版来做搭建环境。
IP:192.168.225.128、192.168.225.129 环境：centos7 版本：redis-3.2.10
主从(MASTER-SLAVE) : 一主多从, 读写分离,提高性能,从节点做备份更方便. 但是主节点挂了,就无法写.
redis sentinel解决主从复制高可用问题 非高可用状态下故障处理 一个主节点、两个从节点 1）主节点发生故障，客户端连接主节点失败，两个从节点和主节点连接终端复制失败 2）选择一个从节点更新为主节点 3）更新应用方的配置信息，更新主节点信息，重新启动 4）待原来的主节点恢复后，将其加入从节点同步新的主节点
Redis-Sentinel是Redis官方推荐的高可用性(HA)解决方案。实际上这意味着你可以使用Sentinel模式创建一个可以不用人为干预而应对各种故障的Redis部署。
在安装 Redis 哨兵之前，需要先安装 Redis 服务。可以参考 Redis 官方文档或者本站的 Redis 安装教程进行安装。
本期原本计划是写些redis高可用架构选型，分析，及实战，发现篇幅过长，所以拆开来写了。这期先讲一些官方提供的高可用功能，主从，sentinel，以及redis cluster。
本篇文章笔者推荐一个笔者最常用的docker图形化管理工具——Portainer。
之前的主从复制我们已经会搭建了，但是当我们的主机挂了之后，还需要手动的从 从机里面选一个作为主机，这个手动的太麻烦，现在就需要用新的技术，当主机挂了之后，可以从 多个从机里面 选择一个当做主机。
关于Redis高可用方案，看到较多的是keepalived、zookeeper方案。 keepalived是主备模式，意味着总有一台浪费着。zookeeper工作量成本偏高。 本文主要介绍下使用官方sentinel做redis高可用方案的设计。 阅读目录： Redis Sentinel 故障转移消息接收的3种方式 整体流程图 总结 Redis Sentinel Sentinel介绍 Sentinel是Redis官方为集群提供的高可用解决方案。 在实际项目中可以使用sentinel去做redis自动故障转移，
从今天开始开辟Redis相关方面的东西 上一节说了如何安装和配置redis 还有主从如何搭建 这节内容为哨兵的相关内容 关于哨兵大家可自行在网上搜索其用途和工作原理 系统为 Redhat 7.4 数据库为 Redis 5.0.8 1. redis规划 IP地址 主机名 端口 配置及数据文件位置 角色 172.18.95.83 SYTEST1 6380 /home/redis master 172.18.95.84 SYTEST2 6380 /home/redis slave 172.18.95.85 SYT
如图所示，Redis的 **主从复制模式** 和Sentinel **高可用架构** 的示意图：
本文将通过理论+实践的方式从头到尾总结Redis中的哨兵机制。文章内容从主从复制的弊端、如何解决弊端、什么是哨兵、哨兵监控的图形结构、哨兵监控的原理、如何配置哨兵、哨兵与主从复制的关系等方面来演示。本文演示如何自建一个Redis哨兵机制。推荐使用腾讯云服务器，腾讯云Redis服务等产品。
和MongoDB不同的是，Redis中的主从复制，主节点挂掉后不会自动选举，如果需要自动选举需要借助Redis Sentinel来实现
码哥带大家完成在 CentOS 7 中安装 Redis 6.x 教程。在学习 Redis 之前，我们需要先搭建一套哨兵环境。机器有限，实现目标是一台机器上搭建 6 个节点，构成一主两从三哨兵集群模式。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
