Redis Cluster 理论知识

http://www.ttlsa.com/redis/redis-cluster-theoretical-knowledge/

Redis 集群的 TCP 端口(Redis Cluster TCP ports)

每个 Redis 集群节点需要两个 TCP 连接打开。正常的 TCP 端口用来服务客户端，例如 6379，加 10000 的端口用作数据端口，在上面的例子中就是 16379。 第二个大一些的端口用于集群总线(bus)，也就是使用二进制协议的点到点通信通道。集群总线被节点用 于错误检测，配置更新，故障转移授权等等。客户端不应该尝试连接集群总线端口，而应一直与正常的 Redis 命令端口通信，但是要确保在防火墙中打开了这两个端口，否则 Redis 集群的节点不能相互通信。 命令端口和集群总线端口的偏移量一直固定为 10000。 注意，为了让 Redis 集群工作正常，对每个节点： 1. 用于与客户端通信的正常的客户端通信端口(通常为 6379)需要开放给所有需要连接集群的客户端 以及其他集群节点(使用客户端端口来进行键迁移)。 2. 集群总线端口(客户端端口加 10000)必须从所有的其他集群节点可达。 如果你不打开这两个 TCP 端口，集群就无法正常工作。

Redis 集群的数据分片(Redis Cluster data sharding)

Redis 集群没有使用一致性哈希，而是另外一种不同的分片形式，每个键概念上是被我们称为哈希槽 (hash slot)的东西的一部分。 Redis 集群有 16384 个哈希槽，我们只是使用键的 CRC16 编码对 16384 取模来计算一个指定键所属的 哈希槽。 每一个 Redis 集群中的节点都承担一个哈希槽的子集，例如，你可能有一个 3 个节点的集群，其中：

 节点 A 包含从 0 到 5500 的哈希槽。

 节点 B 包含从 5501 到 11000 的哈希槽。

 节点 C 包含从 11001 到 16384 的哈希槽。

这可以让在集群中添加和移除节点非常容易。例如，如果我想添加一个新节点 D，我需要从节点 A，B， C 移动一些哈希槽到节点 D。同样地，如果我想从集群中移除节点 A，我只需要移动 A 的哈希槽到 B 和 C。 当节点 A 变成空的以后，我就可以从集群中彻底删除它。 因为从一个节点向另一个节点移动哈希槽并不需要停止操作，所以添加和移除节点，或者改变节点持有 的哈希槽百分比，都不需要任何停机时间(downtime)。

Redis cluster 架构(Redis Cluster Architecture)

 redis-cluster 架构图

架构细节:

 所有的 redis 节点彼此互联(PING-PONG 机制),内部使用二进制协议优化传输速度和带宽.

 节点的 fail 是通过集群中超过半数的节点检测失效时才生效.

 客户端与 redis 节点直连,不需要中间 proxy 层.客户端不需要连接集群所有节点,连接集群中任何一个 可用节点即可

 redis-cluster 把所有的物理节点映射到[0-16383]slot 上,cluster 负责维护 node<->slot<->value

redis-cluster 选举:容错

 领领着选举过程是集群中所有 master 参与,如果半数以上 master 节点与 master 节点通信超过 (cluster-node-timeout),认为当前 master 节点挂掉.

 什么时候整个集群不可用(cluster_state:fail)

a:如果集群任意 master 挂掉,且当前 master 没有 slave.集群进入 fail 状态,也可以理解成集群的 slot 映 射[0-16383]不完成时进入 fail 状态. ps : redis-3.0.0.rc1 加入 cluster-require-full-coverage 参数,默认关闭, 打开集群兼容部分失败.

b:如果集群超过半数以上 master 挂掉，无论是否有 slave 集群进入 fail 状态.

ps:当集群不可用时,所有对集群的操作做都不可用，收到((error) CLUSTERDOWN The cluster is down) 错误.

Redis 集群的主从模型(Redis Cluster master-slave model)

为了当部分节点失效时，或者无法与大多数节点通信时仍能保持可用，Redis 集群采用每个节点拥有 1(主 服务自身)到 N 个副本(N-1 个附加的从服务器)的主从模型。 在我们的例子中，集群拥有 A，B，C 三个节点，如果节点 B 失效集群将不能继续服务，因为我们不再 有办法来服务在 5501-11000 范围内的哈希槽。 但是，如果当我们创建集群后(或者稍后)，我们为每一个主服务器添加一个从服务器，这样最终的集群 就由主服务器 A，B，C 和从服务器 A1，B1，C1 组成，如果 B 节点失效系统仍能继续服务。 B1 节点复制 B 节点，于是集群会选举 B1 节点作为新的主服务器，并继续正确的运转。

Redis 集群的一致性保证(Redis Cluster consistency guarantees)

Redis 集群不保证强一致性。实践中，这意味着在特定的条件下，Redis 集群可能会丢掉一些被系统收 到的写入请求命令。

Redis 集群为什么会丢失写请求的第一个原因，是因为采用了异步复制。这意味着在写期间下面的事情 发生了：

 你的客户端向主服务器 B 写入。

 主服务器 B 回复 OK 给你的客户端。

 主服务器 B 传播写入操作到其从服务器 B1，B2 和 B3。

手动故障转移(Manual failover) 

有时候在主服务器事实上没有任何故障的情况下强制一次故障转移是很有用的。例如，为了升级主服务 器节点中的一个进程，可以对其进行故障转移使其变为一个从服务器，这样最小化了对可用性的影响。

Redis 集群支持使用 CLUSTER FAILOVER 命令来手动故障转移，必须在你想进行故障转移的主服务的 其中一个从服务器上执行。

手动故障转移很特别，和真正因为主服务器失效而产生的故障转移要更安全，因为采取了避免过程中数 据丢失的方式，仅当系统确认新的主服务器处理完了旧的主服务器的复制流时，客户端才从原主服务器切 换到新主服务器。

添加新节点(Adding a new node) 

添加一个新节点的过程基本上就是，添加一个空节点，然后，如果是作为主节点则移动一些数据进去， 如果是从节点则其作为某个节点的副本。

两种情况我们都会讨论，先从添加一个新的主服务器实例开始。

两种情况下，第一步要完成的都是添加一个空节点。

我们使用与其他节点相同的配置(端口号除外)在 7006 端口(我们已存在的 6 个节点已经使用了从 7000 到 7005 的端口)上开启一个新的节点，那么为了与我们之前的节点布局一致，你得这么做：

 在你的终端程序中开启一个新的标签窗口。

 进入 cluster-test 目录。

 创建一个名为 7006 的目录。

 在里面创建一个 redis.conf 的文件，类似于其它节点使用的文件，但是使用 7006 作为端口号。

 最后使用../redis-server ./redis.conf 启动服务器。

 

1	./redis-trib.rb add-node 127.0.0.1:7006 127.0.0.1:7000

添加副本节点(Adding a new node as a replica)

添加一个新副本可以有两种方式。显而易见的一种方式是再次使用 redis-trib，但是要使用—slave 选项， 像这样：

 

1	./redis-trib.rb add-node --slave 127.0.0.1:7006 127.0.0.1:7000

注意，这里的命令行完全像我们在添加一个新主服务器时使用的一样，所以我们没有指定要给哪个主服 务器添加副本。这种情况下，redis-trib 会添加一个新节点作为一个具有较少副本的随机的主服务器的副本。

但是，你可以使用下面的命令行精确地指定你想要的主服务器作为副本的目标：

 

1 2	./redis-trib.rb add-node --slave --master-id 3c3a0c74aae0b56170ccb03a76b60cfe7dc1912e 127. 0.0.1:7006 127.0.0.1:7000

移除节点(Removing a node)

要移除一个从服务器节点，只要使用 redis-trib 的 del-node 命令就可以：

 

1	./redis-trib del-node 127.0.0.1:7000 <node-id>

升级节点(Upgrading nodes in a Redis Cluster) 

升级从服务器节点很简单，因为你只需要停止节点然后用已更新的 Redis 版本重启。如果有客户端使用 从服务器节点分离读请求，它们应该能够在某个节点不可用时重新连接另一个从服务器。

升级主服务器要稍微复杂一些，建议的步骤是：

1. 使用 CLUSTER FAILOVER 来触发一次手工故障转移主服务器(请看本文档的手工故障转移小 节)。

2. 等待主服务器变为从服务器。

3. 像升级从服务器那样升级这个节点。

4. 如果你想让你刚刚升级的节点成为主服务器，触发一次新的手工故障转移，让升级的节点重新变 回主服务器