【IT168技术】这篇文档主要是为了说明正在进展中的Redis集群功能。文档主要分为两个部分，前一部分主要介绍我在非稳定分支已完成的代码，后一部分主要介绍还有哪些功能待实现。

　　本文档所有的说明都有可能在将来由于设计原因而进行更改，而未实现的计划比已实现的功能更有可能会被更改。本文档包含了所有client library所需要的细节，但是client library的作者们需要提前意识到真正实现的细节在将来很有可能会有变化。

　　什么是Redis集群?

　　Redis集群是一个实现分布式并且允许单点故障的Redis高级版本。

　　Redis集群没有最重要或者说中心节点，这个版本最主要的一个目标是设计一个线性可伸缩(可随意增删节点?)的功能。

　　Redis集群为了数据的一致性可能牺牲部分允许单点故障的功能，所以当网络故障和节点发生故障时这个系统会尽力去保证数据的一致性和有效性。(这里我们认为节点故障是网络故障的一种特殊情况)

　　为了解决单点故障的问题，我们同时需要masters 和 slaves。 即使主节点(master)和从节点(slave)在功能上是一致的，甚至说他们部署在同一台服务器上，从节点也仅用以替代故障的主节点。 实际上应该说 如果对从节点没有read-after-write(写并立即读取数据 以免在数据同步过程中无法获取数据)的需求，那么从节点仅接受只读操作。

　　已实现子集

　　Redis集群会把所有的单一key存储在非分布式版本的Redis中。对于复合操作比如求并集求交集之类则未实现。

　　在将来，有可能会增加一种为“Computation Node”的新类型节点。这种节点主要用来处理在集群中multi-key的只读操作，但是对于multi-key的只读操作不会以集群传输到Computation Node节点再进行计算的方式实现。

　　Redis集群版本将不再像独立版本一样支持多数据库，在集群版本中只有database 0，并且SELECT命令是不可用的。

　　客户端与服务端在Redis集群版中的约定

　　在Redis集群版本中，节点有责任/义务保存数据和自身状态，这其中包括把数据(key)映射到正确的节点。所有节点都应该自动探测集群中的其他节点，并且在发现故障节点之后把故障节点的从节点更改为主节点(原文这里有“如果有需要” 可能是指需要设置或者说存在从节点)。

　　集群节点使用TCP bus和二进制协议进行互联并对任务进行分派。各节点使用gossip 协议发送ping packets给集群其他节点以确定其他节点是否正常工作。cluster bus也可以用来在节点间执行PUB/SUB命令。

　　当发现集群节点无应答的时候则会使用redirections errors -MOVED and -ASK命令并且会重定向至可用节点。理论上客户端可随意向集群中任意节点发送请求并获得重定向，也就是说客户端实际上并不用关心集群的状态。然而，客户端也可以缓存数据对应的节点这样可以免去服务端进行重定向的工作，这在一定程度上可以提高效率。

　　Keys分配模式

　　一个集群可以包含最多4096个节点(但是我们建议最多设置几百个节点)。

　　所有的主节点会控制4096个key空间的百分比。当集群稳定之后，也就是说不会再更改集群配置(更改配置指的增删节点)，那么一个节点将只为一个hash slot服务。(但是服务节点(主节点)可以拥有多个从节点用来防止单点故障)

　　用来计算key属于哪个hash slot的算法如下：

 　　这里我们会取CRC16后的12个字节。在我们的测试中，对于4096个slots， CRC16算法最合适。

　　集群节点特性

　　在集群中每个节点都拥有唯一的名字。节点名为16进制的160 bit随机数，当节点获取到名字后将被立即启用。节点名将被永久保存到节点设置文件中，除非系统管理员手动删除节点配置文件。

　　节点名是集群中每个节点的身份证明。在不更改节点ID的情况下是允许修改节点IP和地址的。cluster bus会自动通过gossip协议获取更改后的节点设置。

　　每个节点可获知其他节点的信息包括：IP 端口、状态、管理的hash slots、cluster bus最后发送PING的时间、最后接收到PONG的时间、从节点数量、节点ID。

　　无论是主节点还是从节点都可以通过CLUSTER NODES命令来获取以上信息

　　示例如下：