1.为什么要主从复制
- 实现高可用，避免单机节点故障数据丢失
- 实现读写分离
- 提升QPS
2.主从复制的特点
- 一个master可以有多个slave
- 一个slave只能有一个master
- 数据流是单向的，从master到slave
3.主从复制的实现
Redis的主从复制实现非常简单，有如下两种方式：
- 使用slaveof或replicaof命令
假设我们已经在单机上启动了6379、6380两个端口的redis服务，那么可以在从节点6380中执行命令,就可以实现主从复制
slaveof 127.0.0.1 6379
replicaof 127.0.0.1 6379
此时在6379中写入数据，就可以在6380中读取到（注意从节点是不能写入数据的）
- 配置
在6380的配置文件中做出如下修改：
replicaof 127.0.0.1 6379 # 旧版是salveof
replica-read-only yes
然后重新启动redis服务就可以了
如何取消主从复制,只需要在从节点中执行命令 slaveof no one或replicaof no one
4.主从复制的问题
- 读写分离
- 如何将读流量分摊到从节点
- 复制数据延迟
- 读到过期的数据
- 从节点故障，无法进行故障转移
- 配置不一致
- 例如maxmemory不一致，造成丢失数据
- 例如数据结构优化参数（hash-max-ziplist-entries），内存不一致
- 规避全量复制
- 第一次启动不可避免的会进行全量复制
- 节点的运行id不匹配（如主节点发生了重启）
- 复制积压缓冲区不足（网络中断，部分复制无法满足）
- 规避复制风暴
- 主节点重启了，多个从节点复制
5.哨兵机制
对于上面的问题，我们可以引入Redis的哨兵机制进行解决
解决问题
带有自动故障转移的主从式架构，基于主从架构；无法解决主节点并发压力问题
搭建哨兵机制
- 在之前主从复制架构基础上，新增一个哨兵服务
- 添加一个配置文件
vim /root/sentinel.conf
写入以下代码
sentinel monitor mymaster 192.168.2.200 6379 3
- 启动哨兵服务
redis-sentinel /root/sentinel.conf
配置完成后如果主节点宕机，哨兵服务会在从节点中选出一个作为主节点。之前的主节点如果恢复，则只能作为当前主节点的从节点
故障转移
1.从slave节点选出一个合适的节点作为新的master节点
2.对上面的slave节点执行slaveof no one命令让其成为master节点
3.向剩余的slave节点发送命令，让他们成为新的master节点的slave节点，复制规则和parallel-syncs参数有关
4.更新对原来master节点配置为slave，并保持对其关注，当其恢复后命令它去复制新的master节点
什么是合适的slave节点
1.选择slave-priority（slave节点优先级）最高的slave节点，如果存在则返回，不存在则继续
2.选择复制偏移量最大的slave节点（复制的最完整），如果存在则返回，不存在则继续
3.选择runId最小的slave节点