【redis】Redis 主从复制、哨兵（Sentinel）和集群（Cluster）

前置文章：
(一)使用docker安装redis、常用五大基本数据类型、Jedis操作Redis、Spring整合Redis

(二)docker安装redis、非docker安装，集群启动

本文记录一些学习redis集群时产生的疑问

集群可以配置哨兵来进一步监控和管理主节点和从节点

• 在 Redis集群中，还可以配置哨兵（Sentinel）来进一步监控和管理主节点和从节点，以提高故障恢复的可靠性和自动化程度。哨兵可以在主节点下线时自动进行故障转移。

疑惑：集群不是可以在超过节点失联时间时自动实现主从切换吗，为什么这段话还提出集群要配置哨兵来实现自动故障转移呢？

在 Redis 集群中，当主节点失联时，集群本身是能够自动进行故障转移的，从而选择一个从节点升级为新的主节点。这是因为 Redis 集群具备自动发现、故障检测和故障转移的机制。

然而，虽然 Redis 集群能够处理主节点的故障转移，但是这个过程可能会有一些延迟。当主节点失联时，Redis集群需要一些时间来检测主节点的失联情况，然后选举一个新的主节点，这个过程可能需要数秒到数十秒不等的时间。在这段时间内，客户端可能无法连接到一个可用的主节点，从而导致一段时间的不可用。

为了进一步提高 Redis 集群的可靠性和自动化程度，以及减小故障发生时的延迟，可以配置哨兵（Sentinel）。哨兵是一个独立的Redis 进程，它的作用是监控 Redis集群中的主节点和从节点的健康状态。当哨兵检测到主节点失联时，它可以立即进行故障转移，选择一个可用的从节点升级为新的主节点。这可以减小故障发生时的停机时间，并提供更快速的故障转移。

因此，尽管 Redis 集群本身可以自动进行故障转移，但配置哨兵可以增加故障转移的自动性和速度，以提高集群的可靠性和可用性。哨兵可以监控Redis 集群中的多个主节点，并在需要时触发故障转移，以确保集群在主节点失联时能够快速恢复。这是为了提供额外的保障，以防止在某些情况下Redis 集群的自动故障转移不够及时或无法满足特定要求。因此，建议在关键生产环境中使用 Redis集群时，配置哨兵以提高可靠性和自动化程度。

redis集群里面也可以配置三主节点和三个从节点，那么redis主从和集群的区别是什么呢？集群的三主三从可以支持故障转移和自动恢复，主节点下线时会自动选择从节升级为主节点？这不也是主从结构吗？集群具体体现在了哪里？为什么主从就不可以自动故障转移？

Redis集群和Redis主从复制是两种不同的架构，它们解决了不同的问题，并具有不同的特性和用途。

1. Redis主从复制：

   • 主从复制是一种数据备份和读写分离的架构。在主从架构中，有一个主节点（Master）和一个或多个从节点（Slave）。
   • 主节点负责写入和读取数据，而从节点负责复制主节点的数据，从而提供了数据冗余和读取的负载均衡。
   • 主从复制主要用于数据备份、提高读取性能、实现故障恢复等方面，但它通常不支持自动的主节点故障转移。如果主节点宕机，需要手动干预来将一个从节点提升为新的主节点。

2. Redis集群：

   • Redis集群是用于分布式存储和高可用性的架构。它由多个节点组成，通常包括多个主节点和从节点，这些节点分散在不同的物理或虚拟机器上。
   • Redis集群具备自动数据分片和数据复制的功能，可以水平扩展，使得它可以处理大规模的数据和高并发负载。
   • Redis集群支持自动的故障转移。当一个主节点宕机时，Redis集群会自动选择一个从节点提升为新的主节点，而不需要手动干预。这确保了高可用性和数据的连续性。

总结一下，Redis主从复制主要用于备份和读写分离，但不支持自动主节点故障转移。相比之下，Redis集群是一个分布式的、支持高可用性的架构，它可以自动进行故障转移和数据重分布，适用于大规模应用和高可用性要求。

所以，虽然Redis主从复制也可以配置多主多从，但其主要用途是备份和读写分离，故障转移通常需要手动干预。而Redis集群是专门设计用于高可用性和分布式存储的架构，具备自动故障转移和数据分布的特性。

为什么redis集群最少是三个主机？为何主机个数不建议为偶数？

Redis 集群的最少三个主机和不建议偶数主机的原因如下：

1. 容忍故障：Redis 集群通常要求至少有一个主节点在正常工作，以容忍故障。如果只有两个主节点，当一个主节点出现故障时，整个集群可能会无法工作。而如果有三个主节点，即使一个主节点出现故障，其他两个仍然可以继续工作，确保了高可用性。
2. 避免脑裂问题：假设你有两个主节点，如果它们在网络分区（网络故障或延迟等）的情况下互相不可访问，就可能导致脑裂问题。这是因为两个节点都认为自己是主节点，同时处理写入请求，导致数据不一致。在一个三个节点的集群中，当出现网络问题时，多数派规则可以用来决定哪个节点成为主节点，从而避免脑裂问题。
3. Quorum：在 Redis 集群中，Quorum（多数派）决定了一个写操作是否被接受。Quorum 的计算方式是 (M / 2) + 1，其中 M 是主节点的数量。如果 M 是偶数，计算结果将是小数，这可能导致决策出现问题。例如，如果有四个主节点，(4 / 2) + 1 结果为 3，这意味着至少需要三个主节点同意写入操作才能被接受。如果有三个主节点，(3 / 2) + 1 结果为 2，这确保了更可靠的 Quorum 决策。

综上所述，使用三个主节点可以确保更好的容错性、避免脑裂问题和更可靠的 Quorum 决策。虽然可以使用偶数个主节点，但为了获得更好的可靠性，通常会选择奇数个主节点。

主从复制存在哪些问题呢？

主从复制虽好，但也存在一些问题：

一旦主节点出现故障，需要手动将一个从节点晋升为主节点，同时需要修改应用方的主节点地址，还需要命令其他从节点去复制新的主节点，整个过程都需要人工干预。
主节点的写能力受到单机的限制。
主节点的存储能力受到单机的限制。
第一个问题是Redis的高可用问题，第二、三个问题属于Redis的分布式问题。

集群就是终极方案，一举解决高可用和分布式问题。

数据分区： 数据分区 (或称数据分片) 是集群最核心的功能。集群将数据分散到多个节点，一方面 突破了 Redis 单机内存大小的限制，存储容量大大增加；另一方面 每个主节点都可以对外提供读服务和写服务，大大提高了集群的响应能力。
高可用： 集群支持主从复制和主节点的 自动故障转移（与哨兵类似），当任一节点发生故障时，集群仍然可以对外提供服务。

什么是redis的集群脑裂？

Redis 中的脑裂是什么？
从名字分析，脑裂现象就是大脑裂开了，一个人如果有两个大脑，就出现了两个决策者，此时身体就不知道该听谁的了，势必会造成混乱。

对应到 Redis 上，就是指在主从集群中，同时有两个主节点，它们都能接收写请求，那么什么时候会出现这种情况呢？

就是如果当前主库突然出现暂时性 “失联”，而并不是真的发生了故障，此时监听的哨兵会自动启动主从切换机制。当这个原始的主库从假故障中恢复后，又开始处理请求，但是哨兵已经选出了新的主库，这样一来，旧的主库和新主库就会同时存在，这就是脑裂现象。

脑裂有什么影响？
脑裂最直接的影响，就是客户端不知道应该往哪个主节点写入数据，结果就是不同的客户端会往不同的主节点上写入数据。严重的话，脑裂会进一步导致数据丢失。也就是说，等到哨兵让原主库和新主库做全量同步后，原主库在切换期间保存的数据就丢失了。

详细点来说，当主从切换后，从库升级为新主库，原主库和新主库会重新进行数据的全量同步，在这个过程中会发生数据的丢失。

如何解决脑裂问题？
Redis 中有两个关键的配置项可以解决这个问题，分别是 min-slaves-to-write（最小从服务器数） 和 min-slaves-max-lag（从连接的最大延迟时间）。

min-slaves-to-write 是指主库最少得有 N 个健康的从库存活才能执行写命令。

这个配置虽然不能保证 N 个从库都一定能接收到主库的写操作，但是能避免当没有足够健康的从库时，主库无法正常写入，以此来避免数据的丢失 ，如果设置为 0 则表示关闭该功能。

min-slaves-max-lag ：是指从库和主库进行数据复制时的 ACK 消息延迟的最大时间；

可以确保从库在指定的时间内，如果 ACK 时间没在规定时间内，则拒绝写入。

这两个配置项组合后的要求是，主库连接的从库中至少有 N 个从库，和主库进行数据复制时的 ACK 消息延迟不能超过 T 秒，否则，主库就不会再接收客户端的请求了。

这样一来，即使原主库是假故障，它在假故障期间也无法响应哨兵发出的心跳测试，也不能和从库进行同步，自然也就无法和从库进行 ACK 确认了。

此时的 min-slaves-to-write 和 min-slaves-max-lag 的组合要求就无法得到满足，原主库就会被限制接收客户端请求，客户端也就不能在原主库中写入新数据，就可以避免脑裂现象的发生了。