redis集群理论详解

一. Redis集群发展历程

本片文章只介绍集群理论知识，不包含Redis集群搭建教程
教程文章请点击docker搭建redis集群（三主三从）

阶段一：单机版Redis

• 优点：
  • 简单：易于部署和使用，适合小型项目或初期阶段的应用。
• 缺点：
  • 单点故障：整个系统的稳定性依赖于单一实例的运行状况，一旦该实例出现问题，可能导致服务中断。
  • 容量限制：受限于单台服务器的内存容量，难以处理大规模数据。
  • 并发处理能力不足：面对高并发访问时，性能可能迅速下降。

阶段二：主从复制

• 背景：
  • 为了解决单机版Redis的单点故障问题，并提升读操作的负载能力。
• 优点：
  • 提高了数据冗余度：通过将数据同步到一个或多个从节点上，增加了数据的安全性。
  • 增强了读取性能：可以配置多个从节点来分担读请求，减轻主节点的压力，提高整体读性能。
• 缺点：
  • 写操作仍然是瓶颈：所有写入操作都需要在主节点完成，因此无法通过增加从节点来扩展写入性能。
  • 故障转移复杂：当主节点出现故障时，需要手动进行故障切换，这期间服务可能会暂时中断。

阶段三：哨兵（Sentinel）模式

• 背景：
  • 为了自动化主从复制中的故障检测与恢复过程，提供更高的可用性。
• 优点：
  • 自动故障转移：能够在检测到主节点不可用时自动选择一个从节点升级为主节点，减少人工干预，提高系统的可靠性和可用性。
• 缺点：
  • 不支持水平扩展：虽然提高了可用性，但每个节点都存储了全量数据，对于数据存储容量和并发处理能力方面没有实质性的改进。
  • 复杂性增加：相对于简单的主从结构，配置和维护变得更加复杂。

阶段四：Redis Cluster

• 背景：
  • 面对更大规模的数据存储需求和更高的并发访问量，需要一种既能保证数据安全又能实现线性扩展的解决方案。
• 优点：
  • 数据分布与扩展性：通过哈希槽机制实现了数据的分布式存储，支持动态添加或移除节点以适应业务增长的需求。
  • 高可用性：结合了主从复制与自动故障转移的优点，提供了更高层次的服务连续性。
• 缺点：
  • 部署和运维成本上升：复杂的架构设计使得部署、管理和监控都更加困难。
  • 某些命令限制：由于数据分布在不同节点上，部分涉及多键的操作受到限制。

二. Redis Cluster详解

（一）数据分片

1. 基本概念

在Redis Cluster中，数据分片是通过将整个键空间分割成多个部分（称为哈希槽或hash slots），每个部分可以独立地存储在一个节点上。这样做的主要目的是为了支持分布式数据存储和处理大规模数据集。

• 哈希槽（Hash Slots）：Redis Cluster使用16384个哈希槽来分割数据。这意味着任何给定的键都属于这16384个哈希槽中的一个。
• 分配方式：集群中的每个节点负责一部分哈希槽。例如，如果有三个节点，可能节点A负责0到5460号哈希槽，节点B负责5461到10922号哈希槽，而节点C负责剩余的哈希槽。

2. 键到哈希槽的映射

Redis Cluster通过以下步骤确定一个键应该被存储在哪一个哈希槽中：

• 计算CRC16校验和：首先对键进行CRC16校验和计算。
• 取模运算：然后将得到的校验和结果对16384取模，得到的结果就是该键所属的哈希槽编号。
  hash_slot = CRC16(key) % 16384
  这个过程确保了所有键能够均匀分布在16384个哈希槽之间。

什么是校验和？

校验和是一种用于检测数据传输或存储过程中是否发生错误的技术。它通过对数据进行某种数学运算生成一个固定长度的数值，这个数值被称为校验和。接收方可以使用相同的算法重新计算接收到的数据的校验和，并将其与发送方提供的校验和进行比较。如果两者一致，则认为数据在传输或存储过程中没有发生错误；如果不一致，则表明数据可能已被损坏或篡改。
常见的校验和算法包括CRC（循环冗余校验）、MD5（消息摘要算法5）、SHA-1（安全哈希算法1）等。每种算法都有其特定的应用场景和优缺点。
CRC16是一种具体的循环冗余校验算法，它生成一个16位的二进制数作为校验和。CRC16广泛应用于各种通信协议中，如以太网、串行通信等，用于确保数据的完整性和准确性。

3. 节点与哈希槽的关系

每个节点管理着一部分哈希槽。这意味着如果要查找或修改某个键，首先需要知道它对应的哈希槽，然后根据哈希槽找到相应的节点。这种设计使得：

• 负载均衡：通过合理分配哈希槽到不同的节点上，可以实现数据的均匀分布，避免某些节点过载。
• 水平扩展：当需要增加系统容量时，可以通过重新分配哈希槽的方式添加新的节点，并将部分哈希槽迁移到新节点上。

4. 实际操作示例

假设我们有一个包含三个节点的Redis Cluster，每个节点分别负责一组哈希槽。如果我们想要插入一个键user:1000，那么：

• 计算user:1000的CRC16校验和。
• 对校验和结果进行取模运算得到哈希槽编号。
• 根据哈希槽编号找到对应的节点，并在该节点上执行实际的数据插入操作。

5. 数据迁移与再平衡

随着数据的增长或者节点故障恢复后的调整，可能需要对哈希槽进行重新分配以达到更好的负载均衡。Redis Cluster支持在线迁移哈希槽，即可以在不影响服务的情况下将某些哈希槽从一个节点移动到另一个节点。

• ASK重定向：在哈希槽迁移过程中，客户端可能会收到ASK重定向响应，指示临时访问特定键所在的临时位置。
• MOVED重定向：一旦哈希槽完全迁移完毕，后续请求会直接收到MOVED重定向，告知客户端正确的节点地址。

（二）集群通信机制

在Redis Cluster中，集群中的每个节点通过Gossip协议和心跳机制保持彼此的连接和状态同步。节点之间通过TCP连接互相交换信息，确保集群的整体健康和数据一致性。

1. Gossip协议

Gossip 协议是一种去中心化的消息传播机制，它通过节点之间的周期性随机对等通信来传播信息。在 Redis Cluster 中，每个节点都会定期与其他节点交换关于整个集群状态的信息，包括哪些节点在线、哪些节点离线、数据槽(slot)的分配情况等。

优势

• 去中心化：不需要一个中央控制点来管理集群状态，减少了单点故障的风险。
• 容错性：即使部分节点发生故障，剩余的节点仍然可以通过互相通信来维持集群的正常运作。
• 扩展性：随着集群规模的扩大，gossip 协议可以有效地适应并维持高效的通信效率。
• 最终一致性：尽管在某一时刻不同节点可能持有不同的集群视图，但随着时间推移，所有节点将趋向于拥有相同的信息。

感染规则

Gossip 的感染过程类似于病毒传播的方式。每个节点会随机选择集群中的其他一些节点，并向它们发送自己的当前状态信息（如节点列表、健康状况等）。接收这些信息的节点会根据接收到的数据更新自己的状态，并在下一轮通信中继续传播更新后的信息。通过这种方式，新的或变化的信息能够逐渐扩散到整个集群。

2. 心跳机制

心跳机制用于检查集群中各个节点是否在线，并确保节点之间的连接持续有效。每个节点定期向其他节点发送心跳信号，若心跳信号丢失或超时，节点会被认为是失效状态。

• 节点监控：节点通过心跳机制定期监控集群内的其他节点，检测节点是否存在故障。心跳丢失通常表示网络故障或节点崩溃，需要触发故障检测和恢复机制。
• 故障恢复：当心跳信号失败时，集群会认为该节点已不可用，并采取措施将该节点从集群中排除或转为备用状态。

3. 数据同步

在Redis
Cluster中，当某个节点（主节点或从节点）失效或重新加入集群时，系统会自动进行必要的数据迁移和复制操作，以确保整个集群的数据一致性和高可用性。

• 主从同步：

  • 当主节点失效时，集群会选择一个从节点升级为新的主节点。

  • 原故障主节点的其他从节点需要与新的主节点同步数据。这可以通过两种方式进行：

    • 部分重同步：如果条件允许（例如，复制积压缓冲区包含所需数据且服务器运行ID未变），则仅传输断开期间丢失的数据，这种方式更高效。
    • 全量重同步：如果无法进行部分重同步，则需传输全部数据，包括生成RDB文件及传输后续写命令，虽然耗时较长但确保数据一致性。

  • 新加入的从节点：

    • 首次连接时，新从节点会通过全量重同步来获取完整的数据集，包括从主节点接收RDB文件及自开始复制以来的所有写命令。
    • 完成初始同步后，该从节点将保持与主节点的持续连接，实时接收所有更新，确保数据一致性。
    • 在之后的重新连接中，如果满足特定条件（如复制积压缓冲区足够大且包含必要的数据），则可以从部分重同步开始，从而提高效率。

（三）跳转重定向

在Redis Cluster中，由于数据分布在不同的节点上，客户端请求某个键的数据时，可能需要重定向到不同的节点。Redis Cluster通过跳转重定向机制来确保客户端能够访问正确的节点。

1. MOVED重定向

MOVED重定向是在哈希槽完全迁移后，Redis Cluster告知客户端该请求的键已经完全迁移到另一个节点的机制。该重定向是永久性的，不需要再次跳转。

• 哈希槽迁移完毕：当哈希槽迁移完成后，所有请求该哈希槽的数据都会被重定向到新的目标节点。客户端会收到MOVED响应，并知晓正确的目标节点地址。
• 客户端操作：在收到MOVED重定向时，客户端可以直接访问目标节点，不需要进行任何额外的跳转操作。

2.ASK重定向（用于迁移状态）：

在Redis Cluster中，数据分布于多个节点上，通过16384个槽来管理数据的分配。当需要对集群进行扩展或维护时，可能会涉及到槽的重新分配，即从一个节点向另一个节点迁移部分槽的数据。在这个过程中，部分数据可能已经在目标节点上可用，而另一部分仍留在源节点。

• 当客户端尝试访问正处于迁移状态的槽时，当前负责该槽的节点不会立即返回MOVED错误，而是返回一个ASK响应。这个响应包含两个信息：
  1.目标槽号。
  2.负责接收这次请求的临时节点地址（IP和端口）。
• ASKING命令：为了执行ASK重定向，客户端首先需要向目标节点发送ASKING命令，然后客户端再次发送操作命令（如GET或SET）

3. 客户端的处理

在Redis Cluster环境中，客户端必须能够智能地响应ASK或MOVED重定向，以确保请求被发送到正确的节点。这要求客户端支持集群模式，并具备处理这些重定向的能力。

• 重定向的自动处理：
  现代的Redis客户端通常内置了对ASK和MOVED重定向的支持。当收到这样的响应时，客户端会自动解析出目标节点的信息（包括IP地址和端口），然后重新发送原始请求到指定的目标节点。

  • 对于MOVED响应，客户端除了重新发送请求外，还会更新其内部的槽到节点映射表，这样后续针对相同槽的请求将直接发送到正确的节点，无需再次经历重定向过程。
  • 对于ASK响应，客户端仅对该特定请求执行一次临时重定向，通过首先发送ASKING命令告知目标节点接受此次请求，然后再执行实际的操作命令。此操作不会影响客户端内部的槽到节点映射。

• 集群模式：
  在集群模式下，客户端需要维护一个当前集群状态的视图，包括所有节点的信息及其负责的槽。这使得客户端可以有效地路由请求至正确的节点，减少不必要的网络跳转。此外，客户端还需要监听集群拓扑的变化（如通过CLUSTER NODES命令或订阅相关的通知频道），以便及时更新本地缓存的集群状态，确保高效率的数据访问。

（四）选举策略

Redis Cluster通过选举机制来确保集群中的高可用性，尤其是在主节点发生故障时，能够快速选举新的主节点并进行故障转移。

1. 主节点故障检测

Redis Cluster使用节点间的心跳机制以及Gossip协议来检测主节点是否失效。如果某个节点未能及时响应心跳或出现长时间失联的情况，集群会认为该节点失效，并触发故障转移。

• 故障检测：集群中的其他节点会定期通过心跳检查是否能与主节点通信。如果发现主节点长时间没有响应，则会认为主节点故障。
• Gossip协议：Gossip协议能够迅速传播故障信息，使集群中其他节点及时知晓主节点的失效状态。

2. 选举新的主节点

一旦Redis Cluster检测到主节点故障，集群中的从节点会参与选举，选择一个最合适的从节点升级为主节点。

• 选举过程：通常，Redis Cluster会选择一个拥有最新数据的从节点作为新的主节点。选举会考虑节点的延迟、复制状态、网络健康等因素。
• 数据同步：选举完成后，新的主节点会接管所有原主节点的哈希槽，并开始接受新的写请求。此时，其他从节点会同步新的主节点数据，确保数据一致性。

3. 保证数据一致性

在主节点故障恢复过程中，Redis Cluster会确保新主节点接管之后，数据的一致性得到保证。选举过程中，不会有写操作被执行，直到新主节点准备好。

• 数据同步与一致性：故障转移完成后，Redis Cluster会将新主节点的所有数据同步到其他从节点，确保数据一致性，并避免分布式系统中的数据丢失。
• 恢复过程：故障恢复的过程中，Redis Cluster会将所有相关的哈希槽和数据同步到新的主节点，并继续为客户端提供服务，最大程度地减少服务中断。

4. Redis Cluster选举机制与哨兵模式的不同点

虽然Redis Cluster和Redis Sentinel都提供了高可用性解决方案，但在选举新的主节点时，两者采用了不同的机制。

Redis Sentinel (哨兵模式)

• 外部监控系统：

  • Redis Sentinel 是一个独立运行的系统，用于监控Redis实例的状态，并在检测到故障时进行处理。

• 投票机制：

  • 当Sentinel检测到主节点失效时，它会发起一次选举过程来选择一个新的主节点。
  • 这个过程依赖于Sentinel集群中的多数实例达成一致意见。具体来说，Sentinel通过相互之间的通信和投票来决定哪个从节点应该被提升为主节点。

• 决策过程：

  • Sentinel不仅考虑从节点的数据复制偏移量（即数据的新鲜度），还会评估网络状况、从节点的健康状态等因素。
  • 最终的选择是由大多数Sentinel实例同意的结果，确保了决策的一致性和可靠性。

Redis Cluster

• 内置机制：

  • Redis Cluster的故障检测和选举过程是集群内部自我管理的一部分，不需要外部系统参与。

• 竞争选举：

  • 在Redis Cluster中，一旦某个主节点被认为失效，其从节点将根据一系列标准（如复制偏移量、优先级设置等）自主决定是否提升自己为新的主节点。
  • 各个符合条件的从节点会尝试晋升为主节点。第一个成功完成配置更新并开始接受客户端请求的从节点将成为新的主节点。

• 无需多数同意：

  • 与Sentinel不同，Redis Cluster中的选举并不需要其他节点的明确投票批准。而是基于各个从节点自身的条件和动作来进行。
  • 这种设计使得选举过程更加迅速，减少了由于等待多数同意而可能造成的延迟。