Redis集群实现方式

Redis采用数据分区和主从模式实现了分布式集群管理方式，数据分区实现了横向扩展，主从模式实现了故障恢复。

Redis集群示意图

数据分区

Redis集群将数据分区后存储在多个节点上，即不同的分区存储在不同的节点上，每个节点可以存储多个分区。每个分区在Redis中也被称为“hash slot”，Redis集群中总共规划了16384个分区。

例如：当集群中有3个节点时，节点A将包含0-5460分区，节点B将包含5461-10922分区，节点C将包含10923-16383分区。

每个key将会存储到一个唯一的分区中，每个分区其实就是一组key的集合，两者对应关系为：key的CRC16校验码%16384=hash slot（分区标记）.可见Redis并没有像Memecache一样使用一致性哈希。社区说采用此规则的key分布是相当的均匀，在我们的测试中也印证了这一点。

在Redis集群中添加或者移除一个节点时相当容易的事情。例如：添加新节点D时，需要做的只是从A、B、C节点中移动一些分区给D。类似的，移除A时，只需将原属A的分区移动给B和C，等A变空时移除即可。

节点间的分区移动不需要停止服务，所以添加节点、移除节点或者改变节点的分区数量不需要停止集群服务。

客户端访问集群时，理论上可以访问集群中的任一节点。此时，被访问的数据可能不存在于被访问的节点中，但是被访问节点能自动获知目标节点，并重定向客户端的访问，即将目标节点地址返回给客户端，客户端再次发起访问请求。当然，好的客户端工具应该实现数据分区和节点对应关系的缓存，并在对应关系发生改变时能自动更新。目前，包括Jedis在内的几个客户端工具已经实现了此功能。

主-从模型（master-slave model）

Redis集群采用了主-从模型，即一个节点可以有N个副本，其中一个为主节点，N-1个为从节点。

主-从模型可以应对集群中部分节点故障的场景。例如：在上述集群的例子中，如果节点B发生故障，由于分区5461-10922不能访问，所以集群会不可用。如果每个主节点有一个从节点，即A、B、C为主节点，A1、B1、C1为从节点。此时，如果B节点故障，集群则推举B1作为新的主节点，集群对外服务正常。

注意：1.从节点可在集群创建时添加，也可后向追加。2.如果B和B1同时发生故障，则集群仍然不可用。

Redis集群中，每个节点需要使用两个TCP连接。第一个端口服务于客户端，例如默认的端口6379。第二个端口值总是在第一个之上增加10000，例如：16379.

第二个端口用于集群总线，这是一个使用二进制协议的节点和节点之间的通信通道。集群总线可用于失败检测、配置更新、故障转移授权等。客户端只使用第一个端口，从来不会使用第二个端口。

一个主节点可以有多个从节点。当从节点首次或者重连主节点时，主节点会进行后台存储，即将数据snapshot为磁盘上的rdb文件，也将rdb文件发给从节点进行存储。后台存储过程中以及之后的产生的写操作，主节点都会异步的发送到从节点，从节点执行这些操作以保证数据同步。默认情况下，从节点对客户端只提供读服务。

由于主从之间是异步传输，所以存在丢失数据的风险。例如：客户端写主节点B，B回复客户端OK，B传送写操作到从节点B1、B2和B3. 由于B在回复客户端前，不会等待从节点的确认。所以如果此时B发生故障，虽然从节点会被推举出一个主节点，但是还没有传送到从节点的数据将永远丢失了。