Redis 集群中有一个特性,它不使用强一致性模型,而是使用最终一致性。Redis 集群通过分区 (sharding) 的方式来存储数据,不同的键可能会被存储在不同的节点上。每个键通过一个哈希槽 (hash slot) 来决定应该被存储到哪个节点上。一个 Redis 集群总共有 16384 个哈希槽,每个节点负责管理其中的一部分。
当你在一个主节点(master node)上使用 SET 命令写入一个键时,这个键会被存储在负责该键的哈希槽对应的主节点上,且其数据将复制到这个主节点对应的从节点(slave node),确保冗余和故障恢复。
在三主三从的集群配置中,每个主节点都有一个对应的从节点。如果你在某个主节点上设置了一个键值对,那么这个键值对仅在这个主节点及其从节点上可用。其他主节点(和它们对应的从节点)不会包含此键值对,除非你尝试写入的键落在它们负责的哈希槽范围内。
如果你在另一个主节点上查询那个被 SET 的键,那么你有两种情况:
如果查询的节点正是负责该键的主节点,那么你应该能够查询到这个键。
如果查询的节点不是负责该键的主节点,查询将失败,因为这个键不存在于该节点负责的哈希槽内。
如果你需要在任意节点上查询任意键,则必须使用 ASK 或 MOVED 重定向响应来实现。Redis 客户端通常会处理这些重定向响应,自动将请求发送到正确的节点。
此外,还有一些边缘情况,可能会导致数据在主节点上无法立即查询到:
网络分区或者其他通信问题
主从复制延迟
写入命令尚未被主节点处理
确保你的 Redis 客户端正确配置和处理集群模式,以便自动重定向到正确的节点以完成操作。如果你的操作没有按预期生效,检查你的 Redis 客户端日志和配置,以确保它支持集群模式,并且当前的工作状态是好的。