传统（常规）redis
根据我在这里读到的内容，当使用memcached时：
每个客户端都知道所有服务器
服务器之间不通信
如果客户机希望设置或读取与某个密钥对应的值，则客户机的库首先计算该密钥的哈希值，以确定要使用哪个服务器。
我的理解是redis（不是redis cluster）强加了相同的需求和逻辑。也就是说，客户机需要知道他们需要向哪些服务器写入数据（例如，使用散列或等效文件）。
redis集群
使用redis集群，情况似乎有所不同。它看起来像：
大师们互相交谈
主机与复制从机对话
这似乎使它更接近于。 etcd 或者 Zookeeper ，除了它可能都在内存中（因此缓存速度更快）。
也就是说，在 etcd 可以以rr（循环）方式（即只要 etcd 节点响应），并且不必知道在读取/写入节点时数据是如何分片的。这是因为 etcd 使用一致性算法（raft）跨节点分发数据，并且 etcd 尝试写入并存储所有节点上的所有数据。
这是否也适用于redis集群？或者，在读/写集群时，是否需要知道每个键位于何处（从而命中哪些节点）？
1条答案
按热度按时间cbjzeqam1#
我的理解是redis（不是redis cluster）强加了相同的需求和逻辑。也就是说，客户机需要知道他们需要向哪些服务器写入数据（例如，使用散列或等效文件）。
不完全是。在这种情况下，只有一个主节点，客户端总是需要写入主节点（当主节点与副本同步时，对副本节点的写入将被覆盖）。客户机可以从任何节点读取数据，但从副本读取的数据可能已过时。没有散列内容，因为每个节点都有所有数据的完整副本。如果您也使用redis sentinel，那么您可以动态地从redis sentinel获取主节点和副本节点的信息。哨兵也会做主故障转移的事情。
这是否也适用于redis集群？或者，在读/写集群时，是否需要知道每个键位于何处（从而命中哪些节点）？
客户端需要知道每个密钥在哪个节点上的位置。但是，客户端可以将请求发送到任何节点。如果请求的密钥不在此节点上，则节点将使用密钥的位置信息进行响应。然后客户端可以向正确的节点发送另一个请求。
通常一个好的客户端库会实现这个逻辑，最终用户不需要知道这些细节。