redis架构系列——Cluster集群模式详解

设计的主要特点和基本原理

Redis 集群目标

• 高性能和线性可扩展性，最多可达1000个节点。没有代理，使用异步复制，并且不对值执行合并操作。
• 可接受的写入安全程度：系统尝试（尽最大努力）保留来自与大多数主节点连接的客户端的所有写入。通常，有一些小窗口可能会丢失确认的写入。当客户端位于少数分区中时，丢失确认写入的窗口会更大。
• 可用性：Redis集群能够在大多数主节点可访问的分区中继续存在，并且每个主节点至少有一个无法再访问的副本。此外，使用副本迁移时，不再被任何副本复制的主节点将从多个副本覆盖的主节点接收一个副本。

已实现的子集

Redis集群实现了Redis的非分布式版本。执行复杂多键的命令在以下情况下实现设置并集和交集等操作操作中涉及的所有密钥都哈希到同一插槽。

Redis集群实现了一个称为哈希标签的概念，可以使用强制将某些密钥存储在同一个哈希槽中。然而，在手动重新分片、多键操作可能在一段时间内不可用而单键操作始终可用。

Redis集群不支持像单机版那样的多个数据库的Redis。仅支持database 0；不允许select命令

Redis 集群协议中的客户端和服务器角色

在Redis集群中，节点负责保存数据，并获取集群的状态，包括将密钥映射到正确的节点。群集节点还能够自动发现其他节点，检测不工作节点，并在需要时按顺序将副本节点提升为master在发生故障时继续运行。

为了执行其任务，所有群集节点都使用TCP总线和二进制协议，称为Redis集群总线。每个节点都使用集群连接到集群中的所有其他节点总线。节点使用gossip协议来传播有关集群的信息为了发现新节点，发送ping数据包以确保所有其他节点工作正常，并且需要发送集群消息信号特定条件。集群总线也用于在集群中传播Pub/Sub消息并编排手动消息用户请求时的故障转移（手动故障转移是故障转移不是由Redis集群故障检测器启动的，而是由直接系统管理员）。

因为Node并不提供Proxy机制，当Client将请求发给错误的nodes时（此node上不存在此key所属的slot），node将会反馈“MOVED”或者“ASK”错误信息，以便Client重新定向到合适的node。理论上，Client可以将请求发送给任意一个nodes，然后根据在根据错误信息转发给合适的node，客户端可以不用保存集群的状态信息，当然这种情况下性能比较低效，因为Client可能需要2次TCP调用才能获取key的结果，通常客户端会缓存集群中nodes与slots的映射关系，并在遇到“Redirected”错误反馈时，才会更新本地的缓存。

安全写入（write safety）

在Master-slaves之间使用异步replication机制，在failover之后，新的Master将会最终替代其他的replicas（即slave）。在出现网络分区时（network partition），总会有一个窗口期（node timeout）可能会导致数据丢失；不过，Client与多数派的Master、少数派Master处于一个分区（网络分区，因为网络阻断问题，导致Clients与Nodes被隔离成2部分）时，这两种情况下影响并不相同。

1）write提交到master，master执行完毕后向Client反馈“OK”，不过此时可能数据还没有传播给slaves（异步replication）；如果此时master不可达的时间超过阀值（node timeout，参见配置参数），那么将触发slave被选举为新的Master（即Failover），这意味着那些没有replication到slaves的writes将永远丢失了！

2）还有一种情况导致数据丢失：
A）因为网络分区，此时master不可达，且Master与Client处于一个分区，且是少数派分区。
B）Failover机制，将其中一个slave提升为新Master。
C）此后网络分区消除，旧的Master再次可达，此时它将被切换成slave。
D）那么在网络分区期间，处于少数派分区的Client仍然将write提交到旧的Master，因为它们觉得Master仍然有效；当旧的Master再次加入集群，切换成slave之后，这些数据将永远丢失。

可用性

处于“