Redis高可用方案
Redis高可用方案
主从模式
主从概念说明
主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器，主从是哨兵和集群模式能够实施的基础。前者称为主节点（master），后者称为从节点（slave），数据的复制是单向的，只能由主节点到从节点。默认情况下，每台Redis服务器都是主节点，且一个主节点可以有零个或多个从节点，但一个从节点只能有一个主节点。一般主节点负责接收写请求，从节点负责接收读请求，从而实现读写分离。主从一般部署在不同机器上，复制时存在网络延时问题，使用参数repl-disable-tcp-nodelay选择是否关闭TCP_NODELAY，默认为关闭。
关闭：无论数据大小都会及时同步到从节点，占带宽，适用于主从网络好的场景。
开启：主节点每隔指定时间合并数据为TCP包节省带宽，默认为40毫秒同步一次，适用于网络环境复杂或带宽紧张，如跨机房。
缺点：延时，由于所有的写操作都是在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使得这个问题更加严重。
主从模式类型
1）一主一从：最基础的主从复制模型，主节点负责处理写请求，从节点负责处理读请求，主节点使用RDB持久化模式，从节点使用AOF持久化模式。
2）一主多从：一个主节点可以有多个从节点，但每个从节点只能有一个主节点。一主多从适用于写少读多的场景，多个从节点可以分担读请求负载，提升并发。
3）树状主从：上面的一主多从可以实现读请求的负载均衡，但当从节点数量多的时候，主节点的同步压力也是线性提升的，因此可以使用树状主从来分担主节点的同步压力。
主从使用场景
1）数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
2）故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复，实际上是一种服务的冗余。
3）负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务，分担服务器负载，尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。
4）读写分离：主库写、从库读，读写分离不仅可以提高服务器的负载能力，同时可根据需求的变化，改变从库的数量。
5）高可用基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础。
主从配置详解
配置主从可以在命令行或配置文件中配置，推荐开启从服务器的只读配置，否则的话在从节点的写操作不会同步到主节点会导致数据不一致。
===============================命令行===============================
# 在从服务器执行下面的命令成为或取消成为某节点的从节点
# slaveof 命令是异步的，不会阻塞。同时，从服务器现有的数据会先被清空，然后才会同步主服务器的数据。
# slaveof 主服务器的IP 端口号
slaveof host port
# 取消成为任何服务器的从服务器
slaveof no one
# 从服务器只读（推荐配置）
config set slave-read-only yes
# 查看主从信息
info replication
# 配置主节点ACL账号密码（Redis6开启ACL的情况）
config set masteruser username
config set masterauth password
===============================配置文件===============================
# 修改端口号
port 6380
# 在从服务器配置文件中添加下面的配置然后重启从服务器即可：
# 在从节点配置文件中新增下面两个配置即可指定成为某个主节点的从节点
# slaveof 主节点地址 主节点端口
slaveof host port
# 从服务器只读（推荐配置）
slave-read-only yes
主从复制原理
原理说明：
同步机制（先全量，后增量）：Redis可以使用主从同步，从从同步。第一次同步时，主节点做一次bgsave，并同时将后续修改操作记录到内存buffer，待完成后将rdb文件全量同步到复制节点，复制节点接受完成后将rdb镜像加载到内存。加载完成后，再通知主节点将期间修改的操作记录同步到复制节点进行重放就完成了同步过程。
主从复制过程大体可以分为3个阶段：连接建立阶段（即准备阶段）、数据同步阶段、命令传播阶段。在从节点执行slaveof命令后，复制过程便开始按下面的流程运作：
1）保存主节点信息：配置slaveof之后会在从节点保存主节点的信息。
2）主从建立socket连接：定时发现主节点以及尝试建立连接。
3）发送ping命令：从节点定时发送ping给主节点，主节点返回pong。若主节点没有返回pong或因阻塞无法响应导致超时，则主从断开，在下次定时任务时会从新ping主节点。
4）权限验证：若主节点开启了ACL或配置了requirepass参数，则从节点需要配置masteruser和masterauth参数才能保证主从正常连接。
5）同步数据集：首次连接，全量同步。
6）命令持续复制：全量同步完成后，保持增量同步。
7）断开重新连接时，全量同步。
=====================================================
Redis主从同步包括三个阶段。
第一阶段：主从库间建立连接、协商同步。
从库向主库发送psync命令，告诉它要进行数据同步。
主库收到psync命令后，响应FULLRESYNC命令（它表示第一次复制采用的是全量复制），并带上主库runID和主库目前的复制进度offset。
第二阶段：主库把数据同步到从库，从库收到数据后，完成本地加载。
主库执行bgsave命令，生成RDB文件，接着将文件发给从库。从库接收到RDB文件后，会先清空当前数据库，然后加载RDB文件。
主库把数据同步到从库的过程中，新来的写操作，会记录到replication buffer。
第三阶段，主库把新写的命令，发送到从库。
主库完成RDB发送后，会把replication buffer中的修改操作发给从库，从库再重新执行这些操作。这样主从库就实现同步啦。
主从复制问题
1）主从数据不一致问题
因为主从复制是异步进行的，如果从库滞后执行，则会导致主从数据不一致。
主从数据不一致一般有两个原因：
1）主从库网路延迟。
2）从库收到了主从命令，但是它正在执行阻塞性的命令（如hgetall等）。
解决方案：
1）可以换更好的硬件配置，保证网络畅通。
2）监控主从库间的复制进度。
2）读取过期数据问题
如果使用Redis版本低于3.2，读从库时，并不会判断数据是否过期，而是会返回过期数据。而3.2版本后，Redis做了改进，如果读到的数据已经过期了，从库不会删除，却会返回空值，避免了客户端读到过期数据。因此，在主从Redis模式下，尽量使用Redis 3.2以上的版本。
3）全量复制时主库压力问题
如果是一主多从模式，从库很多的时候，如果每个从库都要和主库进行全量复制的话，主库的压力是很大的。因为主库fork进程生成RDB，这个fork的过程是会阻塞主线程处理正常请求的。同时，传输大的RDB文件也会占用主库的网络宽带。可以使用主-从-从模式解决。主-从-从模式其实就是部署主从集群时，选择硬件网络配置比较好的一个从库，让它跟部分从库再建立主从关系。
4）主从网络断开问题
主从库完成了全量复制后，它们之间会维护一个网络长连接，用于主库后续收到写命令传输到从库，它可以避免频繁建立连接的开销。但是，如果网络断开重连后，是否还需要进行一次全量复制呢？如果是Redis 2.8之前，从库和主库重连后，确实会再进行一次全量复制，但是这样开销就很大。而Redis 2.8之后做了优化，重连后采用增量复制方式，即把主从库网络断连期间主库收到的写命令，同步给从库。主从库重连后，就是利用repl_backlog_buffer实现增量复制。当主从库断开连接后，主库会把断连期间收到的写操作命令，写入replication buffer，同时也会把这些操作命令写入repl_backlog_buffer这个缓冲区。repl_backlog_buffer是一个环形缓冲区，主库会记录自己写到的位置，从库则会记录自己已经读到的位置。
哨兵模式
哨兵概念说明
Redis哨兵（Redis Sentinel），用于对主从结构中的每一台服务器进行监控，当主节点出现故障后通过投票机制来挑选新的主节点，并且将所有的从节点连接到新的主节点上。主从是最基础的提升Redis服务器稳定性的一种实现方式，但我们可以看到master节点仍然是一台，若主节点宕机，所有从服务器都不会有新的数据进来，如何让主节点也实现高可用，当主节点宕机的时候自动从从节点中选举一台节点提升为主节点就是哨兵实现的功能。
哨兵也是一台Redis服务器，只是不对外提供任何服务，Redis的bin目录下的redis-sentinel其实就是redis-server的软连接。哨兵节点最少三台且必须为单数。这个与其他分布式框架如zookeeper类似，如果是双数，在选举的时候就会出现平票的情况，所以必须是三台及以上的单数。
哨兵主要作用
哨兵主要功能如下：
1）监控：监控主从节点运行情况。
2）通知：当监控节点出现故障，哨兵之间进行通讯。
3）自动故障转移：当监控到主节点宕机后，断开与宕机主节点连接的所有从节点，然后在从节点中选取一个作为主节点，将其他的从节点连接到这个最新的主节点，最后通知客户端最新的服务器地址。
哨兵其实是一个运行在特殊模式下的Redis进程。它有三个作用，分别是：监控、自动选主切换（简称选主）、通知。哨兵进程在运行期间，监视所有的Redis主节点和从节点。它通过周期性给主从库发送PING命令，检测主从库是否挂了。如果从库没有在规定时间内响应哨兵的PING命令，哨兵就会把它标记为下线状态；如果主库没有在规定时间内响应哨兵的PING命令，哨兵则会判定主库下线，然后开始切换到选主任务。所谓选主，其实就是从多个从库中，按照一定规则，选出一个当做主库。至于通知呢，就是选出主库后，哨兵把新主库的连接信息发给其他从库，让它们和新主库建立主从关系。同时，哨兵也会把新主库的连接信息通知给客户端，让它们把请求操作发到新主库上。
哨兵配置详解
在Redis源码中找到sentinel.conf配置文件，我们把它移动到Redis安装目录下然后修改配置，或者在redis.conf同目录下新建sentinel.conf文件，共有下面几个配置：
# 端口
port 26379
# 后台启动
daemonize yes
# 运行时PID文件
pidfile /var/run/redis-sentinel.pid
# 日志文件（绝对路径）
logfile "/opt/app/redis6/sentinel.log"
# 数据目录
dir /tmp/sentinel_26379
# 监控的节点名字可以自定义，后边的2代表的含义是如果有俩个哨兵判断这个主节点挂了那这个主节点就挂了，通常设置为哨兵个数一半加一
sentinel monitor mymaster 127.0.0.1 6379 2
# 哨兵连接主节点多长时间没有响应就代表主节点挂了，单位毫秒。默认30000毫秒，30秒。
sentinel down-after-milliseconds mymaster 30000
# 在故障转移时，最多有多少从节点对新的主节点进行同步。这个值越小完成故障转移的时间就越长，这个值越大就意味着越多的从节点因为同步数据而暂时阻塞不可用
sentinel parallel-syncs mymaster 1
# 在进行同步的过程中，多长时间完成算有效，单位是毫秒，默认值是180000毫秒，3分钟。
sentinel failover-timeout mymaster 180000
# 禁止使用SENTINEL SET设置notification-script和client-reconfig-script
sentinel deny-scripts-reconfig yes
哨兵配置案例
准备3个Redis服务以及3个哨兵服务（将哨兵配置文件设置到对应3个服务，按哨兵模式启动即可），其中3个Redis服务作一主两从，哨兵都监控主节点，然后测试主节点挂了之后哨兵自动选举新的master节点。实际应用中建议分别部署在不同的机器上：
# 一主二从三哨兵
Redis服务:localhost:6381、localhost:6382、localhost:6383
sentinel服务:localhost:26381、localhost:26382、localhost:26383
6381为Redis初始主节点，6382、6383分别为6381的从节点。
26381、26382、26383作为三个哨兵服务监控上面的Redis主从架构。
分别修改三个目录中的redis.conf和sentinel.conf文件，主要修改端口和文件路径：
vim redis.conf
--------------------------------------------
port 6381
daemonize yes
pidfile "/var/run/redisA_6381.pid"
logfile "/opt/app/redis6A/redis_6381.log"
dir "/opt/app/redis6A/data"
--------------------------------------------
vim sentinel.conf
--------------------------------------------
port 26381
daemonize yes
pidfile "/var/run/redis-sentinel_26381.pid"
logfile "/opt/app/redis6A/sentinel_26381.log"
dir "/tmp/sentinel_26381"
sentinel monitor mymaster 127.0.0.1 6381 2 #此参数在ABC三个服务中保持一致，都监听6381端口
然后配置6382和6383作为6381的从节点，配置和主从配置一致。启动Redis和哨兵，每个Redis都要有2个窗口，一个是服务启动，一个是哨兵。
Linux启动方式：
/opt/app/redis6A/bin/redis-server /opt/app/redis6A/bin/redis.conf
/opt/app/redis6A/bin/redis-sentinel /opt/app/redis6A/bin/sentinel.conf
Windows上可以配置启动脚本， 编写一个 bat 来启动 sentinel，在每个节点目录下建立 startup_sentinel.bat，内容如下：
# 窗口名称
title sentinel-26381
redis-server.exe sentinel.conf --sentinel
通过开关主服务，查看哨兵是否生效，也可以通过代码进行操作，当主服务断开，是否能继续写入数据：
查看是主库还是从库，cmd进入对应的redis文件夹>>> redis-cli.exe -p 服务端口，如有密码，则 auth 密码，然后再输入：info replication
查看哨兵sentinel状态，cmd进入对应的redis文件夹>>> redis-cli.exe -p 哨兵配置端口，输入：
info sentinel
哨兵判断下线
哨兵如何判定主库下线：
1）哨兵进程向主库、从库发送PING命令，如果主库或者从库没有在规定的时间内响应PING命令，哨兵就把它标记为主观下线。
2）如果是主库被标记为主观下线，则正在监视这个主库的所有哨兵要以每秒一次的频率，以确认主库是否真的进入了主观下线。当有多数的哨兵（一般少数服从多数，由Redis管理员自行设定的一个值）在指定的时间范围内确认主库的确进入了主观下线状态，则主库会被标记为客观下线。这样做的目的就是避免对主库的误判，以减少没有必要的主从切换，减少不必要的开销。
3）假设我们有N个哨兵实例，如果有N/2+1个实例判断主库主观下线，此时就可以把节点标记为客观下线，就可以做主从切换了。
哨兵领导选举
哨兵Leader选举，一般情况下当哨兵发现主节点sdown之后，该哨兵节点会成为领导者负责处理主从节点的切换工作：
1）哨兵A发现Redis主节点失联。
2）哨兵A报出sdown，并通知其他哨兵，发送指令sentinel is-master-down-by-address-port给其余哨兵节点。
3）其余哨兵接收到哨兵A的指令后尝试连接Redis主节点，发现主节点确实失联。
4）哨兵返回信息给哨兵A，当超过半数的哨兵认为主节点下线后，状态会变成odown。
5）最先发现主节点下线的哨兵A会成为哨兵领导者负责这次的主从节点的切换工作。
一个哨兵标记主库为主观下线后，它会征求其他哨兵的意见，确认主库是否的确进入了主观下线状态。它向其他实例哨兵发送is-master-down-by-addr命令。其他哨兵会根据自己和主库的连接情况，回应Y或N（Y 表示赞成，N表示反对票）。如果这个哨兵获取得足够多的赞成票数（quorum配置），主库会被标记为客观下线。标记主库客观下线的这个哨兵，紧接着向其他哨兵发送命令，再发起投票，希望它可以来执行主从切换。这个投票过程称为Leader选举。因为最终执行主从切换的哨兵称为Leader，投票过程就是确定Leader。一个哨兵想成为Leader需要满足两个条件：
1）需要拿到num(sentinels)/2+1的赞成票。
2）并且拿到的票数需要大于等于哨兵配置文件中的quorum值。举个例子，假设有3个哨兵。配置的quorum值为2。即一个一个哨兵想成为Leader至少需要拿到2张票。
案例说明：
1）在t1时刻，哨兵A1判断主库为客观下线，它想成为主从切换的Leader，于是先给自己投一张赞成票，然后分别向哨兵A2和A3发起投票命令，表示想成为Leader。
2）在t2时刻，A3判断主库为客观下线，它也想成为Leader，所以也先给自己投一张赞成票，再分别向A1和A2发起投票命令，表示也要成为Leader。
3）在t3时刻，哨兵A1收到了A3的Leader投票请求。因为A1已经把票Y投给自己了，所以它不能再给其他哨兵投赞成票了，所以A1投票N给A3。
4）在t4时刻，哨兵A2收到A3的Leader投票请求，因为哨兵A2之前没有投过票，它会给第一个向它发送投票请求的哨兵回复赞成票Y，即投票给A3。
5）在t5时刻，哨兵A2收到A1的Leader投票请求，因为哨兵A2之前已经投过赞成票给A3了，所以它只能给A1投反对票N。
6）最后t6时刻，哨兵A1只收到自己的一票Y赞成票，而哨兵A3得到两张赞成票（A2和A3投的），因此哨兵A3成为了Leader。
假设网络故障等原因，哨兵A3也没有收到两张票，那么这轮投票就不会产生Leader。哨兵集群会等待一段时间（一般是哨兵故障转移超时时间的2倍），再进行重新选举。
哨兵选举主库
如果明确主库已经客观下线了，哨兵就开始了选主模式。哨兵选主包括两大过程，分别是：过滤和打分。其实就是在多个从库中，先按照一定的筛选条件，把不符合条件的从库过滤掉。然后再按照一定的规则，给剩下的从库逐个打分，将得分最高的从库选为新主库。
1）选主时，会判断从库的状态，如果已经下线，就直接过滤。
2）如果从库网络不好，老是超时，也会被过滤掉。看这个参数down-after-milliseconds，它表示我们认定主从库断连的最大连接超时时间。
3）过滤掉了不适合做主库的从库后，就可以给剩下的从库打分，按这三个规则打分：从库优先级、从库复制进度以及从库ID号。
4）从库优先级最高的话，打分就越高，优先级可以通过slave-priority配置。如果优先级一样，就选与旧的主库复制进度最快的从库。如果优先级和从库进度都一样，从库ID号小的打分高。
哨兵故障转移
哨兵之间会有通讯，哨兵和主从节点之间也有监控，基于这些信息同步和状态监控实现Redis的故障转移：
1）哨兵和哨兵之间以及哨兵和Redis主从节点之间每隔一秒发送ping监控它们的健康状态；
2）哨兵向Redis主从节点每隔10秒发送一次info保存节点信息；
3）哨兵向Redis主节点每隔2秒发送一次hello，直到哨兵报出sdown，代表主节点失联，然后通知其余哨兵尝试连接该主节点；
4）Redis主节点下线的情况分为主观下线和客观下线：
主观下线（sdown）：单独一个哨兵发现master故障了。
客观下线（odown）：半数哨兵都认为master节点故障就会触发故障转移。
故障转移，当哨兵发现主节点下线之后经过上面的哨兵选举机制，选举出本次故障转移工作的哨兵节点完成本次主从节点切换的工作：
1）哨兵Leader根据一定规则从各个从节点中选择出一个节点升级为主节点；
2）其余从节点修改对应的主节点为新的主节点；
3）当原主节点恢复启动的时候，变为新的主节点的从节点；
4）全部服务重新启动会按配置文件设置的进行分配；
5）哨兵Leader选择新的主节点遵循下面几个规则：
健康度：从节点响应时间快
完整性：从节点消费主节点的offset偏移量尽可能的高
稳定性：若仍有多个从节点，则根据从节点的创建时间选择最有资历的节点升级为主节点
集群模式
集群概念说明
Redis集群（Redis Cluster）是从Redis 3.0开始引入的分布式存储方案。集群由多个节点（Node）组成，Redis的数据分布在这些节点中。集群中的节点分为主节点和从节点，只有主节点负责读写请求和集群信息的维护，从节点只进行主节点数据和状态信息的复制。
Redis集群的作用有下面几点：
1）数据分区：突破单机的存储限制，将数据分散到多个不同的节点存储。
2）负载均衡：每个主节点都可以处理读写请求，提高了并发能力。
3）高可用：集群有着和哨兵模式类似的故障转移能力，提升集群的稳定性。
集群配置详解
从Redis5之后我们就可以直接使用redis-cli --cluster命令自动部署Redis集群了，所以我们可以直接使用该方式搭建集群。这里演示仍然是一台机器上使用三主三从的方式部署Redis集群：
# 三主三从
主服务:localhost:7000,localhost:7001,localhost:7002
从服务:localhost:8000,localhost:8001,localhost:8002
1、首先复制Redis目录出三个：
cp -r /opt/app/redis6A /opt/app/redis6AA
cp -r /opt/app/redis6B /opt/app/redis6BB
cp -r /opt/app/redis6C /opt/app/redis6CC
2、分别修改6个目录中的redis.conf文件，主要开启集群以及修改端口和文件路径，下面以A为演示，其余略过：
vim /opt/app/redis6A/bin/redis.conf
--------------------------------------------
port 6381
daemonize yes
pidfile "/var/run/redisA_6381.pid"
logfile "/opt/app/redis6A/redis_6381.log" #需要手动touch文件
dir "/opt/app/redis6A/data" #需要手动先mkdir文件夹
cluster-enabled yes # 启用集群模式
cluster-node-timeout 15000 # 设置当前节点连接超时毫秒数
cluster-config-file node_6381.conf #设置当前节点集群配置文件路径
--------------------------------------------
3、在6个目录下分别创建log文件和目录：
mkdir /opt/app/redis6A/data
touch /opt/app/redis6A/redis_6381.log
部署集群需要先启动各个节点的服务，此时这些节点都没加到集群中，redis-cli --cluster代替了之前的redis-trib.rb，我们无需安装ruby环境即可直接使用它附带的所有功能：创建集群、增删节点、槽迁移、完整性检查、数据重平衡等等。使用redis-cli --cluster create xxx命令创建集群：
# 这里的--cluster-replicas表示每个主节点有几个副本节点
bin/redis-cli --cluster create 127.0.0.1:6381 127.0.0.1:6382 127.0.0.1:6383 127.0.0.1:6391 127.0.0.1:6392 127.0.0.1:6393 --cluster-replicas 1
集群限制说明
由于Redis集群中数据分布在不同的节点上，因此有些功能会受限：
1）db库：单机的Redis默认有16个db数据库，但在集群模式下只有一个db0。
2）复制结构：上面的复制结构有树状结构，但在集群模式下只允许单层复制结构。
3）事务或lua脚本：仅允许操作的key在同一个节点上才可以在集群下使用事务或lua脚本（使用Hash Tag可以解决）。
Hash Tag：上面介绍集群限制的时候，由于key被分布在不同的节点之上，因此无法跨节点做事务或lua脚本操作，但我们可以使用hash tag方式解决。当key包含{}的时候，不会对整个key做hash，只会对{}包含的部分做hash然后分配槽slot，因此我们可以让不同的key在同一个槽内，这样就可以解决key的批量操作和事务及lua脚本的限制了，但由于hash tag会将不同的key分配在相同的slot中，如果使用不当，会造成数据分布不均的情况，需要注意。
4）key的批量操作：如mget、mset操作，只有当操作的key都在同一个节点上才可以执行（使用Hash Tag可以解决）。
5）keys或flushall：只会在该节点之上进行操作，不会对集群的其他节点进行操作。
集群哈希算法
由于哈希算法具有随机性，可以保证数据均匀分布，因此Redis集群采用哈希分区的方式对数据进行分区，哈希分区就是对数据的特征值进行哈希，然后根据哈希值决定数据放在哪里。Redis采用的数据存储方案，在一致性哈希基础之上，引入虚拟节点的概念，虚拟节点被称为槽（slot）。Redis集群中，槽的数量为16384。槽介于数据和节点之间，将节点划分为一定数量的槽，每个槽包含哈希值一定范围内的数据。由原来的hash-->node变为hash-->slot-->node。当增删节点时，该节点所有拥有的槽会被重新分配给其他节点，可以避免在一致性哈希分区中由于某个节点的增删造成数据的严重分布不均。
Redis Cluster方案采用哈希槽（Hash Slot），来处理数据和实例之间的映射关系。一个切片集群被分为16384个slot（槽），每个进入Redis的键值对，根据key进行散列，分配到这16384插槽中的一个。使用的哈希映射也比较简单，用CRC16算法计算出一个16bit的值，再对16384取模。数据库中的每个键都属于这16384个槽的其中一个，集群中的每个节点都可以处理这16384个槽。集群中的每个节点负责一部分的哈希槽，假设当前集群有A、B、C，3个节点，每个节点上负责的哈希槽数 =16384/3，那么可能存在的一种分配：
节点A负责0~5460号哈希槽
节点B负责5461~10922号哈希槽
节点C负责10923~16383号哈希槽
集群访问数据
Moved重定向示意图：
Ask重定向示意图：
数据访问解析：
在Redis cluster模式下，节点对请求的处理过程如下：
1）通过哈希槽映射，检查当前Redis key是否存在当前节点
若哈希槽不是由自身节点负责，就返回MOVED重定向
若哈希槽确实由自身负责，且key在slot中，则返回该key对应结果
2）若Redis key不存在此哈希槽中，检查该哈希槽是否正在迁出（MIGRATING）
若Redis key正在迁出，返回ASK错误重定向客户端到迁移的目的服务器上
若哈希槽未迁出，检查哈希槽是否导入中
3）若哈希槽导入中且有ASKING标记，则直接操作，否则返回MOVED重定向
Moved重定向（固定槽之间跳转）：客户端给一个Redis实例发送数据读写操作时，如果计算出来的槽不是在该节点上，这时候它会返回MOVED重定向错误，MOVED重定向错误时，会将哈希槽所在的新实例的IP和port端口带回去。这就是Redis Cluster的MOVED重定向机制。
Ask重定向（分配槽时跳转）：一般发生于集群伸缩的时候。集群伸缩会导致槽迁移，当我们去源节点访问时，此时数据已经可能已经迁移到了目标节点，使用Ask重定向可以解决此种情况。
集群通讯协议
一个Redis集群由多个节点组成，各个节点之间是怎么通信的呢？通过Gossip协议！Gossip是一种谣言传播协议，每个节点周期性地从节点列表中选择k个节点，将本节点存储的信息传播出去，直到所有节点信息一致，即算法收敛了。
Gossip协议基本思想：一个节点想要分享一些信息给网络中的其他的一些节点。于是，它周期性的随机选择一些节点，并把信息传递给这些节点。这些收到信息的节点接下来会做同样的事情，即把这些信息传递给其他一些随机选择的节点。一般而言，信息会周期性的传递给N个目标节点，而不只是一个。这个N被称为fanout。
Redis Cluster集群通过Gossip协议进行通信，节点之前不断交换信息，交换的信息内容包括节点出现故障、新节点加入、主从节点变更信息、slot信息等等。gossip协议包含多种消息类型，包括ping，pong，meet，fail，等等。
meet消息：通知新节点加入。消息发送者通知接收者加入到当前集群，meet消息通信正常完成后，接收节点会加入到集群中并进行周期性的ping、pong消息交换。
ping消息：节点每秒会向集群中其他节点发送ping消息，消息中带有自己已知的两个节点的地址、槽、状态信息、最后一次通信时间等。
pong消息：当接收到ping、meet消息时，作为响应消息回复给发送方确认消息正常通信。消息中同样带有自己已知的两个节点信息。
fail消息：当节点判定集群内另一个节点下线时，会向集群内广播一个fail消息，其他节点接收到fail消息之后把对应节点更新为下线状态。
特别的，每个节点是通过集群总线(cluster bus)与其他的节点进行通信的。通讯时，使用特殊的端口号，即对外服务端口号加10000。例如如果某个node的端口号是6379，那么它与其它nodes通信的端口号是16379。nodes之间的通信采用特殊的二进制协议。
