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

Question

传统(常规)红色

根据我所读到的这里，当使用memcached时

• 每个客户端都知道所有服务器。
• 服务器执行，而不是相互通信。
• 如果客户端希望设置或读取与某个键对应的值，则客户端库首先计算密钥的散列，以确定要使用的服务器。

我的理解是，Redis (而不是 Redis集群)提出了相同的要求和逻辑。也就是说，客户端需要知道他们需要向哪些服务器写入数据(例如使用哈希或等效的)。

红系簇

对于Redis集群，情况似乎有所不同。看上去：

• 师父互相交谈
• 主从与复制奴隶对话

这似乎使它更接近于例如etcd或Zookeeper，但可能都在内存中(因此缓存速度更快)。

也就是说，在etcd中，可以向写入任何节点(跟随者或领导者)，例如，a in RR (Round )方式(即，只要etcd节点响应)，而not必须在向节点读取/写入数据时，not必须知道关于数据是如何被分割的<代码>E 234的。这是因为etcd使用协商一致算法(Raft)跨节点分发数据，而etcd试图在all nodes上编写和存储all data。

这也适用于Redis集群吗？或者，在向集群进行读写时，是否需要知道每个键位于何处(因此需要命中哪些节点)？

​

​

Answer 1

我的理解是，Redis (而不是Redis集群)强加了相同的要求和逻辑。也就是说，客户端需要知道他们需要向哪些服务器写入数据(例如使用哈希或等效的)。

不完全同意。在这种情况下，只有一个主节点，客户端总是需要写到主节点(当主复制同步时，对副本节点的写将被覆盖)。客户端可以从任何节点读取数据，但从副本读取的数据可能会过时。没有散列内容，因为每个节点都有所有数据的完整副本。如果您还使用Redis，您可以从Redis动态获取主节点和副本节点信息。此外，哨兵将做主故障转移的东西。

这也适用于Redis集群吗？或者，在向集群进行读写时，是否需要知道每个键位于何处(因此需要命中哪些节点)？

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

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