Redis 集群是否需要读/写分片的知识？

Question

传统（常规）redis

根据我读到的here，在使用 memcached 时：

• 每个客户端都知道所有服务器
• 服务器之间不相互通信
• 如果客户端希望设置或读取与某个键对应的值，客户端的库首先计算该键的哈希值以确定使用哪个服务器。

我的理解是 Redis（不是 Redis 集群）强加了相同的要求和逻辑。也就是说，客户端需要知道他们需要将数据写入哪些服务器（例如，使用散列或等价物）。

Redis 集群

使用 Redis 集群，情况似乎有所不同。它看起来像：

• 大师们互相交流
• master 与复制 slave 对话

这似乎使它更接近例如etcd 或 Zookeeper，只是它可能都在内存中（因此缓存速度更快）。

也就是说，在etcd 中，可以写入任何节点（追随者或领导者），例如以 RR（循环）方式（即只要 etcd 节点响应），并且不必须知道数据是如何分片 strong> 读取/写入节点时。这是因为etcd 使用共识算法（Raft）跨节点分发数据，而etcd 尝试在所有节点上写入和存储所有数据。

这是否也适用于 Redis 集群？或者在读/写集群时是否需要知道每个键的位置（以及要命中的节点）？

Answer 1

我的理解是 Redis（不是 Redis 集群）强加了相同的要求和逻辑。也就是说，客户端需要知道他们需要将数据写入哪些服务器（例如，使用散列或等价物）。

不完全是。在这种情况下，只有一个主节点，客户端总是需要写入主节点（当主节点与副本同步时，对副本节点的写入将被覆盖）。客户端可以从任何节点读取，除了从副本读取的数据可能是陈旧的。没有散​​列的东西，因为每个节点都有所有数据的完整副本。如果您还使用 Redis Sentinel，则可以从 Redis Sentinel 动态获取主节点和副本节点信息。 Sentinel 也会做主故障转移的工作。

这是否也适用于 Redis 集群？或者在读/写集群时是否需要知道每个键的位置（以及要命中的节点）？

客户端需要知道每个键在哪个节点上的位置。但是，客户端可以将请求发送到任何节点。如果请求的密钥不在该节点上，该节点将响应密钥的位置信息。然后客户端可以向正确的节点发送另一个请求。

通常一个像样的客户端库会实现这个逻辑，最终用户不需要知道这些细节。