下面是主要是自己看完《Redis设计与实现》，《Redis深度历险：核心原理与应用实践》后，为了更好得掌握Redis，网上找了一些面试题，查阅书籍和资料后，写的解答。
1.Redis主从同步是怎么实现的？
2.Redis中哨兵是什么？
3.客户端是怎么接入哨兵系统的？
4.Redis哨兵系统是怎么实现自动故障转移的？
5.谈一谈你对Redis Cluster的理解？
6.RedisCluster是怎么实现数据分片的？
7.RedisCluster是怎么做故障转移和发现的？
Redis主从同步是怎么实现的？
主从节点建立连接后，从节点会进行判断：
1.如果这是从节点之前没有同步过数据
属于初次复制，会进行全量重同步，那么从节点会向主节点发送PSYNC?-1 命令，请求主节点进行全量重同步。
2.如果从节点不是初次复制（例如出现掉线后重连） 这个时候从节点会将之前进行同步的Replication ID(一个随机字符串，标识主节点上的特定数据集)和offset（从服务器当前的复制偏移量）通过PSYNC id offset命令发送给主节点，主节点会进行判断，
- 如果Replication ID跟当前的Replication ID不一致(可能主节点进行了变化)，或者是当前buffer缓冲区中不存在对应的offset，那么会跟上面的初次复制一样，进行全量重同步。
- 如果Replication ID跟当前的Replication ID一致并且当前buffer缓冲区中存在对应的offset，那么会进行部分重同步。（部分重同步是Redis 2.8之后的版本支持的，主要基于性能考虑，为了断线期间的小部分数据修改进行全量重同步效率比较低）
全量重同步
主节点会执行BGSAVE命令，fork出一个子进程，在后台生成一个RDB持久化文件，完成后，发送给从服务器，从节点接受并载入RDB文件，使得从节点的数据库状态更新至主节点执行BGSAVE命令时的状态。并且在生成RDB文件期间，主节点也会使用一个缓冲区来记录这个期间执行的所有写命令，将这些命令发送给从节点，从节点执行命令将自己数据库状态更新至与主节点完全一致。
部分重同步
因为此时从节点只是落后主节点一小段时间的数据修改，并且偏移量在复制缓冲区buffer中可以找到，所以主节点把从节点落后的这部分数据修改命令发送给从节点，完成同步。
命令传播
在执行全量重同步或者部分重同步以后，主从节点的数据库状态达到一致后，会进入到命令传播阶段。主节点执行修改命令后，会将修改命令添加到内存中的buffer缓冲区（是一个定长的环形数组，满了时就会覆盖前面的数据），然后异步地将buffer缓冲区的命令发送给从节点。
Redis中哨兵是什么？
Redis中的哨兵服务器是一个运行在哨兵模式下的Redis服务器，核心功能是监测主节点和从节点的运行情况，在主节点出现故障后，完成自动故障转移，让某个从节点升级为主节点。
客户端是怎么接入哨兵系统的？
**配置提供者：**前者只负责存储当前最新的主从节点信息，供客户端获取。
代理：客户端所有请求都会经过哨兵节点。
首先Redis中的哨兵节点是一个配置提供者，而不是代理。因为客户端只是在首次连接时从哨兵节点获取主节点信息，后续直接与主节点进行连接，发送请求，接收请求结果。
具体流程：
String masterName = "mymaster"; Set<String> sentinels = new HashSet<>(); sentinels.add("192.168.92.128:26379"); sentinels.add("192.168.92.128:26380"); JedisSentinelPool pool = new JedisSentinelPool(masterName, sentinels); //初始化过程做了很多工作 Jedis jedis = pool.getResource(); jedis.set("key1", "value1"); pool.close();
在实际开发中，通过在客户端配置哨兵节点的地址+主节点的名称(哨兵系统可能会监控多个主从节点，名称用于区分)就可以与哨兵节点建立连接，获取到主节点信息，然后与主节点建立连接，并且订阅哨兵节点的频道，以便在主节点变化后，接受到通知。 上面的代码在底层实现是客户端向依次向哨兵节点发送"sentinel get-master-addr-by-name"命令，成功获得主节点信息就不向后面的哨兵节点发送命令。同时客户端会订阅哨兵节点的+switch-master频道，一旦主节点发送故障，哨兵服务器对主节点进行自动故障转移，会将从节点升级主节点，并且更新哨兵服务器中存储的主节点信息，会向+switch-master频道发送消息，客户端得到消息后重新从哨兵节点获取主节点信息，初始化连接池。
Redis哨兵系统是怎么实现自动故障转移的？
1.认定主节点主观下线
因为每隔2s，哨兵节点会给主节点发送PING命令，如果在一定时间间隔内，都没有收到回复，那么哨兵节点就认为主节点主观下线。
2.认定主节点客观下线
哨兵节点认定主节点主观下线后，会向其他哨兵节点发送sentinel is-master-down-by-addr命令，获取其他哨兵节点对该主节点的状态，当认定主节点下线的哨兵数量达到一定数值时(这个阀值是Sentinel配置中quorum参数的值，通常我们设置为哨兵总节点数的1/2)，就认定主节点客观下线。
3.进行领导者哨兵选举
认定主节点客观下线后,各个哨兵之间相互通信，选举出一个领导者哨兵，由它来对主节点进行故障转移操作。
选举使用的是Raft算法，基本思路是所有哨兵节点A会先其他哨兵节点，发送命令，申请成为该哨兵节点B的领导者，如果B还没有同意过其他哨兵节点，那么就同意A成为领导者，最终得票超过半数以上的哨兵节点会赢得选举，如果本次投票，没有选举出领导者哨兵，那么就开始新一轮的选举，直到选举出哨兵节点（实际开发中，最先判定主节点客观下线的哨兵节点，一般就能成为领导者。）
4.领导者哨兵进行故障转移
领导者哨兵节点首先会从从节点中选出一个节点作为新的主节点。选择的规则是：
- 1.首先排除一些不健康的节点。（下线的，断线的，最近5s没有回复哨兵节点的INFO命令的，与旧的主服务器断开连接时间较长的）
- 2.然后根据优先级，复制偏移量，runid最小，来选出一个从节点作为主节点。
向这个从节点发送slaveof no one命令，让其成为主节点，通过slaveof 命令让其他从节点成为它的从节点，将已下线的主节点更新为新的主节点的从节点，将其他从节点的复制目标改完新的主节点，将旧的主服务器改为从服务器。
谈一谈你对RedisCluster的理解？
当需要存储的数据量特别大，单个Redis实例无法满足需求，所以需要分片，早期很多业务就是在业务中进行分片，通过自定义一些业务规则，将不同的数据存储在不同的Redis实例中。后来就有了官方推出的集群化方案Redis Cluster。
RedisCluster是怎么实现数据分片的？
首先Redis Cluster设定了有16384个槽位，然后根据启动时集群的主节点数量进行均分，每个主节点得到一定数量的槽位，为了保证每个主节点挂掉之后，服务保持高可用，一般会为每个主节点配置几个从节点，从节点保存了主节点上同步过来的数据，一旦主节点挂掉，会有一个从节点会被选为主节点。客户端在与Redis Cluster建立连接时会获取到各槽位与主节点之间的映射关系，然后缓存到本地。
客户端执行命令的流程：
假设客户端需要发送一个查询请求时，首先会对key使用CRC16算法计算得到一个hash值，然后将hash值与16384(也就是2的14次方)进行取模(下面是网上找的图，应该是CRC16(key)%16384)，得到一个槽位slot，然后根据本地缓存的槽位映射关系表，找到这个槽位slot对应的主节点，发送查询命令。主节点在收到命令后会有以下几种情况：
1.这个主节点确实负责这个槽位，且不在迁移中。
直接查询到这个键值对，返回给客户端。
2.这个主节点不负责这个槽位，或者已经确定转移到其他节点上去了(Moved指令)
可能是这个槽位已经迁移了，或者是客户端将指令发送到了错误的节点，或者是客户端缓存的槽位映射关系以前过期。主节点就会给客户端返回Moved指令及正确的节点信息，Moved指令相当于是一个永久重定向指令，用于纠正客户端缓存的错误槽位信息。客户端收到后会更新本地的槽位关系表，然后向正确的节点发送查询指令。
3.这个槽位正在迁移中(ASKING指令)
如果这个槽位之前是在这个主节点上，但是目前正在迁移(槽位状态为IMPORTING)，那么如果现在主节点上存在这个可以，就成功处理请求。否则就返回ASKING指令+槽位所在的新节点，ASKING指令相当于是一个临时重定向指令，客户端收到之后不会更新本地的槽位关系表，只是将本次请求发送到新节点。
Redis Cluster的节点扩容和下线
扩容
例如数据量太大了，原有的节点太少了，希望增加一些Redis实例，分担一些数据量。在Redis Cluster中，需要程序员手动执行命令，将节点添加到集群，并执行命令从其他的主节点上分配一些槽位到这个新节点上。
具体执行命令流程如下：
./redis-trib.rb add-node 127.0.0.1:7006 127.0.0.1:7000
可以看到.使用addnode命令来添加节点，第一个参数是新节点的地址，第二个参数是任意一个已经存在的节点的IP和端口。
新节点现在已经连接上了集群， 成为集群的一份子， 并且可以对客户端的命令请求进行转向了， 但是和其他主节点相比， 新节点还有两点区别：
- 新节点没有包含任何数据， 因为它没有包含任何哈希槽位.
- 尽管新节点没有包含任何哈希槽位， 但它仍然是一个主节点， 所以在集群需要将某个从节点升级为新的主节点时， 这个新节点不会被选中。
接下来， 只要使用 redis-trib 程序， 将集群中的某些哈希槽位移动到新节点里面， 新节点就会成为真正的主节点了。
槽位迁移需要执行的命令会比较的多，大家想了解的可以看看这篇文章：
https://www.cnblogs.com/youngchaolin/archive/2004/01/13/12034660.html
下线
在节点上执行 redis-trib.rb del-node{host:port} {donwNodeId} 通知其他的节点，自己下线，如果本节点是主节点，会安排对应的从节点阶梯主节点的位置。
RedisCluster是怎么做故障转移和发现的？
1.主观下线
当节点 1 向节点 2 例行发送 Ping 消息的时候，如果节点 2 正常工作就会返回 Pong 消息，同时会记录节点 1的相关信息，更新与节点2的最近通讯时间。如果节点 1的定时任务检测到与节点 2 上次通讯的时间超过了 cluster-node-timeout 的时候，就会更新本地节点状态，把节点 2 更新为主观下线。
2.客观下线：
由于 Redis Cluster 的节点不断地与集群内的节点进行通讯，下线信息也会通过 Gossip 消息传遍所有节点。
因此集群内的节点会不断收到下线报告，当半数以上持有槽的主节点标记了某个节点是主观下线时，便会认为节点2客观下线，执行后面的流程。
3.资格检查
每个从节点都会检查与主节点断开的时间。如果这个时间超过了 cluster-node-timeout*cluster-slave-validity-factor（从节点有效因子，默认为 10），那么就没有故障转移的资格。也就是说这个从节点和主节点断开的太久了，很久没有同步主节点的数据了，不适合成为新的主节点，因为成为新的主节点以后，其他的从节点回同步它的数据。
4.从节点触发选举
通过资格的从节点都可以触发选举。但是触发选举是有先后顺序的，这里按照复制偏移量的大小来判断。
这个偏移量记录了执行命令的字节数。主服务器每次向从服务器传播 N 个字节时就会将自己的复制偏移量+N，从服务在接收到主服务器传送来的 N 个字节的命令时，就将自己的复制偏移量+N。
复制偏移量越大说明从节点延迟越低，也就是该从节点和主节点沟通更加频繁，该从节点上面的数据也会更新一些，因此复制偏移量大的从节点会率先发起选举。
5.从节点发起选举
首先每个主节点会去更新配置纪元（clusterNode.configEpoch），这个值是不断增加的整数。
在节点进行 Ping/Pong 消息交互时也会更新这个值，它们都会将最大的值更新到自己的配置纪元中。
这个值记录了每个节点的版本和整个集群的版本。每当发生重要事情的时候，例如：出现新节点，从节点精选。都会增加全局的配置纪元并且赋给相关的主节点，用来记录这个事件。
说白了更新这个值目的是，保证所有主节点对这件“大事”保持一致。大家都统一成一个配置纪元（一个整数），表示大家都知道这个“大事”了。
更新完配置纪元以后，每个从节点会向集群内发起广播选举的消息。
6.主节点为选举投票
参与投票的只有主节点，从节点没有投票权。每个主节点在收到从节点请求投票的信息后，如果它还没有为其他从节点投票，那么就会把票投给从节点。(也就是主节点的票只会投给第一个请求它选票的从节点。)
超过半数的主节点通过某一个节点成为新的主节点时投票完成。
如果在 cluster-node-timeout*2 的时间内从节点没有获得足够数量的票数，本次选举作废，进行第二轮选举。
这里每个候选的从节点会收到其他主节点投的票。在第2步领先的从节点通常此时会获得更多的票，因为它触发选举的时间更早一些。
获得票的机会更大，也是由于它和原主节点延迟少，理论上数据会更加新一点。
7.选举完成
当满足投票条件的从节点被选出来以后，会触发替换主节点的操作。新的主节点别选出以后，删除原主节点负责的槽数据，把这些槽数据添加到自己节点上。
并且广播让其他的节点都知道这件事情，新的主节点诞生了。
Redis Cluster的主从复制模型
Redis集群的架构就是多个主节点，每个主节点负责一部分槽位，每个主节点拥有几个从节点，一旦主节点挂掉，会挑选一个从节点成为新的主节点，负责这部分槽位。如果某个主节点和它的所有从节点都挂掉了，那么这部分槽位就不可用。
Redis Cluster一致性
CAP理论认为C一致性，A可用性，P分区容错性，一般最多只能满足两个，也就是只能满足CA和CP，而Redis Cluster的主从复制的模式是异步复制的模式，也就是主节点执行修改命令后，返回结果给客户端后，有一个异步线程会一直从aof_buf缓冲区里面取命令发送给从节点，所以不是一种强一致性，只满足CAP理论中的CA。
参考链接：
http://www.redis.cn/topics/cluster-tutorial.html
https://blog.csdn.net/g6u8w7p06dco99fq3/article/details/105336857
