集群 节点 一致性hash 哈希槽 异步复制 网络分区
Redis的集群方案
- redis cluster集群方案；
- master/slave主从方案；
- 哨兵模式来进行主从替换以及故障恢复。
Redis Sentinal着眼于高可用，在master宕机时会自动将slave提升为master，继续提供服务。
Redis Cluster着眼于扩展性，在单个redis内存不足时，使用Cluster进行分片存储。
Redis Cluster实现了分布式且允许单点故障，没有中心节点，各节点地位一致，具有线性可伸缩的功能。节点之间通过二进制协议进行通信，节点与客户端之间通过ascii协议进行通信。
集群介绍
Redis集群从3.0版本开始。集群不支持同时处理多个keys的命令，因为这需要在不同的节点间移动数据，会严重影响性能，在高负载的情况下可能会导致错误。
Redis集群通过节点提供一定程度的可用性，在实际环境中当某个节点宕机或者不可达的情况下继续处理命令。
集群的优势:
- 自动分割数据到不同的节点上。
- 集群的部分节点失败或者不可达的时候能够继续处理命令。
集群的数据分片
Redis集群没有使用一致性hash，而是使用16384个哈希槽。每个key通过CRC16校验后对16384取模来决定放到哪个槽。集群的每个节点负责一部分hash槽。
这种结构很容易添加或者删除节点。从一个节点将哈希槽移动到另一个节点并不会停止服务，所以改变某个节点的哈希槽的数量不会造成集群不可用。
集群的主从复制模型
为了在部分节点失败或者大部分节点无法通信的情况下，集群仍然可用。集群使用了主从复制模型，每个节点会有多个复制品。
一致性保证
Redis集群不能保证数据的强一致性。在特定条件下可能会丢失写操作。
- 第一个原因是，集群是异步复制。
例如写操作过程:
客户端向主节点B写入一条命令。
主节点B向客户端回复命令状态。
主节点将写操作复制给从节点 B1, B2 和 B3。
主节点对命令的复制工作发生在返回命令回复之后，因为如果每次处理命令请求都需要等待复制操作完成的话，那么主节点处理命令请求的速度将极大地降低 —— 必须在性能和一致性之间做出权衡。 注意：Redis 集群可能会在将来提供同步写的方法。
- 另一个原因是，集群出现网络分区导致丢失命令， 并且一个客户端与至少包括一个主节点在内的少数实例被孤立。
举个例子：假设集群包含 A 、 B 、 C 、 A1 、 B1 、 C1 六个节点，还有一个客户端 Z1 。假设集群中发生网络分区，那么集群可能会分为两方，大部分的一方包含节点 A 、C 、A1 、B1 和 C1 ，小部分的一方则包含节点 B 和客户端 Z1。
Z1仍然能够向主节点B中写入, 如果网络分区发生时间较短,那么集群将会继续正常运作,如果分区的时间足够让大部分的一方将B1选举为新的master，那么Z1写入B中得数据便丢失了。
注意，在网络分区出现期间， 客户端 Z1 可以向主节点 B 发送写命令的最大时间是有限制的，这一时间限制称为节点超时时间（node timeout）。
