1. redis 主从复制
1.1 原理
主从结构是指一个master 有多个从节点（一般是一主两从），或者级联结构，来实现读写分离的功能。
（主节点提供读写功能，从节点只读）
1.2 全量复制
- slave 向master 发起同步命令。
- master 收到命令向slave 发送 runid 和 offset ，offset就是偏移量。
- slave 保存master的信息。
- master 自身调用 bgsave，并将写进来的数据写到缓存中。
- master 向slave 发送 rdb文件和缓存数据。
- slave 调用 flushall。
- slave 加载数据。
1.3 增量复制
在slave 初始化后，master 会将用户执行的指令给slave 发送，让从节点执行，来进行增量同步。
1.4 主从复制存在的问题
当 master 无法提供服务的时候，需要人工的干预，将从节点提升为主节点，或者恢复主节点。
1.5 设置缓存区大小的配置
repl-backlog-size 1mb
2. 哨兵模式
2.1 原理
哨兵模式其实就是主从复制的升级版，在主从复制的基础上，引入了主节点自动故障转移的功能。
哨兵会不停的监控主节点和从节点是否正常的运作，如果主节点发生故障， 可以自动通过投票机制，从slave节点中选举新的master，实现将从数据库转换为主数据库的自动切换。
2.2 主观下线概念
其中一个哨兵给节点发送ping命令规定时间内没有收到回应，就认为节点宕机，是主观下线。
2.3 客观下线概念
哨兵群中，超过半数的哨兵认为节点宕机，就是客观下线。
2.4 主要配置
sentinel monitor mymaster 127.0.0.1 26379 2 mymaster表示监视的节点名称，后面是节点地址，2是表示需要有两个哨兵节点的同意，才能进行故障转移。
2.5 哨兵监控步骤（或者说哨兵的定时任务）
- 每10秒向master 发送 info 命令获取下面的所有的从节点的信息。
- 每2秒通过发布订阅的功能获取其他哨兵的信息。
- 每1秒向其他的节点发送ping命令，来判断是否下线。
2.6 slave的选举策略
-
根据配置的 slave-priority 100 优先级决定。
-
如果多个节点的优先级一致，查看offset偏移量，选择偏移量大的。
-
如果多个节点同时满足1和2，选择runid小的。
2.7 故障转移流程
-
选举出来的节点执行 slaveof no one 命令
-
其他的节点也是执行 slaveof 命令来作为选举出来新master的从节点。
-
故障的主节点恢复后也被设置为从节点。
2.8 存在的问题
存储的能力受单机的限制，无法负载大量的数据。
3. Redis Cluster集群
redis Cluster 是在 3.0之后才出现的，至少需要3主3从才能够搭建，自动将数据进行分片，每个主节点上放一部分数据，内置的高可用支持，部分主节点宕机，也能继续提供服务。
3.1 槽
redis Cluster，有一个16384个slot（槽），这个槽是虚拟的，并不是真实存在的，集群中的每一个master负责一部分槽（一般是均匀分配的），存进来的数据会根据一定的规则分配到不同的槽中。
3.2 数据分片
set 某个 key 时，集群使用 CRC16 算法算出key 的hash值，并用hash值%16384来计算出 key 是在哪一个槽中，然后在将数据存储。
3.3 数据迁移
当其中的节点宕机后，需要对宕机节点的数据进行迁移，宕机节点的槽会分配给其他的节点，同时会将槽的数据迁移过去，新增节点的话，会将其他节点的槽抽出来分给新节点。
3.4 节点变更
cluster采用的是被动的方案，当目标节点宕机，客户端访问了挂一个异常，这时客户端会在集群中随机找一个节点来重试，重试的节点会通知客户端数据已经被分配到其他的节点，同时客户端会关闭所有连接，清空本地保存的slot映射信息，然后重新初始化节点信息。
