Redis Cluster 基础概述
是什么让 Redis Cluster 脱颖而出
在当今数据量飞速增长以及高并发访问场景愈发常见的大背景下，Redis Cluster 作为 Redis 的分布式解决方案，展现出了诸多独特优势，使其脱颖而出。
首先，Redis Cluster 具备高可用性的特点。它采用多主多从的架构，各个主节点可以挂载多个从节点，当主节点出现故障时，对应的从节点能够迅速顶上，接替主节点的工作，继续对外提供服务，从而保障整个集群的正常运行，最大程度减少因节点故障对业务造成的影响，让数据服务始终保持稳定可用。
其次，有着出色的横向扩展性。随着业务发展，数据量不断增大，单机 Redis 可能会面临内存、性能等方面的瓶颈，而 Redis Cluster 则可以通过简单地增加主节点数量来实现横向扩容，每个主节点都能分担一部分数据存储和处理任务，轻松应对海量数据的存储与高并发读写请求，如同为数据处理能力的提升打开了一扇可以无限拓展的大门。
再者，Redis Cluster 支持自动数据分片。它运用虚拟槽分区的方式，将整个数据空间划分为 16384 个虚拟槽，依据数据的 key 通过特定的哈希算法（如 CRC16 [key] % 16384）来确定该数据应该落入哪个虚拟槽，进而确定存储在负责对应虚拟槽的节点上，这样能够让数据较为均匀地分布在各个节点之中，避免了数据倾斜的问题，提高了数据存储和访问的均衡性。
另外，其配置和管理相对便捷。虽然 Redis Cluster 背后有着复杂的架构和原理，但它提供了诸如集群管理命令等实用的工具，像添加节点、删除节点、重新分布数据等操作，都可以通过相应的命令方便地完成，大大简化了运维人员对集群进行管理和维护的流程，降低了管理成本。
总之，Redis Cluster 凭借这些特点，在应对数据增长和高并发访问场景时发挥着至关重要的作用，接下来我们就深入探讨一下它的架构与实现细节，帮助大家更好地设计高可用的 Redis 集群。
Redis Cluster 架构解析
节点角色与分工
在 Redis Cluster 中，节点有着明确的角色划分，主要分为主节点（Master）和从节点（Slave），它们各司其职，共同保障集群的高效稳定运行。
主节点承担着最为关键的数据读写操作任务。当客户端有写入数据的请求时，主节点负责接收并将数据进行存储；而对于读取数据的请求，主节点同样能够进行相应处理。例如在一个电商系统中，商品的库存信息、用户的订单数据等需要实时写入和读取操作时，都是由主节点来完成这些关键的数据交互工作的。
从节点则主要负责数据备份。它会实时复制主节点的数据，就像是主节点的 “影子” 一样，时刻保持数据的一致性。从节点的存在为集群提供了冗余安全性，当主节点出现故障，比如遭遇硬件故障、网络异常等情况导致无法正常工作时，对应的从节点能够迅速顶上，接替主节点的角色，继续对外提供服务，保障整个集群不会因为某个主节点的问题而陷入瘫痪，业务依然可以正常运转。
主从节点之间存在着紧密的协作关系。主节点会将自身的数据变更信息及时同步给从节点，从节点则不断地接收并更新自己的数据副本，时刻做好准备，以便在需要的时候能够无缝切换，承担起主节点的职责。它们相互配合，使得 Redis Cluster 在具备高性能数据处理能力的同时，又有着可靠的高可用性保障，能更好地应对各种复杂的业务场景和可能出现的意外状况。
数据分片机制
Redis Cluster 采用了一种高效的数据分片机制，即通过哈希槽（hash slots）来对数据进行划分与管理，总共将数据空间划分为 16384 个槽位。
每个键值对（key-value）都会依据特定的哈希算法，也就是 CRC16 [key] % 16384，计算出其对应的哈希槽编号。例如，有一个键为 “user:1000”，先通过 CRC16 哈希函数计算出它的哈希值，假设这个哈希值是 12345，然后对 16384 取模（12345 % 16384 = 345），那么这个键值对就会被映射到编号为 345 的哈希槽上。
而这些哈希槽会被分配到各个节点上，由不同的节点负责相应槽位的数据存储工作。各个主节点会承担一部分槽点的维护，每个槽中存储着对应的数据。通过这样的方式，数据能够较为均匀地分布在各个节点之中，避免了数据倾斜的问题，使得每个节点所承担的数据存储和读写压力相对均衡，从而提高了整个集群数据存储和访问的效率。当客户端发起针对某个键的操作请求时，集群可以根据键所映射的哈希槽，快速定位到负责该槽位的节点，进而将请求准确地路由到对应的节点上进行处理，保障数据操作的高效性和准确性。
节点间通信与信息交互
在 Redis Cluster 里，节点间采用 Gossip 协议来交换集群状态信息，这一协议对于集群的正常运行以及信息的同步起着至关重要的作用。
Gossip 协议下，节点之间会相互传递多种关键信息，比如节点的新增情况、节点的删除情况、某个节点出现故障的信息，以及槽信息变更等内容。每个节点默认每秒会执行 10 次操作，每次选择随机 5 个最久没有通信的其他节点，向它们发送 ping 消息，这个 ping 消息中包含了自身信息以及自己所知道的集群信息。而收到 ping 消息的节点则会返回 pong 消息作为回复。通过这种随机的消息交换方式，经过不断地信息传播和汇总，最终每个节点都能够获得整个集群的所有信息。
例如，当有新的节点加入集群时，原有的某个节点会发送 meet 消息给新加入的节点，邀请它加入集群，随后新节点便开始与其他节点通过 ping、pong 等消息进行通信交互，逐步融入集群，其他节点也能及时知晓集群成员发生了变化。再比如，当某个主节点出现故障挂掉了，与之相连的节点会发现这一情况，并将这个失联信息向整个集群广播，当其他节点收到该失联信息的数量达到集群的大多数时，就会标记这个故障节点为确定下线状态，然后进一步广播这一消息，强迫所有节点都接受该节点已经下线的事实，同时对应的从节点会接替主节点的工作，并告知其他所有节点这一角色变更情况，其他存活节点则会相应地更新它们维护的信息表，从而保障集群能够继续稳定运行，信息始终保持同步一致。
Redis Cluster 高可用实现方式
主从复制与故障转移
在 Redis Cluster 中，主从复制是保障高可用性的基础机制之一。主节点负责处理客户端的读写请求，并将数据变更同步给对应的从节点，从节点则实时复制主节点的数据，时刻保持数据的一致性，就像主节点的 “影子” 一样。
当主节点出现故障时，比如遭遇硬件故障、网络异常等情况无法正常工作，从节点会自动接替主节点的角色，继续对外提供服务，这个过程就是故障转移。具体来说，主从节点之间会维持心跳连接，从节点通过不断接收主节点发送的数据变更信息来更新自己的数据副本。一旦主节点失去响应达到一定时长（可配置），从节点就会检测到这种异常情况，然后自动切换为新的主节点，对外接收读写请求，保障整个集群不会因为某个主节点的问题而陷入瘫痪，业务依然可以正常运转。
例如，在一个电商系统中，如果存储商品库存信息、用户订单数据等关键数据的主 Redis 节点突然宕机，对应的从节点就能无缝接替，继续处理诸如查询库存、新增订单等各种数据交互操作，最大程度减少因节点故障对业务造成的影响，让数据服务始终保持稳定可用。这种机制使得 Redis Cluster 在复杂多变的网络环境和实际应用场景中，具备了可靠的容错能力，是实现高可用性的重要环节。
Sentinel 监控与自动切换
Redis Sentinel 在 Redis Cluster 的高可用体系中起着至关重要的监控与自动切换作用。它是一个分布式架构，由多个 Sentinel 节点组成，这些节点会持续监控 Redis 的主从节点状态。
Sentinel 节点有着多个定时监控任务来完成对集群的监控工作。首先，每隔 10 秒会向集群中的 Redis 数据节点发送 info 命令，以此获取最新的拓扑结构信息，包括主从角色以及对应的 IP、端口等，哪怕有新增的 Redis 节点也能自动探测到新的拓扑情况。其次，每个 Sentinel 节点每隔 2 秒会向 redis 数据节点的_sentinel_:hello 频道同步自身得到的主节点信息以及当前自身的信息，由于其他 Sentinel 节点也订阅了这个频道，所以可以实现信息交换，既能发现新加入的 Sentinel 节点，又能作为后续客观判断主节点下线的依据。另外，Sentinel 节点每隔 1 秒会向 Redis 节点发送 ping 命令来检测实例的状态，如果在指定的时间内（由配置项 down-after-milliseconds 决定）没有收到回复或者收到错误的回复，那么该实例就会被 Sentinel 节点判定为主观下线（SDOWN）。
而当一个 Sentinel 节点认为主节点主观下线时，它会通过
sentinelis-master-down-byaddr 命令向其他 Sentinel 节点咨询该主节点是否下线了，如果超过半数的 Sentinel 节点都回答了下线，此时主节点就会被认定为客观下线（ODOWN）。当主节点客观下线后，Sentinel 节点们会进行选举，每个 Sentinel 节点通过向其他节点发送”sentinel is-master-down-by addr” 命令来申请成为领导者，且每个 Sentinel 节点在收到一个这样的命令时，只允许给第一个节点投票，其他节点的该命令都会被拒绝。如果一个 Sentinel 节点收到了半数以上的同意票，它就会成为 Sentinel 领导者，由这个领导者从剩余的从 Redis 节点中选出一个最合适的节点作为新的主 Redis 节点对外服务，比如会优先选择从节点优先级（slave-priority）最高、复制偏移量最大等条件的从节点，然后执行切换操作，向选为主节点的从节点发送 SLAVEOF NO ONE 命令提升其为主节点，再向其余 Redis 节点发送 slaveof 命令使之成为新主节点的从库节点，并将这一变化通知给客户端，让客户端能及时更新连接的主节点信息，整个过程无需人工干预，完全自动化，从而保障了 Redis Cluster 在主节点故障时能快速恢复正常服务，确保高可用性。
集群扩展与数据迁移
随着业务的发展，系统负载不断增加，原有的 Redis Cluster 可能面临性能瓶颈，这时就需要通过增加节点来扩展集群性能。
在进行集群扩展时，首先要在新的服务器上部署 Redis Cluster，这包括安装 Redis 软件、配置相关参数等操作，比如配置好节点的绑定 IP、端口、集群模式启用等关键配置项。准备好新节点后，使用相应的工具（如 redis-trib.rb 等）将新部署的节点添加到现有的集群中，命令格式通常为 “./redis-trib.rb add-node 新节点：端口 现有集群：端口”。
新节点加入集群后，并不会立刻承担数据存储任务，需要重新分配槽位，也就是让新节点负责一部分虚拟槽的数据。可以使用 “./redis-trib.rb reshard 集群任意一个主库的 ip: 端口” 命令来进行槽位重新分配，分配的时候可以选择让所有节点分出一部分槽位迁移给新节点，也可以指定某个节点迁移出一部分槽位给新节点。例如，在一个原本有 4 个节点的 Redis Cluster 中，每个节点承担 16384/4 = 4096 个槽位，当新增一个节点后，就需要通过重新分配，让每个节点的槽位数量进行合理调整，使新节点也负责一部分槽位的数据存储。
而数据迁移过程则是在槽位重新分配的基础上进行的。当确定好要迁移的槽位以及目标节点后，原节点会将对应槽位的数据逐步迁移到新节点上。不过在数据迁移时，需要注意一些事项，比如要确保目标节点是在线的且有足够的资源（如内存等）来接收数据，同时，数据迁移可能会造成短暂的性能下降，建议选择在系统访问量较少的时间段进行操作，避免对业务产生较大影响。另外，在迁移过程中，客户端可能会收到 MOVED 或者 ASK 等转向信号，当收到 MOVED 时，客户端需要更新自己维护的槽位映射信息，收到 ASK 时，则需要向新节点发 ASKING 命令并重新执行操作，以此来正确地与集群进行数据交互，保障集群扩展和数据迁移过程能够平稳完成，让扩展后的 Redis Cluster 继续高效稳定地运行，满足业务增长带来的性能需求。
高可用 Redis 集群设计要点
合理配置节点数量与关系
在搭建高可用的 Redis 集群时，合理配置节点数量与关系是至关重要的基础环节。首先要依据业务需求来确定，例如，如果业务涉及频繁的读写操作且数据量较大，像电商系统中对商品库存、用户订单等关键数据的处理，那么就需要更多的节点来分担负载，保障服务的高效性与稳定性。
从容错机制角度考虑，Redis Cluster 采用多主多从架构来实现高可用，通常至少需要 3 个主节点。这是因为在判断节点故障以及进行故障转移时，需要遵循多数原则。假设有 3 个主节点，当 1 个主节点出现故障时，剩余的 2 个主节点能够达成一致，确认故障节点并触发从节点进行故障转移，接替主节点继续提供服务。若只有 2 个主节点，一旦其中 1 个故障，剩下的 1 个无法独自决定故障情况以及进行后续操作，集群就可能陷入无法正常工作的状态。
而且主节点与从节点之间是相互关联、紧密协作的关系。主节点负责处理读写请求并将数据变更同步给对应的从节点，从节点实时复制主节点的数据，作为备份存在。每个主节点可以挂载多个从节点，一般会根据业务对数据安全性以及读写性能的侧重程度来确定从节点数量。比如对数据安全性要求极高的金融业务场景，可能会为每个主节点配置较多的从节点，以增强数据冗余备份能力，确保在主节点出现任何意外情况时，都有可靠的从节点能够无缝切换，保障业务不受影响继续运转。
数据备份与持久化策略
在 Redis Cluster 中，数据备份与持久化是确保数据安全以及集群高可用的关键手段，主要通过 RDB 快照和 AOF 日志这两种方式将数据备份到磁盘。
RDB 快照是 Redis 的默认持久化方式，它将 Redis 在某个时间点的数据状态保存到磁盘上的一个二进制文件中。其原理是通过 fork 子进程来完成操作，先复制一份 Redis 当前的数据状态，然后在子进程中将这份数据写入磁盘文件，这样对 Redis 的性能影响较小。配置 RDB 快照时，可以修改 Redis 配置文件 redis.conf，比如设置 “save 900 1”（表示在 900 秒即 15 分钟内如果至少有 1 个键发生变化，则执行快照）、“save 300 10”（300 秒即 5 分钟内如果至少有 10 个键发生变化，则执行快照）、“save 60 10000”（60 秒内如果至少有 10000 个键发生变化，则执行快照）等参数，也可以手动执行 BGSAVE 命令来创建子进程执行快照操作，成功后会在后台生成一个 RDB 文件，文件名格式为 dump-${时间戳}.rdb。RDB 快照适用于对备份、全量复制、灾难恢复等场景，因其恢复数据的速度远远比 AOF 快，不过它无法做到实时持久化，每次进行 bgsave 操作都要执行 fork 操作创建子进程，属于重量级操作，频繁执行成本过高。
AOF（Append-Only File）日志则是把每次写命令追加写入日志中，当需要恢复数据时重新执行 AOF 文件中的命令就可以了，它提供了比 RDB 更高的数据安全性，几乎不会丢失任何已提交的事务，是目前主流的 Redis 持久化方式。AOF 持久化流程包含命令追加（append），即所有写命令都会被追加到 AOF 缓存区（aof_buf）中；文件同步（sync），可根据不同策略将 AOF 缓存区同步到 AOF 文件中，比如 “always”（每次写入缓存区都要同步到 AOF 文件中，但硬盘操作慢，限制高并发，不建议配置）、“no”（每次写入缓存区后不进行同步，同步到 AOF 文件的操作由操作系统负责，同步周期不可控且增大每次同步的硬盘数据量）、“everysec”（每次写入缓存区后，由专门的线程每秒钟同步一次，兼顾性能和数据安全，是默认推荐的同步策略）；文件重写（rewrite），定期对 AOF 文件进行重写，以压缩文件体积、提高性能；数据加载（load），恢复数据时重新执行 AOF 文件中的命令。AOF 文件通常会占用更多的磁盘空间，因为它记录了每个写操作的详细信息，并且随着时间推移，若不适当重写，文件可能变得非常庞大。
在实际的 Redis Cluster 应用场景中，可以根据业务需求和对数据保护的要求，选择合适的持久化方式或者结合使用二者，以满足性能和数据完整性的平衡。例如对数据完整性要求极高的业务，可同时开启 RDB 和 AOF，利用 RDB 定期备份以及 AOF 实时记录写命令的优势，全方位保障数据安全。
应对常见限制与问题
在 Redis Cluster 的高可用设计中，会面临一些常见的限制与问题，需要采取相应的解决办法来保障集群的稳定高效运行。
其一，Redis Cluster 不支持多键操作，例如像 MGET、MSET 这类同时对多个键进行操作的命令，在集群模式下无法像单机 Redis 那样直接使用。这是因为数据分散存储在不同的节点上，一个多键操作涉及的键可能分布在多个节点，集群无法一次性处理。对此，可以通过在业务层面进行优化，将需要同时操作的相关数据尽量设计为存储在同一个节点上，比如按照业务模块对数据进行分类存储，或者在代码逻辑中提前判断键的分布情况，分多次对不同节点上的键进行操作，模拟实现类似多键操作的功能。
其二，写操作热点问题也是常见的挑战。比如在某些业务场景下，特定的数据会频繁被更新写入，导致承载这些数据的节点压力过大，出现性能瓶颈。像预约系统中对预约人数的统计，如果数百万用户同时点击预约操作，频繁写入同一个键对应的缓存数据，单个 Redis 节点很难承受如此高的并发写压力。解决这个问题可以通过合适的数据分布和缓存策略，例如采用一主多从的架构，让主节点专注于承担写数据以及少量的分发工作，从节点负责读操作，从节点之间可以进行数据同步；还可以结合本地缓存，在每一台预约服务器定义一个本地变量作为本地缓存，由它来负责累加请求，每隔一段时间将这些累加数据一次性地与 Redis 中的预约人数相加，以此分担 Redis 节点的写压力，同时降低对实时性要求不高的数据频繁写入带来的性能影响。
另外，数据倾斜也是可能出现的问题，如果数据没有均匀地分布在各个节点上，部分节点负载过高，而部分节点资源闲置，会影响整个集群的性能和可用性。可以通过合理配置哈希槽，以及定期检查和调整数据分布情况等方式来避免数据倾斜，确保每个节点承担相对均衡的数据存储和读写任务，保障集群的高效稳定运行。
Redis Cluster 高可用集群搭建实践
环境准备与前期配置
在开始搭建 Redis Cluster 高可用集群之前，需要做好相应的环境准备以及前期配置工作，以下为你详细介绍。
软件环境方面：不同的操作系统都可以搭建 Redis Cluster，常见的如 CentOS、Ubuntu 等 Linux 系统，这里以 CentOS 7 为例进行说明。首先确保服务器安装了基本的编译工具以及相关依赖，像gcc等，因为 Redis 是基于 C 语言开发的，编译源码需要gcc编译器的支持，如果未安装，可通过命令yum -y install gcc来进行安装。
硬件要求上：要依据业务的数据量以及预期的访问并发量来综合确定。如果业务数据量庞大且读写频繁，那就需要配置更高的内存、多核的 CPU 以及足够的磁盘空间来保证集群的高效运行。例如，对于一个大型电商系统的缓存场景，可能就需要多台配置较高的服务器来搭建集群。
接下来就是 Redis 的下载与安装步骤：
- 进入到待安装目录，比如cd /usr/local。
- 下载 Redis 源代码压缩包，执行wget http://download.redis.io/releases/redis-5.0.3.tar.gz（这里以 Redis 5.0.3 版本为例，你可以根据实际需求选择合适版本），然后解压文件tar -zxvf redis-5.0.3.tar.gz。
- 进入解压后的目录并使用make命令执行编译安装 Redis，顺序执行如下命令：
cd redis-5.0.3
make && make install安装完成后，便可以开始进行节点的配置工作，步骤如下：
- 创建 redis 实例根目录以及各个具体实例相关目录，例如创建端口号为 7001 的实例相关目录，命令如下：
mkdir /opt/redis/cluster
mkdir /opt/redis/cluster/7001
cd /opt/redis/cluster/7001- 复制配置文件并进行修改，使其作为当前 redis 实例的启动配置文件：
cp /opt/redis/redis.conf.然后修改配置文件中的关键配置项，下面为你列举一些必要的修改内容及说明：
- port 7001：指定客户端连接端口，不同的节点实例需要配置不同的端口号，比如后续创建的其他实例可以依次配置为 7002、7003 等。
- bind 192.168.220.11：绑定实例的 IP 地址，填写服务器实际的 IP，如果是在本地模拟多个节点，也可填写本地回环地址等，要确保各节点配置的 IP 可相互通信。
- dir /opt/redis/cluster/7001/data：指定 redis 实例数据的存储位置，便于管理数据文件。
- daemonize yes：设置是否以后台进程的方式启动 redis 实例，设置为yes可以让实例在后台运行。
- pidfile /var/run/redis_7001.pid：指定该进程的 pid 文件路径及文件名，便于管理进程。
- cluster-enabled yes：开启集群模式，这是搭建集群的关键配置项，确保节点以集群模式启动。
- appendonly yes：开启 aop 日志，用于数据持久化以及故障恢复等场景，保障数据的安全性。
- protected-mode no：关闭保护模式，方便在搭建和测试阶段进行集群内外的访问，不过在生产环境要根据实际安全策略谨慎配置此项。
- requirepass cyclone：为主节点开启密码保护（这里密码以cyclone为例，可自行设置），用于节点间认证等场景。
- masterauth cyclone：从节点与主节点交互时的密码，要和主节点的requirepass配置一致，确保从节点能正常同步主节点数据。
按照上述方式，依次创建并配置好其他的节点实例，比如 7002、7003 等节点对应的目录及配置文件，这样就完成了前期的环境准备与配置工作，为后续的集群创建打下基础。
集群创建与节点启动
当完成了环境准备与前期配置后，接下来就可以进行 Redis Cluster 集群的创建以及各个节点的启动操作了。
集群创建的操作流程如下：
在 Redis 5.0 及以后版本，可以使用redis-cli工具方便地创建集群，命令格式大致为（以下命令假设所有节点都在同一台服务器上，通过不同端口区分，实际应用中根据真实 IP 和端口替换即可）：
redis-cli -a cyclone --cluster create --cluster-replicas 1 192.168.220.11:7001 192.168.220.11:7002 192.168.220.11:7003 192.168.220.11:7004 192.168.220.11:7005 192.168.220.11:7006这里的--cluster-replicas 1表示为每个主节点创建一个从节点，也就是构建的是三主三从的集群结构（根据具体需求也可以调整这个参数来改变主从节点数量关系）。上述命令执行后，工具会自动进行哈希槽的分配等操作，将 16384 个哈希槽合理地分配到各个主节点上，并且建立好主从节点之间的关联关系。
如果是在 Redis 5.0 之前的版本搭建集群，可能还需要借助ruby环境以及redis-trib.rb脚本工具来创建集群，例如：
./redis-trib.rb create --replicas 1 192.168.220.11:7001 192.168.220.11:7002 192.168.220.11:7003 192.168.220.11:7004 192.168.220.11:7005 192.168.220.11:7006不过使用这种方式需要先确保服务器安装了ruby以及相关的rubygems，并且通过gem install redis命令安装对应的redis接口依赖。
节点启动方法和顺序方面：
各个节点的启动顺序并没有严格要求，但要确保所有参与集群的节点都能正常启动并且配置正确。启动节点的命令示例如下（以 7001 端口节点为例）：
redis-server /opt/redis/cluster/7001/redis.conf按照上述命令格式，依次启动之前配置好的各个节点实例，比如 7002、7003 等端口对应的节点。在启动过程中，可以通过查看节点的日志文件（配置文件中指定的logfile路径对应的文件）或者使用命令ps -ef | grep redis查看进程是否正常启动，来确认节点启动是否成功。如果某个节点启动失败，需要根据日志中的报错信息排查配置文件是否有误、端口是否被占用等问题，确保所有节点都成功启动后，整个 Redis Cluster 集群才算搭建完成并可以开始对外提供服务了。
集群测试与维护
完成 Redis Cluster 集群的搭建后，还需要进行一系列的测试以及日常的维护工作，以保障集群能够稳定高效地运行。
集群测试操作步骤如下：
在完成搭建后，可以通过简单的功能测试来验证集群是否正常运行。首先，使用redis-cli命令连接到集群的某个节点上，例如：
redis-cli -a cyclone -c -h 192.168.220.11 -p 7001这里的-c参数表示以集群模式连接，连接成功后，可以执行一些简单的读写命令进行测试，比如set key value设置一个键值对，然后再通过get key获取该键对应的值，如果能够正常设置和获取，说明集群的基本读写功能是正常的。还可以尝试插入多个不同的键值对，观察数据是否能按照哈希槽的分配规则正确地存储在不同节点上，例如通过cluster keyslot key命令可以查看某个键对应的哈希槽编号，进而判断其是否存储在对应的负责节点上。
日常维护方面需要关注以下要点及采取相应维护手段：
- 节点状态监控：要时刻关注各个节点的状态，包括节点是否在线、是否有延迟过高、是否出现频繁的连接断开等情况。可以通过定期执行cluster nodes命令查看节点的详细信息，比如节点的角色（主节点还是从节点）、节点的 IP 和端口、节点负责的哈希槽范围以及节点的连接状态等。如果发现某个节点显示为下线状态或者有异常的延迟等情况，需要及时排查是网络问题、服务器硬件故障还是软件配置出错等原因导致的，并尽快恢复节点正常运行，避免影响整个集群的可用性。
- 数据一致性检查：由于 Redis Cluster 存在主从复制机制来保障数据的冗余备份以及故障转移后的数据完整性，所以需要定期检查主从节点之间的数据一致性。可以通过对比主从节点上相同键值的数据内容是否一致来进行简单的检查，也可以借助一些第三方的监控工具或者自己编写脚本实现更全面的数据一致性校验逻辑。若发现数据不一致的情况，要及时排查主从同步过程中是否出现了问题，比如网络传输中断导致部分数据未同步成功等，并采取相应的修复措施，例如手动触发一次全量的数据同步或者修复网络问题后等待从节点自动重新同步数据等。
- 故障处理与恢复：在集群运行过程中，难免会遇到节点故障的情况，如主节点宕机等。当主节点出现故障时，从节点会自动进行故障转移接替主节点的工作，但在故障恢复后，原主节点重新上线时，要确保它能正确地重新融入集群，可能需要手动执行一些操作，比如重新调整节点的角色（如果之前的从节点已经提升为主节点了，原主节点上线后可能需要设置为从节点），以及重新分配哈希槽等，这些操作都要谨慎进行，避免造成数据丢失或者集群不稳定的情况。同时，对于一些硬件故障导致的节点损坏等情况，需要及时准备好备用的服务器节点，按照之前的配置流程重新部署节点并加入到集群中，保障集群的节点数量和性能能够满足业务需求。
总之，对 Redis Cluster 集群的测试与维护是保障其高可用性的重要环节，需要运维人员定期进行检查和操作，及时发现并解决潜在的问题，确保集群能够持续稳定地为业务提供数据服务。