redis集群scan_Redis 集群规范

Redis 集群规范¶

引言¶

这个文档是正在开发中的 Redis 集群功能的规范(specification)文档，

文档分为两个部分：

第一部分介绍目前已经在 unstable 分支中实现了的那些功能。

第二部分介绍目前仍未实现的那些功能。

文档各个部分的内容可能会随着集群功能的设计修改而发生改变，

其中，

未实现功能发生修改的几率比已实现功能发生修改的几率要高。

这个规范包含了编写客户端库(client library)所需的全部知识，

不过请注意，

这里列出的一部分细节可能会在未来发生变化。

什么是 Redis 集群？¶

Redis 集群是一个分布式(distributed)、容错(fault-tolerant)的 Redis 实现，

集群可以使用的功能是普通单机 Redis 所能使用的功能的一个子集(subset)。

Redis 集群中不存在中心(central)节点或者代理(proxy)节点，

集群的其中一个主要设计目标是达到线性可扩展性(linear scalability)。

Redis 集群为了保证一致性(consistency)而牺牲了一部分容错性：

系统会在保证对网络断线(net split)和节点失效(node failure)具有有限(limited)抵抗力的前提下，

尽可能地保持数据的一致性。

Note

集群将节点失效视为网络断线的其中一种特殊情况。

集群的容错功能是通过使用主节点(master)和从节点(slave)两种角色(role)的节点(node)来实现的：

主节点和从节点使用完全相同的服务器实现，

它们的功能(functionally)也完全一样，

但从节点通常仅用于替换失效的主节点。

不过，

如果不需要保证“先写入，后读取”操作的一致性(read-after-write consistency)，

那么可以使用从节点来执行只读查询。

Redis 集群实现的功能子集¶

Redis 集群实现了单机 Redis 中，

所有处理单个数据库键的命令。

针对多个数据库键的复杂计算操作，

比如集合的并集操作、合集操作没有被实现，

那些理论上需要使用多个节点的多个数据库键才能完成的命令也没有被实现。

在将来，

用户也许可以通过 MIGRATE COPY 命令，

在集群的计算节点(computation node)中执行针对多个数据库键的只读操作，

但集群本身不会去实现那些需要将多个数据库键在多个节点中移来移去的复杂多键命令。

Redis 集群不像单机 Redis 那样支持多数据库功能，

集群只使用默认的 0 号数据库，

并且不能使用 SELECT 命令。

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

Redis 集群中的节点有以下责任：

持有键值对数据。

记录集群的状态，包括键到正确节点的映射(mapping keys to right nodes)。

自动发现其他节点，识别工作不正常的节点，并在有需要时，在从节点中选举出新的主节点。

为了执行以上列出的任务，

集群中的每个节点都与其他节点建立起了“集群连接(cluster bus)”，

该连接是一个 TCP 连接，

使用二进制协议进行通讯。

节点之间使用 Gossip 协议 来进行以下工作：

传播(propagate)关于集群的信息，以此来发现新的节点。

向其他节点发送 PING 数据包，以此来检查目标节点是否正常运作。

在特定事件发生时，发送集群信息。

除此之外，

集群连接还用于在集群中发布或订阅信息。

因为集群节点不能代理(proxy)命令请求，

所以客户端应该在节点返回 -MOVED 或者 -ASK 转向(redirection)错误时，

自行将命令请求转发至其他节点。

因为客户端可以自由地向集群中的任何一个节点发送命令请求，

并可以在有需要时，

根据转向错误所提供的信息，

将命令转发至正确的节点，

所以在理论上来说，

客户端是无须保存集群状态信息的。

不过，

如果客户端可以将键和节点之间的映射信息保存起来，

可以有效地减少可能出现的转向次数，

籍此提升命令执行的效率。

键分布模型¶

Redis 集群的键空间被分割为 16384 个槽(slot)，

集群的最大节点数量也是 16384 个。

Note

推荐的最大节点数量为 1000 个左右。

每个主节点都负责处理 16384 个哈希槽的其中一部分。

当我们说一个集群处于“稳定”(stable)状态时，

指的是集群没有在执行重配置(reconfiguration)操作，

每个哈希槽都只由一个节点进行处理。

Note

重配置指的是将某个/某些槽从一个节点移动到另一个节点。

Note

一个主节点可以有任意多个从节点，

这些从节点用于在主节点发生网络断线或者节点失效时，

对主节点进行替换。

以下是负责将键映射到槽的算法：

HASH_SLOT = CRC16(key) mod 16384

以下是该算法所使用的参数：

算法的名称: XMODEM (又称 ZMODEM 或者 CRC-16/ACORN)

结果的长度: 16 位

多项数(poly): 1021 (也即是 x16 + x12 + x5 + 1)

初始化值: 0000

反射输入字节(Reflect Input byte): False

发射输出 CRC (Reflect Output CRC): False

用于 CRC 输出值的异或常量(Xor constant to output CRC): 0000

该算法对于输入 "123456789" 的输出: 31C3

附录 A 中给出了集群所使用的 CRC16 算法的实现。

CRC16 算法所产生的 16 位输出中的 14 位会被用到。

在我们的测试中，

CRC16 算法可以很好地将各种不同类型的键平稳地分布到 16384 个槽里面。

集群节点属性¶

每个节点在集群中都有一个独一无二的 ID ，

该 ID 是一个十六进制表示的 160 位随机数，

在节点第一次启动时由 /dev/urandom 生成。

节点会将它的 ID 保存到配置文件，

只要这个配置文件不被删除，

节点就会一直沿用这个 ID 。

节点 ID 用于标识集群中的每个节点。

一个节点可以改变它的 IP 和端口号，

而不改变节点 ID 。

集群可以自动识别出 IP/端口号的变化，

并将这一信息通过 Gossip 协议广播给其他节点知道。

以下是每个节点都有的关联信息，

并且节点会将这些信息发送给其他节点：

节点所使用的 IP 地址和 TCP 端口号。

节点的标志(flags)。

节点负责处理的哈希槽。

节点最近一次使用集群连接发送 PING 数据包(packet)的时间。

节点最近一次在回复中接收到 PONG 数据包的时间。

集群将该节点标记为下线的时间。

该节点的从节点数量。

如果该节点是从节点的话，那么它会记录主节点的节点 ID 。

如果这是一个主节点的话，那么主节点 ID 这一栏的值为 0000000 。

以上信息的其中一部分可以通过向集群中的任意节点(主节点或者从节点都可以)发送 CLUSTER NODES 命令来获得。

以下是一