redis cluster集群模式总结

Redis集群介绍

Redis 集群是一个提供在多个Redis间节点间共享数据的程序集。

Redis集群并不支持处理多个keys的命令,由于这须要在不一样的节点间移动数据,从而达不到像Redis那样的性能,在高负载的状况下可能会致使不可预料的错误.

Redis 集群经过分区来提供必定程度的可用性,在实际环境中当某个节点宕机或者不可达的状况下继续处理命令. Redis 集群的优点:

• 自动分割数据到不一样的节点上。
• 整个集群的部分节点失败或者不可达的状况下可以继续处理命令。

Redis 集群的数据分片

Redis 集群没有使用一致性hash, 而是引入了 哈希槽的概念.

Redis 集群有16384个哈希槽,每一个key经过CRC16校验后对16384取模来决定放置哪一个槽.集群的每一个节点负责一部分hash槽,举个例子,好比当前集群有3个节点,那么:

• 节点 A 包含 0 到 5500号哈希槽.
• 节点 B 包含5501 到 11000 号哈希槽.
• 节点 C 包含11001 到 16384号哈希槽.

这种结构很容易添加或者删除节点. 好比若是我想新添加个节点D, 我须要从节点 A, B, C中得部分槽到D上. 若是我想移除节点A,须要将A中的槽移到B和C节点上,而后将没有任何槽的A节点从集群中移除便可. 因为从一个节点将哈希槽移动到另外一个节点并不会中止服务,因此不管添加删除或者改变某个节点的哈希槽的数量都不会形成集群不可用的状态.

Redis 集群的主从复制模型

为了使在部分节点失败或者大部分节点没法通讯的状况下集群仍然可用，因此集群使用了主从复制模型,每一个节点都会有N-1个复制品.

在咱们例子中具备A，B，C三个节点的集群,在没有复制模型的状况下,若是节点B失败了，那么整个集群就会觉得缺乏5501-11000这个范围的槽而不可用.

然而若是在集群建立的时候（或者过一段时间）咱们为每一个节点添加一个从节点A1，B1，C1,那么整个集群便有三个master节点和三个slave节点组成，这样在节点B失败后，集群便会选举B1为新的主节点继续服务，整个集群便不会由于槽找不到而不可用了

不过当B和B1 都失败后，集群是不可用的.

Redis 一致性保证

Redis 并不能保证数据的强一致性. 这意味这在实际中集群在特定的条件下可能会丢失写操做.

第一个缘由是由于集群是用了异步复制. 写操做过程:

• 客户端向主节点B写入一条命令.
• 主节点B向客户端回复命令状态.
• 主节点将写操做复制给他得从节点 B1, B2 和 B3.

主节点对命令的复制工做发生在返回命令回复以后， 由于若是每次处理命令请求都须要等待复制操做完成的话， 那么主节点处理命令请求的速度将极大地下降 —— 咱们必须在性能和一致性之间作出权衡。 注意：Redis 集群可能会在未来提供同步写的方法。 Redis 集群另一种可能会丢失命令的状况是集群出现了网络分区， 而且一个客户端与至少包括一个主节点在内的少数实例被孤立。

举个例子 假设集群包含 A 、 B 、 C 、 A1 、 B1 、 C1 六个节点， 其中 A 、B 、C 为主节点， A1 、B1 、C1 为A，B，C的从节点， 还有一个客户端 Z1 假设集群中发生网络分区，那么集群可能会分为两方，大部分的一方包含节点 A 、C 、A1 、B1 和 C1 ，小部分的一方则包含节点 B 和客户端 Z1 .

Z1仍然可以向主节点B中写入, 若是网络分区发生时间较短,那么集群将会继续正常运做,若是分区的时间足够让大部分的一方将B1选举为新的master，那么Z1写入B中得数据便丢失了.

注意， 在网络分裂出现期间， 客户端 Z1 能够向主节点 B 发送写命令的最大时间是有限制的， 这一时间限制称为节点超时时间（node timeout）， 是 Redis 集群的一个重要的配置选项：

 

集群在线重配置（live reconfiguration）-动态新增、删除节点数据一致性保障

Redis 集群支持在集群运行过程当中添加或移除节点。实际上，添加或移除节点都被抽象为同一个操做，那就是把哈希槽从一个节点移到另外一个节点。

• 向集群添加一个新节点，就是把一个空节点加入到集群中并把某些哈希槽从已存在的节点移到新节点上。
• 从集群中移除一个节点，就是把该节点上的哈希槽移到其余已存在的节点上。
• 因此实现这个的核心是能把哈希槽移来移去。从实际角度看，哈希槽就只是一堆键，因此 Redis 集群在重组碎片（reshard）时作的就是把键从一个节点移到另外一个节点。

为了理解这是怎么工做的，咱们须要介绍 CLUSTER 的子命令，这些命令是用来操做 Redis 集群节点上的哈希槽转换表（slots translation table）。

如下是可用的子命令：

• CLUSTER ADDSLOTS slot1 [slot2] … [slotN]
• CLUSTER DELSLOTS slot1 [slot2] … [slotN]
• CLUSTER SETSLOT slot NODE node
• CLUSTER SETSLOT slot MIGRATING node
• CLUSTER SETSLOT slot IMPORTING node
• 头两个命令，ADDSLOTS 和 DELSLOTS，就是简单地用来给一个 Redis 节点指派（assign）或移除哈希槽。 在哈希槽被指派后，节点会将这个消息经过 gossip 协议向整个集群传播。ADDSLOTS 命令一般是用于在一个集群刚创建的时候快速给全部节点指派哈希槽。

当 SETSLOT 子命令使用 NODE 形式的时候，用来给指定 ID 的节点指派哈希槽。 除此以外哈希槽能经过两个特殊的状态来设定，MIGRATING 和 IMPORTING：

• 当一个槽被设置为 MIGRATING，原来持有该哈希槽的节点仍会接受全部跟这个哈希槽有关的请求，但只有当查询的键还存在原节点时，原节点会处理该请求，不然这个查询会经过一个 -ASK 重定向（-ASK redirection）转发到迁移的目标节点。
• 当一个槽被设置为 IMPORTING，只有在接受到 ASKING 命令以后节点才会接受全部查询这个哈希槽的请求。若是客户端一直没有发送 ASKING 命令，那么查询都会经过 -MOVED 重定向错误转发到真正处理这个哈希槽的节点那里。

这么讲可能显得有点奇怪，如今咱们用实例让它更清晰些。假设咱们有两个 Redis 节点，称为 A 和 B。咱们想要把哈希槽 8 从 节点A 移到 节点B，因此咱们发送了这样的命令：

• 咱们向 节点B 发送：CLUSTER SETSLOT 8 IMPORTING A
• 咱们向 节点A 发送：CLUSTER SETSLOT 8 MIGRATING B

其余全部节点在每次被询问到的一个键是属于哈希槽 8 的时候，都会把客户端引向节点”A”。具体以下：

• 全部关于已存在的键的查询都由节点”A”处理。
• 全部关于不存在于节点 A 的键都由节点”B”处理。

这种方式让咱们能够不用在节点 A 中建立新的键。同时，一个叫作 redis-trib 的特殊客户端，它也是 Redis 集群的配置程序（configuration utility），会确保把已存在的键从节点 A 移到节点 B。这经过如下命令实现：

CLUSTER GETKEYSINSLOT slot count

上面这个命令会返回指定的哈希槽中 count 个键。对于每一个返回的键，redis-trib 向节点 A 发送一个 MIGRATE 命令，这样会以原子性的方式（在移动键的过程当中两个节点都被锁住，以避免出现竞争情况）把指定的键从节点 A 移到节点 B。如下是 MIGRATE 的工做原理：

MIGRATE target_host target_port key target_database id timeout

执行 MIGRATE 命令的节点会链接到目标节点，把序列化后的 key 发送过去，一旦收到 OK 回复就会从它本身的数据集中删除老的 key。因此从一个外部客户端看来，在某个时间点，一个 key 要不就存在于节点 A 中要不就存在于节点 B 中。

在 Redis 集群中，不须要指定一个除了 0 号以外的数据库，但 MIGRATE 命令能用于其余跟 Redis 集群无关的的任务，因此它是一个足够通用的命令。MIGRATE 命令被优化了，使得即便在移动像长列表这样的复杂键仍然能作到快速。 不过当在重配置一个拥有不少键且键的数据量都很大的集群的时候，这个过程就并不那么好了，对于使用数据库的应用程序来讲就会有延时这个限制。

参数文档：http://www.redis.cn/topics/cluster-spec.html、http://www.redis.cn/topics/cluster-tutorial.html