主从模式
主从模式，有主有从，就是通过一台Master服务器，和多台slave服务器构成的一种集群模式，我们主要介绍的是在这种模式下，他们的工作原理，是如何保持状态一致的。
主从模式中实现状态一致的技术就是复制（replication）
Redisde 复制功能主要分为同步（sync）和命令传播两个部分
同步：是将slave更新至master所处的状态的操作
命令传播：是在Master进行写操作后，让slave更新至最新状态的操作
sync
从服务器对主服务器的同步操作需要通过向主服务器发送 SYNC 命令来完成， 以下是 SYNC 命令的执行步骤：
1）从服务器向主服务器发送 SYNC 命令。
2）收到 SYNC 命令的主服务器执行 BGSAVE 命令， 在后台生成一个 RDB 文件， 并使用一个缓冲区记录从现在开始执行的所有写命令。
3）当主服务器的 BGSAVE 命令执行完毕时， 主服务器会将 BGSAVE 命令生成的 RDB 文件发送给从服务器， 从服务器接收并载入这个 RDB 文件， 将自己的数据库状态更新至主服务器执行 BGSAVE 命令时的数据库状态。
4）主服务器将记录在缓冲区里面的所有写命令发送给从服务器， 从服务器执行这些写命令， 将自己的数据库状态更新至主服务器数据库当前所处的状态。
命令传播
在同步操作执行完毕之后， 主从服务器两者的数据库将达到一致状态， 但这种一致并不是一成不变的 —— 每当主服务器执行客户端发送的写命令时， 主服务器的数据库就有可能会被修改， 并导致主从服务器状态不再一致。
所以此时就需要，当master接收到写操作后看，在执行操作时异步的将命令传播到slave，是的主从一致，防止主从数据不一致。
哨兵
当主数据库遇到异常问题宕机时，我们可以通过主动设置将从数据库升级为主数据库，以维持正常运行，但是这样做未免太麻烦了，所以在Redis2.8提供了哨兵工具来实现自动化的系统监控和故障恢复功能。
哨兵的主要作用就是两个：
1）监控主从数据库是否正常运行
2）master出现问题时，将slave替换master
主从切换过程：
（1） slave leader升级为master
（2） 其他slave修改为新master的slave
（3） 客户端修改连接
（4） 老的master如果重启成功，变为新master的slave
集群
redis是一个开源的key value存储系统，受到了广大互联网公司的青睐。redis3.0版本之前只支持单例模式，在3.0版本及以后才支持集群
一个 Redis 集群通常由多个节点（node）组成，一节点就是一个redis实例， 在刚开始的时候， 每个节点都是相互独立的， 它们都处于一个只包含自己的集群当中， 要组建一个真正可工作的集群， 我们必须将各个独立的节点连接起来， 构成一个包含多个节点的集群。
当我们在一个node下，发起CLUSTER MEET 命令（CLUSTER MEET ）——后，就 可以让 node 节点与 ip 和 port 所指定的节点进行握手（handshake）， 当握手成功时， node节点就会将 ip 和 port 所指定的节点添加到 node 节点当前所在的集群中。
通过这个过程，我们就可以让几个相互独立的节点，通过握手联系在一起，放在一个集群中。
启动节点
一个节点就是一个运行在集群模式下的 Redis 服务器， Redis 服务器在启动时会根据 cluster-enabled 配置选项的是否为 yes 来决定是否开启服务器的集群模式， 如图 IMAGE_NODE_OR_SERVER 所示。
CLUSTER MEET 命令的实现
他们是怎么握手的呢？
- 收到命令的节点 A 将与节点 B 进行握手（handshake）， 以此来确认彼此的存在， 并为将来的进一步通信打好基础：
2)节点 A 会为节点 B 创建一个 clusterNode 结构， 并将该结构添加到自己的 clusterState.nodes 字典里面。
之后， 节点 A 将根据 CLUSTER MEET 命令给定的 IP 地址和端口号， 向节点 B 发送一条 MEET 消息（message）。
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 消息， 握手完成。
图 IMAGE_HANDSHAKE 展示了以上步骤描述的握手过程。
之后， 节点 A 会将节点 B 的信息通过 Gossip 协议传播给集群中的其他节点， 让其他节点也与节点 B 进行握手， 最终， 经过一段时间之后， 节点 B 会被集群中的所有节点认识。
集群的工作
1）节点通过握手来将其他节点添加到自己所处的集群当中
2）集群中的 16384 个槽可以分别指派给集群中的各个节点， 每个节点都会记录哪些槽指派给了自己， 而哪些槽又被指派给了其他节点。
3）节点在接到一个命令请求时， 会先检查这个命令请求要处理的键所在的槽是否由自己负责， 如果不是的话， 节点将向客户端返回一个MOVED 错误， MOVED 错误携带的信息可以指引客户端转向至正在负责相关槽的节点。
4）对 Redis 集群的重新分片工作是由客户端执行的， 重新分片的关键是将属于某个槽的所有键值对从一个节点转移至另一个节点。
5）如果节点 A 正在迁移槽 i 至节点 B ， 那么当节点 A 没能在自己的数据库中找到命令指定的数据库键时， 节点 A 会向客户端返回一个 ASK 错误， 指引客户端到节点 B 继续查找指定的数据库键。
6）MOVED 错误表示槽的负责权已经从一个节点转移到了另一个节点， 而 ASK 错误只是两个节点在迁移槽的过程中使用的一种临时措施。
7）集群里的从节点用于复制主节点， 并在主节点下线时， 代替主节点继续处理命令请求。
8）集群中的节点通过发送和接收消息来进行通讯， 常见的消息包括 MEET 、 PING 、 PONG 、 PUBLISH 、 FAIL 五种。