主从复制

单节点的Redis的并发能力是有上线的，要进一步提高redis的并发能力，就需要搭建主从集群，实现读写分离，下面我们来看一张图

下面我们再来聊聊主从数据的同步的流程

全量同步

全量同步：首先slave节点发起数据同步的请求，然后master先去检测这个slave是不是第一次进行数据同步，如果是则进行全量同步，master执行bgsave生成RDB快照文件，然后将快照文件发给slave，slave加载快照文件，如果master在发送快照文件的同时又有命令在执行的话就会生成一个 baklog文件，同时会将这个log文件发送给slave，这样就是进行全量同步的全部流程了，还有一个地方要特别记录一下，就是master是如何判断slave是否是第一次同步呢？ 这里还需要再介绍个东西replid，在同步之前，只需要去判断一下这个replid是否和master一致就行，如果不一致的话说明就是第一次同步，此时将进行全量同步，当然在同步之后也会将slave的replid与master同步

增量同步（slave重启或者后期数据变化）

增量同步：这个同步流程的前面步骤和全量同步是类似的，首先slave发起同步的请求，判断replid是否和master节点的replid一致，如果一致则进行增量同步，然后主节点还会去获取一下从节点的offset值，举一个例子：如果从节点的offset为30，而主节点的offset值为60，那么此时主节点就只需要将30-60之间的数据发送给从节点进行同步即可

哨兵模式

哨兵的作用和结构如下：
监控：sentinel会不断检查master和slave是否按照预期工作
自动故障恢复：如果master故障，sentinel会将一个slave提升为master。当故障实例恢复后也以新的master为主
通知：sentinel充当redis客户端的服务发现来源，当集群发送故障转移时，会将最新信息推送给redis客户端

服务状态监控

Sentinel基于心跳检测服务状态，每隔一秒向集群的每个实例发送ping命令：
如果某一个Sentinel节点发现某实例未在规定时间响应，则认为该实例是主观下线
若超过指定数量的Sentinel都认为该实例主观下线，则该实例客观下线

哨兵选主规则

首先判断主与从节点断开时间长短，如超过指定值就排除该从节点（比如某一个slave与master断开了特别长的时间，那么我们就可以排除掉这个slave）
然后判断从节点的slave-priority值，越小优先级越高
如果果slave-prority一样，则判断slave节点的offset值，越大优先级越高
最后是判断slave节点的运行id大小，越小优先级越高。

分片集群

先介绍一下分片集群的结构：

分片集群的特点：
集群中有多个master每个master保存不同的数据
每个master都可以有多个slave节点
master之间通过ping监测彼此健康状态
客户端请求可以访问集群任意节点，最终都会被转发到正确的节点

哈希槽

前面我们说到，分片集群有一个特点，客户端的请求可以访问集群任意节点，并且最终都会被转发到正确的节点，这个特点其实就是通过哈希槽来实现的，下面我们来介绍一下有关哈希槽的一些东西

Redis集群有16384个哈希槽，每个key通过CRC16校验后对16384取模来决定放置到哪个槽，集群中的每个节点负责一部分哈希槽