redis哨兵实现redis高可用（redis主从哨兵集群优缺点）

副件是指用于备份或复制的原始数据的副本。在Redis中，实现高可用主要涉及到主从模式、哨兵模式和集群模式三种部署方式。每一种方式都有其独特的优势和应用场景。

高可用性的核心在于确保数据的完整性和服务的持续性。为了确保这一点，Redis提供了多种部署模式来满足不同的业务需求。其中，主从模式是最基础的高可用部署方式。

一、主从模式

在主从模式下，Redis数据库被复制并部署到多个服务器上，以实现数据的冗余备份。Master节点负责处理读写操作，而Slave节点只负责读操作。这种读写分离的方式有效地分散了服务器的负载，提高了系统的整体性能。当Master节点出现故障时，可以快速地切换到其他Slave节点，从而保证服务的可用性。

主从复制的原理在于，所有的写操作只在Master节点上进行，然后Master节点将的数据同步给Slave节点。这一过程包括全量复制、增量复制和部分同步三种方式。

全量复制主要用于Slave节点初次连接Master节点时的数据初始化。增量复制则是在Slave节点初始化后开始正常工作时，Master节点的写操作实时同步到Slave节点的过程。而部分同步则是在redis 2.8版本后引入的一种更高效的数据同步方式，它可以在主从连接中断后，避免全量同步，只同步部分数据，从而提高系统的恢复效率。

二、哨兵模式和集群模式

除了主从模式，Redis还提供了哨兵模式和集群模式来实现更高的可用性。哨兵模式是一种自动故障切换的解决方案，它可以监控Redis实例的运行状态，并在Master节点出现故障时自动进行故障转移。集群模式则通过分片技术将数据分布到多个Redis节点上，提高了数据的可用性和可扩展性。

Master节点接收到psync命令并审视当前服务器状态时，它将决定执行全量复制还是部分复制。当Slave节点的runID与Master节点的runID相匹配，且其发送的slave_repl_offset之后的数据仍存储在repl_backlog_buffer缓冲区时，Master节点将回应CONTINUE，表示将进行部分复制。这时，Slave节点只需等待Master节点发送其缺失的数据即可。

当Slave节点的runID与Master节点的runID不一致，或者其发送的slave_repl_offset之后的数据已从Master节点的repl_backlog_buffer缓冲区中消失（被队列中的新数据挤出），Master节点将回应FULLRESYNC，并附带新的runID和offset。Slave节点需保存这两个值以备后用。

当Slave库与Master库断连时间过长，导致其在Master库repl_backlog_buffer中的slave_repl_offset位置的数据被覆盖时，Slave库和Master库间将进行全面复制。

关于主从模式的优缺点：

优点：

主从模式实现了读写分离，极大地提高了服务器性能。Salve节点可以分担Master节点的读操作压力，而写服务仍由Master节点独立完成。当Master节点服务出现故障时，可以选择让Slave节点变成Master节点继续提供服务。

缺点：

主从模式在Master节点故障时，需要人工将Slave节点晋升为Master节点，并通知应用方更新Master节点地址。这在许多业务场景中是无法接受的。由于Redis的Master节点和Slave节点数据相同，虽然提供了数据备份，但同时也降低了内存的可用性，并且存储能力有限。写操作主要在Master节点进行，因此写的压力并没有得到有效减轻。主从复制模式在高可用性的要求下显得捉襟见肘。

为了解决主从模式中的痛点，Redis从2.8版本开始引入了Redis Sentinel（哨兵）架构。哨兵模式由多个Sentinel实例组成，可以监控所有的Master节点和Slave节点。当被监控的Master节点出现故障时，Sentinel系统能自动将某个Slave节点升级为新的Master节点。每个Sentinel实例都是特殊的redis实例，不存储数据，只负责集群的监控。哨兵模式的主要作用包括监控Redis服务器的运行状态、自动切换故障Master节点以及通过发布订阅模式通知其他Slave节点修改配置。为了确保高可用，可以使用多个Sentinel实例进行监控，它们之间也会相互监控。哨兵的主要工作是通过三个定时监控任务来完成对各节点的发现和监控。

哨兵节点的核心任务

哨兵节点每10秒向Master节点和Slave节点发送命令，获取的拓扑结构图。仅需配置对Master节点的监控，哨兵便能通过向Master节点获取信息，感知到Slave节点的动态，一旦有新的Slave节点加入，即刻察觉。

每隔2秒，每个哨兵节点会在redis数据节点的指定频道上发布关于Master节点的判断及自身信息。它们也会订阅这个频道，以获取其他哨兵节点的观点及信息。这一切都是通过消息的publish和subscribe完成的。

哨兵节点的心跳检测是每秒钟一次的ping命令。这不仅是对Master节点和Slave节点进行健康检查的重要手段，也是哨兵判断节点状态的关键依据。

当服务下线时，哨兵的主观与客观判断尤为关键。主观下线是指当哨兵节点检测到Master或Slave节点、其他哨兵节点的心跳丢失，超过一定阈值时，认为该节点可能出现问题。但这并不绝对，可能存在误判。而客观下线则更为严谨，当多个哨兵节点都确认某个Master节点出现问题时，该Master节点便被认定为客观下线。

一旦Master节点客观下线，自动故障转移机制启动。需要选举一个哨兵领导者。每个希望成为领导者的哨兵节点会发送特定的命令给其他哨兵节点。当某个哨兵节点获得超过半数且超过法定人数的同意时，它将成为领导者。接下来，从下线Master节点的从节点中挑选新的Master。这个过程考虑了节点的主观状态、优先级、复制偏移量等因素。通过特定的命令更新主从状态，让选出的Slave节点成为新的Master节点，其他节点则成为其Slave节点。已下线的Master节点在恢复后，将作为新Master节点的Slave节点进行复制。

我们还需要警惕脑裂现象。当Master节点因某种原因与其他节点失去连接，但仍在运行时，可能会出现两个Master的情况。这可能导致数据丢失或不一致。为了防止这种情况，我们需要确保网络的稳定性，并及时更新和维护集群状态。

哨兵节点的核心任务是监控和维护Redis集群的健康状态，确保数据的完整性和一致性。通过心跳检测、信息交换和故障转移机制，哨兵节点能够在集群出现问题时迅速作出反应，保证Redis集群的高可用性。在一个旧时代的背景下，我们遇到了一个熟悉的场景。每当老旧的master需要恢复时，它仿佛就成了新手slave的一员，需要被牵引至新的master身边。这是一个历经洗礼的数据旅程，因为在这种转变中，旧master的数据将被清空，重新从新的master那里复制数据。这其中存在一个遗憾的问题：那些后来才被客户端写入的数据在新master这里并未留下痕迹，因此这部分数据也就永远地失去了。

那么，我们该如何解决这种“脑裂”问题呢？Redis为我们提供了两大配置利器：min-slaves-to-write和min-slaves-max-lag。这两个配置就像是数据安全的守护者，它们联手确保至少有一个slave存在，并且数据复制和同步的延迟在可控范围内。如果延迟超过了这个界限，那么master将停止接收任何请求，以此保证数据的完整性和一致性。这样，即使出现了所谓的假故障，也能及时遏制数据的进一步损失。这种配置并不能让数据完全不丢失，但它的确能让数据丢失的可能性降到最低。

接下来，让我们深入一下哨兵模式的优缺点。哨兵模式继承并放大了主从模式的所有优点，自动切换、系统健壮性、高可用性都是它的标签。它也有自己的短板。每台机器上的数据都是冗余的，这无疑降低了内存的可用性。哨兵模式的维护相对复杂，增加了系统的维护成本。当集群容量达到上限时，在线扩容会变得异常复杂。

再来看Redis的Cluster集群模式。这里有一个常见的误区需要澄清：Redis的集群模式并没有采用一致性hash算法，而是引入了slots插槽的概念。为什么这么做呢？我个人认为，固定数量的插槽使得数据迁移变得更加方便和可控。哨兵模式虽然实现了读写分离和自动切换，但在Redis3.0之后，Cluster集群模式的出现让Redis实现了分布式存储。每台Redis节点上存储不同的内容，这一创新解决了在线扩容的问题。

Cluster模式下，一个Redis Cluster由多个Redis节点构成，这些节点分为主要的主节点和备用的从节点。数据在这两者间进行准实时同步。每个节点组只有一个master节点，但可以有多个slave节点。为了保持高可用，一般至少需要6个节点来构建一组集群。这些master节点负责分配不同的slot来存储数据。当某个master出现故障时，其对应的slave会自动接管成为新的master，确保服务的连续性。

redis cluster模式的一大特点是采用了无中心节点的方式，每个Master节点都与其他Master节点保持连接。它们之间通过gossip协议交流信息。客户端在连接集群时，会根据特定的hash算法将数据存储在不同的哈希槽上。整个集群被分为16384个哈希槽，每个Master节点负责其中的一部分。这种数据分片的方式确保了数据的高可用性。当某个Master节点出现故障时，集群能够自动进行故障转移和处理。

Redis的Cluster集群模式为我们提供了一个高效、可靠的数据存储解决方案。它实现了Redis的分布式存储、读写分离和自动切换功能，确保了数据的高可用性和系统的健壮性。优化后的文章如下：

关于Redis主从哨兵集群与gossip协议的

在分布式系统中，Redis主从哨兵集群和gossip协议扮演着至关重要的角色。将深入其工作原理、特点以及优缺点。

一、Redis主从哨兵集群的工作原理及特点

在Redis主从复制的基础上，哨兵集群负责对主节点进行监控，并在主节点出现故障时自动进行故障转移，确保集群的高可用性。当Master节点发生故障时，会立即进行主从切换，使得Slave节点升级为新的Master节点，保证了服务的连续性。值得注意的是，如果Master节点没有Slave节点，那么集群将面临不可用状态。合理的节点配置对于哨兵集群的稳健性至关重要。

二、节点的动态上线与扩容问题

在Redis集群中，节点的动态上线是确保集群扩展性的关键。当新节点加入集群时，会通过gossip协议与其他节点进行握手，并获取集群的其他节点信息。然后，哈希槽会被重新分配，确保数据的高可用性。例如，每个Master节点负责特定的哈希槽范围，当新节点加入时，这些槽会被分配到新节点上。同样，当需要删除节点时，只需将节点的哈希槽迁移到其他节点即可。

三、gossip协议的解读

gossip协议，也被称为Epidemic Protocol或流行病协议，是Redis集群中节点间状态传播的关键机制。当出现新节点加入、节点宕机或Slave选举成为master等情况时，gossip协议能够确保这些变化迅速传播到整个集群，并使所有节点达成一致状态。它的工作原理是节点间相互连通并携带相关状态数据进行传播。由于广播方式会导致过多的CPU和带宽消耗，因此采用了gossip协议进行更高效的数据同步。

四、gossip协议的细节与特点

gossip协议包含多种消息类型，如ping、pong、meet和fail等。每个节点都会频繁发送ping消息，其中包含自己的状态和集群元数据，通过互相交换ping消息来更新元数据。新节点通过meet消息加入集群，并开始与其他节点通信。当某个节点判断另一个节点失败时，会发送fail消息通知其他节点。gossip协议的优点在于去中心化、可扩展、容错、一致性收敛和简单。由于元数据的更新比较分散，压力较低。元数据的更新有一定的延时可能导致集群操作滞后。消息的延迟和冗余也是其缺点之一。

五、Redis主从哨兵集群与gossip协议的优缺点

Redis主从哨兵集群确保了高可用性，并通过哨兵对主节点进行监控和故障转移。合理配置Slave节点数量是确保集群稳定性的关键。另一方面，gossip协议使得集群中的状态变化能够迅速传播，并在节点间达成一致状态。其优点在于去中心化、可扩展、容错和简单。由于元数据的更新有延时和消息的延迟冗余等缺点，需要注意其在实际应用中的影响。

Redis主从哨兵集群与gossip协议共同构成了Redis分布式系统的高可用性基石。深入理解其工作原理、特点以及优缺点，对于构建稳健的Redis集群至关重要。