Redis5.0版是Redis产品的重大版本发布，它的最新特点：
1 新的流数据类型(Stream data type) https://redis.io/topics/streams-intro 2 新的 Redis 模块 API：定时器、集群和字典 API(Timers, Cluster and Dictionary APIs) 3 RDB 增加 LFU 和 LRU 信息 4 集群管理器从 Ruby (redis-trib.rb) 移植到了redis-cli 中的 C 语言代码 5 新的有序集合(sorted set)命令：ZPOPMIN/MAX 和阻塞变体(blocking variants) 6 升级 Active defragmentation 至 v2 版本 7 增强 HyperLogLog 的实现 8 更好的内存统计报告 9 许多包含子命令的命令现在都有一个 HELP 子命令 10 客户端频繁连接和断开连接时，性能表现更好 11 许多错误修复和其他方面的改进 12 升级 Jemalloc 至 5.1 版本 13 引入 CLIENT UNBLOCK 和 CLIENT ID 14 新增 LOLWUT 命令 http://antirez.com/news/123 15 在不存在需要保持向后兼容性的地方，弃用 "slave" 术语 16 网络层中的差异优化 17 Lua 相关的改进 18 引入动态的 HZ(Dynamic HZ) 以平衡空闲 CPU 使用率和响应性 19 对 Redis 核心代码进行了重构并在许多方面进行了改进
Redis Cluster总览
一、简介
在官方文档Cluster Spec中，作者详细介绍了Redis集群为什么要设计成现在的样子。最核心的目标有三个：
1 性能：增加集群功能后不能对性能产生太大影响，所以Redis采取了P2P而非Proxy方式、异步复制、客户端重定向等设计。 2 水平扩展：文档中称可以线性扩展到1000结点。 3 可用性：在Cluster推出之前，可用性要靠Sentinel保证。有了集群之后也自动具有了Sentinel的监控和自动Failover能力。
如果需要全面的了解，那一定要看官方文档Cluster Tutorial。
Redis Cluster是一个高性能高可用的分布式系统。由多个Redis实例组成的整体，数据按照Slot存储分布在多个Redis实例上，通过Gossip协议来进行节点之间通信。功能特点如下：
1 所有的节点相互连接 2 集群消息通信通过集群总线通信，集群总线端口大小为客户端服务端口+10000（固定值） 3 节点与节点之间通过二进制协议进行通信 4 客户端和集群节点之间通信和通常一样，通过文本协议进行 5 集群节点不会代理查询 6 数据按照Slot存储分布在多个Redis实例上 7 集群节点挂掉会自动故障转移 8 可以相对平滑扩/缩容节点
关于Cluster相关的源码可以见：src/cluster.c和src/cluster.h
二、通信
2.1 CLUSTER MEET
需要组建一个真正的可工作的集群，我们必须将各个独立的节点连接起来，构成一个包含多个节点的集群。连接各个节点的工作使用CLUSTER MEET命令来完成。
CLUSTER MEET <ip> <port>
CLUSTER MEET命令实现：
1 节点 A 会为节点 B 创建一个 clusterNode 结构，并将该结构添加到自己的 clusterState.nodes 字典里面。 2 节点A根据CLUSTER MEET命令给定的IP地址和端口号，向节点B发送一条MEET消息。 3 节点B接收到节点A发送的MEET消息，节点B会为节点A创建一个clusterNode结构，并将该结构添加到自己的clusterState.nodes字典里面。 4 节点B向节点A返回一条PONG消息。 5 节点A将受到节点B返回的PONG消息，通过这条PONG消息节点A可以知道节点B已经成功的接收了自己发送的MEET消息。 6 节点A将向节点B返回一条PING消息。 7 节点B将接收到的节点A返回的PING消息，通过这条PING消息节点B可以知道节点A已经成功的接收到了自己返回的PONG消息，握手完成。 8 节点A会将节点B的信息通过Gossip协议传播给集群中的其他节点，让其他节点也与节点B进行握手，最终，经过一段时间后，节点B会被集群中的所有节点认识。
2.2 消息处理 clusterProcessPacket
1 更新接收消息计数器 2 查找发送者节点并且不是handshake节点 3 更新自己的epoch和slave的offset信息 4 处理MEET消息，使加入集群 5 从goosip中发现未知节点，发起handshake 6 对PING，MEET回复PONG 7 根据收到的心跳信息更新自己clusterState中的master-slave，slots信息 8 对FAILOVER_AUTH_REQUEST消息，检查并投票 9 处理FAIL，FAILOVER_AUTH_ACK，UPDATE信息
2.3 定时任务clusterCron
1 对handshake节点建立Link，发送Ping或Meet 2 向随机几点发送Ping 3 如果是从查看是否需要做Failover 4 统计并决定是否进行slave的迁移，来平衡不同master的slave数 5 判断所有pfail报告数是否过半数
2.4 心跳数据
- 发送消息头信息Header
- 所负责slots的信息
- 主从信息
- ip, port信息
- 状态信息
- 发送其他节点Gossip信息
- ping_sent, pong_received
- ip, port信息
- 状态信息，比如发送者认为该节点已经不可达，会在状态信息中标记其为PFAIL或FAIL
clusterMsg结构的currentEpoch、sender、myslots等属性记录了发送者自身的节点信息，接收者会根据这些信息，在自己的clusterState.nodes字典里找到发送者对应的clusterNode结构，并对结构进行更新。
Redis集群中的各个节点通过Gossip协议来交换各自关于不同节点的状态信息，其中Gossip协议由MEET、PING、PONG三种消息实现，这三种消息的正文都由两个clusterMsgDataGossip结构组成。
每次发送MEET、PING、PONG消息时，发送者都从自己的已知节点列表中随机选出两个节点(可以是主节点或者从节点),并将这两个被选中节点的信息分别保存到两个结构中。当接收者收到消息时，接收者会访问消息正文中的两个结构，并根据自己是否认识clusterMsgDataGossip结构中记录的被选中节点进行操作:
1 如果被选中节点不存在于接收者的已知节点列表，那么说明接收者是第一次接触到被选中节点，接收者将根据结构中记录的IP地址和端口号等信息，与被选择节点进行握手。 2 如果被选中节点已经存在于接收者的已知节点列表，那么说明接收者之前已经与被选中节点进行过接触，接收者将根据clusterMsgDataGossip结构记录的信息，对被选中节点对应的clusterNode结构进行更新。
2.5 数据结构
clusterNode 结构保存了一个节点的当前状态， 如节点的创建时间、节点的名字、节点当前的配置纪元、节点的 IP 和端口等：
1 slots：位图，由当前clusterNode负责的slot为1 2 salve, slaveof：主从关系信息 3 ping_sent, pong_received：心跳包收发时间 4 clusterLink *link：节点间的连接 5 list *fail_reports：收到的节点不可达投票
clusterState 结构记录了在当前节点的集群目前所处的状态：
1 myself：指针指向自己的clusterNode 2 currentEpoch：当前节点的最大epoch，可能在心跳包的处理中更新 3 nodes：当前节点记录的所有节点，为clusterNode指针数组 4 slots：slot与clusterNode指针映射关系 5 migrating_slots_to,importing_slots_from：记录slots的迁移信息 6 failover_auth_time,failover_auth_count,failover_auth_sent,failover_auth_rank,failover_auth_epoch：Failover相关信息
clusterLink 结构保存了连接节点所需的有关信息， 比如套接字描述符， 输入缓冲区和输出缓冲区。
三、数据分布及槽信息
3.1 槽（slot）概念
Redis Cluster中有一个16384长度的槽的概念，他们的编号为0、1、2、3……16382、16383。这个槽是一个虚拟的槽，并不是真正存在的。正常工作的时候，Redis Cluster中的每个Master节点都会负责一部分的槽，当有某个key被映射到某个Master负责的槽，那么这个Master负责为这个key提供服务，至于哪个Master节点负责哪个槽，这是可以由用户指定的，也可以在初始化的时候自动生成。在Redis Cluster中，只有Master才拥有槽的所有权，如果是某个Master的slave，这个slave只负责槽的使用，但是没有所有权。
3.2 数据分片
在Redis Cluster中，拥有16384个slot，这个数是固定的，存储在Redis Cluster中的所有的键都会被映射到这些slot中。数据库中的每个键都属于这 16384 个哈希槽的其中一个，集群使用公式 CRC16(key) % 16384 来计算键 key 属于哪个槽，其中 CRC16(key) 语句用于计算键 key 的 CRC16 校验和。集群中的每个节点负责处理一部分哈希槽。
3.3 节点的槽指派信息
clusterNode结构的slots属性和numslot属性记录了节点负责处理那些槽：
struct clusterNode { //… unsignedchar slots[16384/8]; };
Slots属性是一个二进制位数组(bitarray)，这个数组的长度为16384/8=2048个字节，共包含16384个二进制位。Master节点用bit来标识对于某个槽自己是否拥有。比如对于编号为1的槽，Master只要判断序列的第二位（索引从0开始）是不是为1即可。时间复杂度为O（1）。
3.4 集群所有槽的指派信息
通过将所有槽的指派信息保存在clusterState.slots数组里面，程序要检查槽i是否已经被指派，又或者取得负责处理槽i的节点，只需要访问clusterState.slots[i]的值即可，复杂度仅为O（1）。
3.5 请求重定向
由于每个节点只负责部分slot，以及slot可能从一个节点迁移到另一节点，造成客户端有可能会向错误的节点发起请求。因此需要有一种机制来对其进行发现和修正，这就是请求重定向。有两种不同的重定向场景：
a) MOVED错误
-
请求的key对应的槽不在该节点上，节点将查看自身内部所保存的哈希槽到节点 ID 的映射记录，节点回复一个 MOVED 错误。
-
需要客户端进行再次重试。
b) ASK错误
-
请求的key对应的槽目前的状态属于MIGRATING状态，并且当前节点找不到这个key了，节点回复ASK错误。ASK会把对应槽的IMPORTING节点返回给你，告诉你去IMPORTING的节点尝试找找。
-
客户端进行重试 首先发送ASKING命令，节点将为客户端设置一个一次性的标志（flag），使得客户端可以执行一次针对 IMPORTING 状态的槽的命令请求，然后再发送真正的命令请求。
-
不必更新客户端所记录的槽至节点的映射。
四、数据迁移
当槽x从Node A向Node B迁移时，Node A和Node B都会有这个槽x，Node A上槽x的状态设置为MIGRATING，Node B上槽x的状态被设置为IMPORTING。
MIGRATING状态
-
如果key存在则成功处理
-
如果key不存在，则返回客户端ASK，客户端根据ASK首先发送ASKING命令到目标节点，然后发送请求的命令到目标节点
-
当key包含多个命令，
-
如果都存在则成功处理
-
如果都不存在，则返回客户端ASK
-
如果一部分存在，则返回客户端TRYAGAIN，通知客户端稍后重试，这样当所有的key都迁移完毕的时候客户端重试请求的时候回得到ASK，然后经过一次重定向就可以获取这批键
-
此时不刷新客户端中node的映射关系
IMPORTING状态
-
如果key不在该节点上，会被MOVED重定向，刷新客户端中node的映射关系
-
如果是ASKING命令则命令会被执行，key不在迁移的节点已经被迁移到目标的节点
-
Key不存在则新建
4.1 读写请求
槽里面的key还未迁移，并且槽属于迁移中。
假如槽x在Node A，需要迁移到Node B上，槽x的状态为migrating，其中的key1还没轮到迁移。此时访问key1则先计算key1所在的Slot，存在key1则直接返回。
4.2 MOVED请求
槽里面的key已经迁移过去，并且槽属于迁移完。
假如槽x在Node A，需要迁移到Node B上，迁移完成。此时访问key1则先计算key1所在的Slot，因为已经迁移至Node B上，Node A上不存在，则返回 moved slotid IP:PORT，再根据返回的信息去Node B访问key1。
4.3 ASK请求
槽里面的key已经迁移完，并且槽属于迁移中的状态。
假如槽x在Node A，需要迁移到Node B上，迁移完成，但槽x的状态为migrating。此时访问key1则先计算key1所在的Slot，不存在key1则返回ask slotid IP:PORT，再根据返回的信息发送asking请求到Node B，最后没问题后再去Node B上访问key1。
五、通信故障
5.1 故障检测
集群中的每个节点都会定期地向集群中的其他节点发送PING消息，以此交换各个节点状态信息，检测各个节点状态：在线状态、疑似下线状态PFAIL、已下线状态FAIL。
当主节点A通过消息得知主节点B认为主节点D进入了疑似下线(PFAIL)状态时,主节点A会在自己的clusterState.nodes字典中找到主节点D所对应的clusterNode结构，并将主节点B的下线报告(failure report)添加到clusterNode结构的fail_reports链表中。
struct clusterNode { //... //记录所有其他节点对该节点的下线报告 list*fail_reports; //... };
如果集群里面，半数以上的主节点都将主节点D报告为疑似下线，那么主节点D将被标记为已下线(FAIL)状态，将主节点D标记为已下线的节点会向集群广播主节点D的FAIL消息，所有收到FAIL消息的节点都会立即更新nodes里面主节点D状态标记为已下线。
将 node 标记为 FAIL 需要满足以下两个条件：
1 有半数以上的主节点将 node 标记为 PFAIL 状态。 2 当前节点也将 node 标记为 PFAIL 状态。
5.2 多个从节点选主
选新主的过程基于Raft协议选举方式来实现的：
1 当从节点发现自己的主节点进行已下线状态时，从节点会广播一条CLUSTERMSG_TYPE_FAILOVER_AUTH_REQUEST消息，要求所有收到这条消息，并且具有投票权的主节点向这个从节点投票 2 如果一个主节点具有投票权，并且这个主节点尚未投票给其他从节点，那么主节点将向要求投票的从节点返回一条，CLUSTERMSG_TYPE_FAILOVER_AUTH_ACK消息，表示这个主节点支持从节点成为新的主节点 3 每个参与选举的从节点都会接收CLUSTERMSG_TYPE_FAILOVER_AUTH_ACK消息,并根据自己收到了多少条这种消息来统计自己获得了多少主节点的支持 4 如果集群里有N个具有投票权的主节点，那么当一个从节点收集到大于等于集群N/2+1张支持票时，这个从节点就成为新的主节点 5 如果在一个配置纪元没有从能够收集到足够的支持票数，那么集群进入一个新的配置纪元，并再次进行选主，直到选出新的主节点为止
5.3 故障转移
当从节点发现自己的主节点变为已下线(FAIL)状态时，便尝试进Failover，以期成为新的主。
以下是故障转移的执行步骤：
1 从下线主节点的所有从节点中选中一个从节点 2 被选中的从节点执行SLAVEOF NO NOE命令，成为新的主节点 3 新的主节点会撤销所有对已下线主节点的槽指派，并将这些槽全部指派给自己 4 新的主节点对集群进行广播PONG消息，告知其他节点已经成为新的主节点 5 新的主节点开始接收和处理槽相关的请求
总结：
Redis Cluster采用无中心节点方式实现，无需proxy代理，客户端直接与redis集群的每个节点连接，根据同样的hash算法计算出key对应的slot，然后直接在slot对应的Redis上执行命令。从CAP定理来看，Cluster支持了AP（Availability&Partition-Tolerancy），这样让Redis从一个单纯的NoSQL内存数据库变成了分布式NoSQL数据库。
参考文档：