Redis 集群中有一个特性，它不使用强一致性模型，而是使用最终一致性。Redis 集群通过分区 (sharding) 的方式来存储数据，不同的键可能会被存储在不同的节点上。每个键通过一个哈希槽 (hash slot) 来决定应该被存储到哪个节点上。一个 Redis 集群总共有 16384 个哈希槽，每个节点负责管理其中的一部分。

当你在一个主节点（master node）上使用 SET 命令写入一个键时，这个键会被存储在负责该键的哈希槽对应的主节点上，且其数据将复制到这个主节点对应的从节点（slave node），确保冗余和故障恢复。

在三主三从的集群配置中，每个主节点都有一个对应的从节点。如果你在某个主节点上设置了一个键值对，那么这个键值对仅在这个主节点及其从节点上可用。其他主节点（和它们对应的从节点）不会包含此键值对，除非你尝试写入的键落在它们负责的哈希槽范围内。

如果你在另一个主节点上查询那个被 SET 的键，那么你有两种情况：

如果查询的节点正是负责该键的主节点，那么你应该能够查询到这个键。
如果查询的节点不是负责该键的主节点，查询将失败，因为这个键不存在于该节点负责的哈希槽内。
如果你需要在任意节点上查询任意键，则必须使用 ASK 或 MOVED 重定向响应来实现。Redis 客户端通常会处理这些重定向响应，自动将请求发送到正确的节点。

此外，还有一些边缘情况，可能会导致数据在主节点上无法立即查询到：

网络分区或者其他通信问题
主从复制延迟
写入命令尚未被主节点处理
确保你的 Redis 客户端正确配置和处理集群模式，以便自动重定向到正确的节点以完成操作。如果你的操作没有按预期生效，检查你的 Redis 客户端日志和配置，以确保它支持集群模式，并且当前的工作状态是好的。