redis学习笔记六：Redis集群机制

主从机制中，主服务器可能存在单点故障，万一主服务器宕机，这是个麻烦事情，所以Redis提供了Redis-Sentinel，以此来实现主从切换的功能，类似于zookeeper。

Sentinel（哨兵）

Redis-Sentinel是Redis官方推荐的高可用性(HA)解决方案，当用Redis做master-slave的高可用方案时，假如master宕机了，Redis本身(包括它的很多客户端)都没有实现自动进行主备切换，而Redis-Sentinel本身也是一个独立运行的进程，它能监控多个master-slave集群，发现master宕机后能进行自动切换。

工作原理

哨兵(sentinel) 是一个分布式系统,你可以在一个架构中运行多个哨兵(sentinel) 进程,这些进程使用流言协议(gossipprotocols)来接收关于Master是否下线的信息,并使用投票协议(agreement protocols)来决定是否执行自动故障迁移,以及选择哪个Slave作为新的Master.
　　每个哨兵(sentinel) 会向其它哨兵(sentinel)、master、slave定时发送消息,以确认对方是否”活”着,如果发现对方在指定时间(可配置)内未回应,则暂时认为对方已挂(所谓的”主观认为宕机” Subjective Down,简称sdown).
若“哨兵群”中的多数sentinel,都报告某一master没响应,系统才认为该master"彻底死亡"(即:客观上的真正down机,Objective Down,简称odown),通过一定的vote算法,从剩下的slave节点中,选一台提升为master,然后自动修改相关配置.
　　虽然哨兵(sentinel) 释出为一个单独的可执行文件 redis-sentinel ,但实际上它只是一个运行在特殊模式下的 Redis 服务器，你可以在启动一个普通 Redis 服务器时通过给定 --sentinel 选项来启动哨兵(sentinel).

主要功能

它的主要功能有以下几点

• 监控（Monitoring）：不断地检查redis的主服务器和从服务器是否运作正常。
• 提醒（Notification）：如果发现某个redis服务器运行出现状况，可以通过 API 向管理员或者其他应用程序发送通知。
• 自动故障迁移（Automaticfailover）：能够进行自动切换。当一个主服务器不能正常工作时，会将失效主服务器的其中一个从服务器升级为新的主服务器，并让失效主服务器的其他从服务器改为复制新的主服务器； 当客户端试图连接失效的主服务器时， 集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效服务器。

哨兵机制是有缺点的：

1.主从服务器的数据要经常进行主从复制，这样造成性能下降。

2.当主服务器宕机后，从服务器切换成主服务器的那段时间，服务是不能用的。

Sentinel集群选举Leader

如果需要从redis集群选举一个节点为主节点，首先需要从Sentinel集群中选举一个Sentinel节点作为Leader。
每一个Sentinel节点都可以成为Leader，当一个Sentinel节点确认redis集群的主节点主观下线后，会请求其他Sentinel节点要求将自己选举为Leader。被请求的Sentinel节点如果没有同意过其他Sentinel节点的选举请求，则同意该请求(选举票数+1)，否则不同意。
如果一个Sentinel节点获得的选举票数达到Leader最低票数(quorum和Sentinel节点数/2+1的最大值)，则该Sentinel节点选举为Leader；否则重新进行选举。

Sentinel Leader决定新主节点

当Sentinel集群选举出Sentinel Leader后，由Sentinel Leader从redis从节点中选择一个redis节点作为主节点：

1. 过滤故障的节点
2. 选择优先级slave-priority最大的从节点作为主节点，如不存在则继续
3. 选择复制偏移量（数据写入量的字节，记录写了多少数据。主服务器会把偏移量同步给从服务器，当主从的偏移量一致，则数据是完全同步）最大的从节点作为主节点，如不存在则继续
4. 选择runid（redis每次启动的时候生成随机的runid作为redis的标识）最小的从节点作为主节点

Redis官方集群方案 Redis Cluster

Redis在3.0版正式引入了集群这个特性。Redis集群是一个分布式（distributed）、容错（fault-tolerant）的 Redis内存K/V服务， 集群可以使用的功能是普通单机 Redis 所能使用的功能的一个子集（subset），比如Redis集群并不支持处理多个keys的命令,因为这需要在不同的节点间移动数据,从而达不到像Redis那样的性能,在高负载的情况下可能会导致不可预料的错误。

Redis集群的几个重要特征：
　　(1). Redis 集群的分片特征在于将键空间分拆了16384个槽位，每一个节点负责其中一些槽位。
　　(2). Redis提供一定程度的可用性,可以在某个节点宕机或者不可达的情况下继续处理命令.
　　(3). Redis 集群中不存在中心（central）节点或者代理（proxy）节点， 集群的其中一个主要设计目标是达到线性可扩展性（linear scalability）。

Retis Cluster的架构图，如下：

Redis Cluster特点如下：

1. 所有的节点相互连接；
2. 集群消息通信通过集群总线通信，，集群总线端口大小为客户端服务端口+10000，这个10000是固定值；
3. 节点与节点之间通过二进制协议进行通信；
4. 客户端和集群节点之间通信和通常一样，通过文本协议进行；
5. 集群节点不会代理查询；

Redis Cluster分区实现原理

1、槽（slot）概念
　　Redis Cluster中有一个16384长度的槽的概念，他们的编号为0、1、2、3……16382、16383。这个槽是一个虚拟的槽，并不是真正存在的。正常工作的时候，Redis Cluster中的每个Master节点都会负责一部分的槽，当有某个key被映射到某个Master负责的槽，那么这个Master负责为这个key提供服务，至于哪个Master节点负责哪个槽，这是可以由用户指定的，也可以在初始化的时候自动生成（redis-trib.rb脚本）。这里值得一提的是，在Redis Cluster中，只有Master才拥有槽的所有权，如果是某个Master的slave，这个slave只负责槽的使用，但是没有所有权。Redis Cluster怎么知道哪些槽是由哪些节点负责的呢？某个Master又怎么知道某个槽自己是不是拥有呢？

2、位序列结构
　　Master节点维护着一个16384/8字节的位序列，Master节点用bit来标识对于某个槽自己是否拥有。比如对于编号为1的槽，Master只要判断序列的第二位（索引从0开始）是不是为1即可。

如上面的序列，表示当前Master拥有编号为1，134的槽。集群同时还维护着槽到集群节点的映射，是由长度为16384类型为节点的数组实现的，槽编号为数组的下标，数组内容为集群节点，这样就可以很快地通过槽编号找到负责这个槽的节点。位序列这个结构很精巧，即不浪费存储空间，操作起来又很便捷。

3、故障容忍度
　　
(1)心跳和gossip消息

Redis Cluster持续的交换PING和PONG数据包。这两种数据包的数据结构相同，都包含重要的配置信息，唯一的不同是消息类型字段。PING和PONG数据包统称为心跳数据包。

每个节点在每一秒钟都向一定数量的其它节点发送PING消息，这些节点应该向发送PING的节点回复一个PONG消息。节点会尽可能确保拥有每个其它节点在NOTE_TIMEOUT/2秒时间内的最新信息，否则会发送一个PING消息，以确定与该节点的连接是否正常。

假定一个Cluster有301个节点，NOTE_TIMEOUT为60秒，那么每30秒每个节点至少发送300个PING，即每秒10个PING， 整个Cluster每秒发送10x301=3010个PING。这个数量级的流量不应该会造成网络负担。

(2)故障检测。

Redis Cluster的故障检测用于检测一个master节点何时变得不再有效，即不能提供服务，从而应该让slave节点提升为master节点。如果提升失败，则整个Cluster失效，不再接受客户端的服务请求。当一个节点A向另外一个节点B发送了PING消息之后，经过NODE_TIMEOUT秒时间之后仍然没有收到PONG应答，则节点A认为节点B失效，节点A将为该节点B设置PFAIL标志。在 NODE_TIMEOUT * FAIL_REPORT_VALIDITY_MULT时间内，当Cluster中大多数节点认为节点B失效，即设置PFAIL标志时，这个Cluster认为节点B真的失效了，此时节点A将为节点B设置FAIL标志，并向所有节点发送FAIL消息。在一些特定情况下，拥有FAIL标志的节点，也可以清除掉FAIL标志。

Redis Cluster故障检测机制最终应该让所有节点都一致同意某个节点处于某个确定的状态。如果发生这样的情况少数节点确信某个节点为FAIL，同时有少数节点确认某个节点为非FAIL，则Redis Cluster最终会处于一个确定的状态：

情况1：最终大多数节点认为该节点FAIL，该节点最终实际为FAIL。

情况2：最终在N x NODE_TIMEOUT时间内，仍然只有少数节点将给节点标记为FAIL，此时最终会清除这个节点的FAIL标志。

Redis投票容错如下图所示：
　　
4、重定向客户端
文章开始讲到，Redis Cluster并不会代理查询，那么如果客户端访问了一个key并不存在的节点，这个节点是怎么处理的呢？比如我想获取key为msg的值，msg计算出来的槽编号为254，当前节点正好不负责编号为254的槽，那么就会返回客户端下面信息：

GET msg
-MOVED 254 127.0.0.1:6381

表示客户端想要的254槽由运行在IP为127.0.0.1，端口为6381的Master实例服务。如果根据key计算得出的槽恰好由当前节点负责，则当期节点会立即返回结果。这里明确一下，没有代理的Redis Cluster可能会导致客户端两次连接急群中的节点才能找到正确的服务，推荐客户端缓存连接，这样最坏的情况是两次往返通信。

5、 slots配置传播
　　Redis Cluster采用两种方式进行各个master节点的slots配置信息的传播。所谓slots配置信息，即master负责存储哪几个slots。

(1)心跳消息。

在PING/PONG消息中包含了所负责的slots配置信息。

(2)UPDATE消息。

当一个节点收到PING/PONG消息后，如果发现发送者的世代小于自己的世代，则向其发送UPDATE消息，来更新其有可能已经过时的slots配置信息。如果发现发送者的世代大于自己的世代，则用消息中的slots配置信息更新自己的slots配置信息。

重新分片
　　Redis Cluster的Resharding是指在Cluster内的节点之间转移slots中的键数据，一个slot之前由某个节点负责，在Resharding之后，可能由另外一个节点负责。

复制迁移
　　Redis Cluster在节点失效时，可能进行自动的slave节点重新配置，修改了Cluster中部分节点的master-slave复制关系，即复制迁移。

假定场景：

Cluster中有三个master节点：A、B、C。A有1个slave节点A1，B有1个slave节点B1，C有2个slave节点C1和C2。Aj节点失效了，将A1节点提升为master节点。

考虑不进行自动的slave节点的复制迁移：

如果A失效了，则会将唯一的slave节点A1提升为master节点，但是它没有slave节点。这时如果A1节点又失效了，则原来A节点负责的slots将失效，导致整个cluster不能正常工作。

考虑进行自动的slave节点的复制迁移：

如果A节点失效了，将唯一的slave节点A1提升为master节点，由于它没有slave节点，此时发现C节点有2个slave节点，将其中的C2节点重新配置为A1节点的子节点。这时，Cluster中每个master节点至少有1个slave节点。如果A1节点失效，可将C2节点提升为master。这样的结果是提高了整个cluster的可用性。

架构细节:

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

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

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

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

Redis 集群中内置了 16384 个哈希槽，当需要在 Redis 集群中放置一个 key-value 时，redis 先对 key 使用 crc16 算法算出一个结果，然后把结果对 16384 求余数，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，redis 会根据节点数量大致均等的将哈希槽映射到不同的节点