主从同步

redis的主从同步，一般是一个主节点，加上多个从节点。只有主节点可以接收写命令，主节点接收到的写命令，会同步给从节点，从节点接收到主节点同步过来的写命令，会执行该命令，把数据写操作应用到内存。主节点和从节点都可以接收读命令，从节点可以分担主节点的读请求压力，这样就实现了读写分离。

以下是redis主从同步的原理：

要开启主从同步，我们要在主节点以外，多部署一个从节点。然后我们要登上从节点，执行replicaof {主节点ip} {主节点port} 的命令。

主从同步开启后，从节点会向主节点发送 psync {runid} {offset} 命令。runid是每个节点启动时都会被分配的一个唯一的id值，这里psync命令发送的runid是主节点的id，如果是重连发送的psync，runid是之前同步的主节点的id值，如果是第一次连接主节点，那么runid就是个问号“?”。offset是从节点当前复制到的偏移量，因为此时是第一次连接，从未进行过主从复制，那么发送的offset就是“-1”，于是第一次发送的psync命令就是“psync ? -1”。

当主节点接收到从节点发来的psync命令，分析发现从节点是第一次同步，会给从节点返回一个FULLREPLICA命令，表示接下来要进行全量同步。FULLREPLICA命令会带上主节点自己的runid，以及主节点目前的写入的偏移量offset。

然后主节点会执行bgsave命令，fork出一个子进程，子进程会dump出一个rdb快照，发给从节点。

从节点接收到rdb快照，会首先清空自己的数据，然后加载rdb快照。

在主节点执行完bgsave命令之后，主节点会继续接收客户端请求，期间的写命令会缓存在replication buffer缓冲区中，待从节点加载完rdb快照后，主节点会把replication buffer中的命令发送给从节点，从节点会执行这些命令，把它们应用到缓存中。

最后主节点与从节点之间会维持一个长连接，基于这个长连接进行命令传播。

如果从节点与主节点的连接断开了，从节点会尝试重连，流程如下：

在断开连接的这一段期间，主节点会继续接受请求，写命令会被写入一个名叫repl_backlog_buffer的环形缓冲区中，这个环形缓冲区在写满后，会回到开头进行覆盖写。

当从节点重新连上主节点后，从节点会发送 psync {runid} {offset} 命令。

主节点接收到从节点发来的psync命令后，会根据里面的offset判断repl_backlog_buffer中对应的写命令是否已被覆盖。如果没有被覆盖，那么会把repl_backlog_buffer中从节点的offset到主节点的offset之间的命令发送给从节点，这个就是增量同步；如果已经被覆盖了，那么就要进行全量同步了。

哨兵

当主节点挂掉之后，从节点是不会自动切换为主节点的，需要我们手动进行切换，但是这样就太麻烦了，于是就引入了哨兵集群。

哨兵集群由多个哨兵实例组成，每个哨兵实例其实就是一个redis节点，只是这个节点它不负责数据的读写，这个节点以哨兵的角色启动，负责对进行数据读写的redis节点进行监控，选主和通知这三个工作：

• 监控：监控主节点和从节点是否正常运行。
• 选主：当主节点下线之后，在从节点之中挑选一个提升为主节点。
• 通知：发生主从切换之后，通知其他从节点与新主节点进行同步，通知客户端。

我们只需要给哨兵节点配置主节点的ip地址和端口号即可，哨兵节点启动之后，就会自动组成哨兵集群。哨兵节点自动组成集群，是通过主节点完成的，它们在主节点的“__sentinel__:hello”频道执行pub和sub命令，也就是进行发布订阅，pub命令把自己的ip地址和端口号发布到主节点的“__sentinel__:hello”频道上，sub命令订阅主节点的“__sentinel__:hello”频道，当其他哨兵节点把自己的ip地址和端口号发布到主节点的该频道，当前哨兵节点就可以订阅到其他节点的ip地址和端口号。

哨兵也要对从节点进行监控，但是我们启动哨兵的时候，并没有配置从节点的ip地址和端口号，哨兵也是通过主节点得知从节点的ip地址和端口号的。哨兵节点会向主节点发送一个INFO命令，主节点接收到哨兵节点发来的INFO命令，会把从节点信息列表返回给哨兵。哨兵获取到主节点返回的从节点信息列表，就可以向从节点发起连接。

哨兵持续监控着每一个节点，当有节点下线时，哨兵会把它标记为主观下线。如果下线的是从节点，那么就仅仅是标记为主观下线。如果是发现下线的是主节点，则流程稍微复杂一点：

1. 首先标记主节点为主观下线
2. 询问哨兵集群中的其他节点，看是否也把主节点标记为主观下线
3. 如果达到quorum配置项指定个数的哨兵节点标记主节点为主观下线，则标记主节点为客观下线，并且要进行重新选主

重新选主的过程，也是比较复杂的。当一个哨兵节点把主节点标记为客观下线后，并不是马上进行重新选主，而是要在哨兵集群内进行投票，选出一个leader，它要向哨兵集群内每一个哨兵节点请求投自己一票，如果超过半数的哨兵节点都投了赞成票，该节点才成为选主的leader，由该哨兵节点来进行重新选主。如果该哨兵节点没有成功当上leader，那么就看一下哨兵集群中是否已经选出了leader，如果哨兵集群中已经选出了leader，那么它就啥也不用干了，否则就要等待一段时间，重新发起选举投票。

重新选主就是从众多从节点当中，挑选一个，把它提升为主节点。挑选的规则就是先过滤掉有问题的节点，然后对剩下的节点进行筛选打分，具体流程如下

1. 先过滤掉已下线的从节点，以及经常断连的从节点
2. 从剩下的从节点中，选出一个优先级最高的
3. 如果有两个以上的从节点，有相同的优先级，则选出一个复制进度offset离主节点写入进度最近的
4. 如果有两个以上的从节点offset相等，并且离主节点的写入进度最近，那么从它们之间选出ID最小的一个

选出主节点之后，该哨兵节点还要通知其他从节点与新的主节点进行同步，还要通知客户端与新的主节点连接。

集群

redis集群（Redis Cluster）是redis3.0版本提供的redis集群方案。redis集群采用了hash slot（哈希槽），集群中一共有16384个hash slot。当要往集群中set或get一个key时，会用CRC16算法根据key算出一个hash值，然后利用该hash值对16384取模，得知该key位于哪个hash槽，再请求该hash槽被分配到的redis节点进行读写。

我们可以使用 cluster create命令创建redis集群，并自动分配hash槽；也可以使用cluster meet命令手动建立实例间的连接，然后使用cluster addslots命令手动分配hash槽。

分配好hash槽后，redis集群中的节点之间，会互相交换信息，然后集群中的每个节点，都拥有了整个集群的hash槽分配情况。

然后当redis客户端连接上集群中的其中一个节点时，就能获取到集群中所有hash槽的分配情况，客户端会缓存集群信息在本地。

那么，当redis客户端要向集群set一个key或者get一个key时，就会按照规则进行计算：CRC16(key) % 16384，得到目标hash槽，然后查询本地缓存，看看该hash槽属于哪一个redis节点，然后再向该节点发起请求。

但是有时候由于发生了集群内hash槽的迁移，可能该hash槽已不归该redis节点管理，那么该redis节点上就没有对应的key了。此时redis节点会根据情况返回MOVED命令或ASK命令中的其中一个：

• 如果hash槽里的所有key都完成了迁移，那么返回MOVED命令，并带上该hash槽最新的所属redis节点的ip地址和端口号。
• 如果hash槽里还有部分key没有完成迁移，那么返回ASK命令，并带上该hash槽最新的所属redis节点的ip地址和端口号。

如果返回的时MOVED命令，redis客户端会直接向MOVED命令指定的redis节点发送请求，然后会更新本地缓存。

如果返回的是ASK命令，redis客户端会先向ASK命令指定的redis节点发送一个ASKING命令，表示允许该redis节点执行接下来该客户端发送的命令，然后客户端再发送真正的请求，但是不会更新本地缓存。