redis sentinel（redis哨兵） 一、redis哨兵简介 特殊的redis节点，不是数据节点。用来监控数据节点，如果数据节点故障，能够对该节点进行下线标识，如果故障的节点是主节点，sentinel可以实现自动的故障切换。
我们知道Redis主从模式下，一旦主节点由于故障不能提供服务，需要人工将从节点晋升为主节点，同时还要通知应用方更新主节点的地址。然后在很多应用场景下这种故障处理的方式是无法接受的，应用程序需要实时感知当前的可用节点。为了解决这个问题，Redis Sentinel应运而生，也称之为"哨兵"。
redis 的主从复制模式下，一旦主节点由于故障不能提供服务，需要人工将从节点晋升为主节点，再通知所有的程序把 master 地址统统改一遍，然后重新上线。毫无疑问，这种故障处理的方法是效率低下的，无法接受。
本文基于上一篇主从模式文章docker-compose搭建redis集群之主从复制
IP:192.168.225.128、192.168.225.129 环境：centos7 版本：redis-3.2.10
Redis-Sentinel是Redis官方推荐的高可用性(HA)解决方案。实际上这意味着你可以使用Sentinel模式创建一个可以不用人为干预而应对各种故障的Redis部署。
第15篇文章中我们讲述了sentine的基本搭建办法，今天我们来说说，sentinel的几个重要参数。
上一篇介绍了Redis的主从服务器之间是如何同步数据的。试想下，在一主一从或一主多从的结构下，如果主服务器挂了，整个集群就不可用了，单点问题并没有解决。Redis使用Sentinel解决该问题，保障集群的高可用。
Sentinel为Redis提供了高可用性架构,该部署架构可以在无需人工干预的情况下完成故障转移;同时也提供监控,通知等其他功能.
《Redis设计与实现》读书笔记（二十七） ——Redis哨兵（sentinel）主服务器下线判断与故障转移 （原创内容，转载请注明来源，谢谢） 一、主观下线检测 默认情况下，sentinel会每秒
因为Sentinel节点是一个特殊的Redis节点，所以它有自己的专属API。下面我们详细介绍一下Sentinel节点的API使用。
sentinel 哨兵是特殊的 redis 服务，哨兵不提供读写服务，主要用来监控、提醒和自动故障转移；
可以做故障判断，故障转移，通知客户端（其实是一个进程），客户端直接连接sentinel的地址
Sentinel（哨兵、哨岗）是Redis的高可用（high availability）解决方案：由一个或多个Sentinel实例组成Sentinel系统可以监视任意多个主服务器以及它们属下的所有从服务器，并在监视主服务器进行下线时，将主服务器下属的从服务器升级为新的主服务器，然后由新的主服务器代替已下线的主服务器继续处理命令请求。
Sentinel是Redis的高可用解决方案：由一个或多个Sentinel实例组成Sentinel Cluster，可以监控任意多个master服务器，及这些master下属的slave服务器。当被监视的master进入下线状态时，Sentinel Cluster会自动将其下属的slave中的一个升级为master，然后由新的master代替已下线的master继续提供服务。
出于学习目的，您可以很轻松地在docker环境下运行redis的单个实例，但是如果您需要在生产环境中运行它，那么必须将Redis部署为HA(High Avaliable)模式。
今天有位朋友私下和我说，他昨天电话面试被问到Redis的高可用方案。于是决定今天来分享这个问题。如果你对此有另外的答案，不妨微信联系我，我拉你进群，让更多的人知道，做一个纯粹的技术分享达人。
Redis的哨兵机制存在的意义就是当主从架构中，master发生宕机，无需人工干预，自动实现故障转移。 官方文档 Redis哨兵能干什么？
在现代应用中，无法容忍系统中断或数据丢失。Redis 作为一种高性能的内存数据库，被广泛应用于缓存、会话管理等场景。然而，即使我们拥有可伸缩的 Redis Cluster 集群，也需要考虑在主节点故障时自动切换到从节点的机制。这时候 Redis Sentinel 就派上用场了。高可用性是分布式应用的核心需求之一。我们在之前的文章中介绍了redis cluster 3主3从集群的搭建，本文将为您介绍如何在现有的 Redis 3 主 3 从 Cluster 集群基础上，使用 Docker Compose 部署 Redis Sentinel，为您的应用构建一个强大的高可用性方案。
Redis是一款开源的、高性能的键-值存储（key-value store）。它常被称作是一款数据结构服务器（data structure server）。
Redis Sentinel 为 Redis 提供了一个简单的自动化的高可用机制。
《Redis设计与实现》读书笔记（二十六） ——Redis哨兵（sentinel）启动与建立监听机制 （原创内容，转载请注明来源，谢谢） 一、概述 哨兵（Sentinel）是redis高可用性的解决方案，由一个或多个哨兵实例组成的哨兵系统，可以监视任意多个主服务器，以及这些主服务器属下的从服务器。 当被监视的主服务器下线时，根据某些规则挑选一个从服务器，作为新的主服务器。接着，其他从服务器会向新的主服务器发送复制指令，并且完成复制。同时，哨兵会监视下线的原主服务器，在它重新上线后，将它也置为从服务器。 二、
哨兵 + Redis主从的部署架构不保证数据零丢失，只保证redis集群的高可用性。
[喵咪Redis]Redis-Sentinel 前言 redis-Sentinel 是我们这次来一同学习 redis 的重点,在我们现在的系统已经离不开 redis 的时候 , redis 挂掉了或者
Sentinel(哨兵)，顾名思义就是站岗放哨的，是redis提供的高可用解决方案，它是对主从模式的优化升级，在主从模式下，如果主库发生宕机，需要人工介入将某个从节点提升为主库，同时需要修改应用配置的主节点地址，而在Sentinel模式下，每个哨兵(Sentinel)进程会向其它哨兵(Sentinel)、Master、Slave定时发送消息，以确认对方是否”活”着，如果发现对方在指定时间内未得到回应，会对节点做下线标识，如果被标识的是主节点，它还会与其他Sentinel节点进行协商，当多数派都认为主节点不可达时，它们会选举出一个Sentinel节点来完成故障转移的工作，同时会通知应用方主节点已经发生转移。下面我们就来搭建一个Sentinel集群。
在 redis3.0 以前的版本要实现集群一般是借助哨兵 sentinel 工具来监控 master 节点的状态，如果 master 节点异常，则会做主从切换，将某一台 slave 作为 master，哨兵的配置略微复杂，并且性能和高可用性等各方面表现一般，特别是在主从切换的瞬间存在访问瞬断的情况，而且哨兵模式只有一个主节点对外提供服务，没法支持很高的并发，且单个主节点内存也不宜设置得过大，否则会导致持久化文件过大，影响数据恢复或主从同步的效率。
Redis-Sentinel是Redis官方推荐的针对主从结构的高可用性解决方案，当master不可用，sentinel能监控多个master-slave集群，发现master宕机后能进行自动切换。
由于无法进行主动恢复，因此主从模式衍生出了哨兵模式。哨兵模式基于主从复制模式，只是引入了哨兵来监控与自动处理故障。Redis Sentinel是社区版本推出的原生高可用解决方案，Redis Sentinel部署架构主要包括两部分：Redis Sentinel集群和Redis数据集群，其中Redis Sentinel集群是由若干Sentinel节点组成的分布式集群，可以实现故障发现、故障自动转移、配置中心和客户端通知。Redis Sentinel的节点数量要满足2n+1（n>=1）的奇数个。
实现了Redis的主从复制，在一定程度上保证了数据的可用性，但是如果主从复制中的master 节点挂掉，Redis将不再对外提供读写操作。假设当主从复制中的master节点挂掉后，如果能够从它的slave节点中重新选举一个节点作为master节点，那么系统就可以恢复了，因此就有了Redis的哨兵（sentinel）模式。
Redis 的 主从复制 模式下，一旦 主节点 由于故障不能提供服务，需要手动将 从节点 晋升为 主节点，同时还要通知 客户端 更新 主节点地址，这种故障处理方式从一定程度上是无法接受的。Redis 2.8 以后提供了 Redis Sentinel 哨兵机制 来解决这个问题。
上一篇我们介绍了 redis 主从节点之间的数据同步复制技术，通过一次全量复制和不间断的命令传播，可以达到主从节点数据同步备份的效果，一旦主节点宕机，我们可以选择一个工作正常的 slave 成为新的主节点，并让其他 slave 去同步它。
当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用。 所以更多时候，我们优先考虑哨兵(sentinel) 模式。
此篇的前置原理为,需要能安装REDIS 服务器,并且配置主从关系, Redis 有两种高可用, redis cluster 和 redis sentinel , 今天要说的是redis 的 sentinel, redis sentinel 是从redis 2.8开始提供的一个redis 高可用的功能,这里有几个问题
哨兵（Sentinel）是 redis 的高可用性解决方案，前面我们讲的主从复制它是高可用的基础，需要人工介入才能完成故障转移，哨兵可以解决这个问题，在主从复制情况下，当主节点发生故障时，哨兵可以自动的发现故障并且完成故障转移，实现真正的 redis 高可用。在哨兵集群中，哨兵会监视所有的 redis 服务器和其他 sentinel 节点状态，来保证 redis 的高可用。
流控降级中间件 Sentinel 1.7.0 版本正式发布，引入了 Envoy 集群流量控制支持、properties 文件配置、Consul/Etcd/Spring Cloud Config 动态数据源适配等多项新特性与改进。详细特性列表请参考 Release Notes，欢迎大家使用并提出建议。
在主从模式下（主从模式就是把上图的所有哨兵去掉），master节点负责写请求，然后异步同步给slave节点，从节点负责处理读请求。如果master宕机了，需要手动将从节点晋升为主节点，并且还要切换客户端的连接数据源。这就无法达到高可用，而通过哨兵模式就可以解决这一问题。
一、sentinel哨兵模式介绍 Sentinel(哨兵)是用于监控redis集群中Master状态的工具，是Redis 的高可用性解决方案，sentinel哨兵模式已经被集成在redis2.4之后的版本中。sentinel是redis高可用的解决方案，sentinel系统可以监视一个或者多个redis master服务，以及这些master服务的所有从服务；当某个master服务下线时，自动将该master下的某个从服务升级为master服务替代已下线的master服务继续处理请求。
这可能是我看过的写的最详细的关于redis 选举的文章了， 原文链接 Raft协议是用来解决分布式系统一致性问题的协议，在很长一段时间，Paxos被认为是解决分布式系统一致性的代名词。但是Paxos难于理解，更难以实现，诸如Google大牛们开发的分布式锁系统Chubby都遭遇了很多坑。Raft协议设计的初衷就是容易实现，保证对于普遍的人群都可以十分舒适容易的去理解。另外，它必须能够让人形成直观的认识，这样系统的构建者才能够在现实中进行必然的扩展。 本文从Redis Sentinel集群选择Leader的具
Sentinel 是 Redis 集群中的哨兵角色，它的作用是对 Redis 集群中的主节点和从节点进行监控和管理。
本期原本计划是写些redis高可用架构选型，分析，及实战，发现篇幅过长，所以拆开来写了。这期先讲一些官方提供的高可用功能，主从，sentinel，以及redis cluster。
redis-server /path/to/sentinel.conf --sentinel
前面的文章讲述了redis sentinel实现原理当中的定时任务、主观下线和客观下线，今天我们来看sentinel领导者选举以及故障转移部分。
Sentinel（哨兵）是Redis 的高可用性解决方案：通过哨兵可以创建一个当主服务器出现故障时自动将从服务器升级为主服务器的一个分布式系统。解决了主从复制出现故障时需要人为干预的问题。 这篇介绍哨兵的搭建，以及哨兵是如何进行哨兵发现和主从切换等功能。
sentinel是一个分布式系统，可以在一个架构中运行多个sentinel进程，这些进程使用流言协议（gossip protocols）来接收关于rdis主服务器是否下线的信息，并使用投票协议（agreement protocols）来决定是否执行自动故障迁移，以及选举哪个从服务器成为新的主服务器。
关于Redis高可用方案，看到较多的是keepalived、zookeeper方案。 keepalived是主备模式，意味着总有一台浪费着。zookeeper工作量成本偏高。 本文主要介绍下使用官方sentinel做redis高可用方案的设计。 阅读目录： Redis Sentinel 故障转移消息接收的3种方式 整体流程图 总结 Redis Sentinel Sentinel介绍 Sentinel是Redis官方为集群提供的高可用解决方案。 在实际项目中可以使用sentinel去做redis自动故障转移，
主从(MASTER-SLAVE) : 一主多从, 读写分离,提高性能,从节点做备份更方便. 但是主节点挂了,就无法写.
CAP理论：一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。 Redis选择了AP，牺牲了C。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
云直播
对象存储
