愿打开此篇对你有所帮助。
文章目录
- 简单概念铺垫
- 什么是主从复制
- “主从复制” ，存在即合理
- 使用简明教程
- 不说了，来吧
- 问题来啦
- 哨兵模式
- 主从数据复制原理（全量复制+部分复制）
- 心跳机制
- 心跳阶段的注意事项
- 哨兵工作原理
- 监控工作流程
- 通知工作流程
- 故障转移
- 推选新主节点
简单概念铺垫
在redis.conf中对主从复制有专门的长篇大论，不过是英文。
但是，我翻译好了：点此传送至：redis.conf翻译与配置（二）
啰嗦几句啊。如果看完redis.conf，可以直接跳过下面的，直接打开redis，开始探索之旅。
什么是主从复制
在Redis集群中，让若干个Redis服务器去复制另一个Redis服务器，我们定义被复制的服务器为主服务器（master），而对主服务器进行复制的服务器则被称为从服务器（slave），这种模式叫做主从复制模式。
数据流向是单向的，只能是从master到slave
一个slave只能有一个master“主从复制” ，存在即合理
为数据提供多个副本，实现高可用（容灾备份）
实现读写分离（主机负责写数据，从机负责读数据，主机定期把数据同步到从机保证数据的一致性）
使用简明教程
1）配主不配从
2）配置命令：SLAVE 主机IP 主机Port
每次与主机断开之后，都要重新连接，除非修改配置文件。
3）详细操作
1.拷贝多个redis.conf文件
2.开启daemonize yes
3.pid文件名字
4.指定端口
5.log文件名字
6.dump.rdp名字不说了，来吧
1）打开三个redis端口
2）配置三份conf文件
第一份6379：
用于复制出2、3
第二份6380：
第三份6381不再赘述。
3）打开三个redis服务器，并连接
另外两个客户端自行打开。（这里需要注意的是：一个客户端对应一个服务器）
4）查看各机状态，此时还都是主机
5）配从（将6380、6381挂在主机6379上）
6381记得挂
再查看主机状态：
6）验证主从复制
问题来啦
1）切入点问题：slave1、slave2是从切入时开始复制还是从头开始复制
答：全量复制，大家可以做下测试。
2）从机是否可写？
3）主机挂了呢？从机是趁机上位还是原地待命？
哦，从机还是从机，它就算有“不臣之心”，它也不知道“主子”已经先走一步了。
4）立马扶持一个从机上位
注意看，它是没有从机的，原先旧主的老部下可是不会跟着它走的。
5）旧主回归，旧臣是否依旧追随？
当然，那个自立门户的是不会主动回来了。
6）从机挂了呢？
挂了就挂了呗，什么时候想回来就回来呗。
7）手动不嫌麻烦吗？
当然麻烦，那就往下看：
哨兵模式
这里的哨兵有两个作用：
通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器。
当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。然而一个哨兵进程对Redis服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。
这些都是后话，咱先把一个搞好吧。
1）打开一个新终端
2）哨兵文件：
3）创建一个哨兵专属配置文件
4）配置该文件
如果要监视多个主机，那就多写几行。
最后那个1是票数
5）哨兵站岗
6）主机挂掉之后
7）原主机回来了
主从数据复制原理（全量复制+部分复制）
心跳机制
心跳机制
在命令传播阶段是，主节点与从节点之间一直都需要进行信息互换，使用心跳机制进行维护，实现主节点和从节点连接保持在线。
master心跳
指令：ping
默认10秒进行一次，是由参数repl-ping-slave-period决定的
主要做的事情就是判断从节点是否在线
可以使用info replication 来查看从节点租后一次连接时间的间隔，lag为0或者为1就是正常状态。
slave心跳任务
指令：replconf ack {offset}
每秒执行一次
主要做的事情是给主节点发送自己的复制偏移量，从主节点获取到最新的数据变更命令，还做一件事情就是判断主节点是否在线。心跳阶段的注意事项
主节点为保障数据稳定性，当从节点挂掉的数量或者延迟过高时。将会拒绝所有信息同步。
这里有俩个参数可以进行配置调整：
min-slaves-to-write 2
min-slaves-max-lag 8这俩个参数表示从节点的数量就剩余2个，或者从节点的延迟大于8秒时，主节点就会强制关闭maste功能，停止数据同步。
那么主节点是如何知道从节点挂掉的数量和延迟时间呢！ 在心跳机制里边slave 会每隔一秒发送perlconf ack 这个指令，这个指令可携带偏移量，也可以携带从节点的延迟时间和从节点的数量。
哨兵工作原理
哨兵作用是监控、通知、故障转移：
监控工作流程
1、哨兵发送info指令，并且保存所有哨兵状态，主节点和从节点的信息
2、主节点会记录redis实例的信息，主节点记录的信息跟哨兵记录的信息看起来是一样的，实际上还是有点区别哈。
3、哨兵会根据在主节点拿到的从节点信息，给对应的从节点也发送info指令
4、接着哨兵2来了，同样的也会改主节点发送info指令，并且建立cmd连接
5、这个时候哨兵2也会保存跟哨兵1一样的信息，只不过是保存的哨兵信息是2个。
6、这个时候为了每个哨兵的信息都一致它们之间建立了一个发布订阅。为了哨兵之间的信息长期对称它们之间也会互发ping命令。
7、当再来一个哨兵3时，也会做同样的事情，给主节点和从节点发送info。并且跟哨兵1和哨兵2建立连接。
通知工作流程
Sentinel会给主从的所有节点发送命令获取其状态，并且会把信息发布到哨兵的订阅里。
故障转移
哨兵会一直给主节点发送publish sentinel ：hello，直到哨兵报出sdown，哨兵会往内网里发布消息说明这个主节点挂了。发送的指令是sentinel is-master-down-by-address-port
其余的哨兵接收到指令后，会去看看到底挂没挂。发送的信息也是hello。其余的哨兵也会发送他们收到的信息并且发送指令sentinel is-master-down-by-address-port到自己的内网，确认一下。当所有人都认为主节点挂了后就会修改其状态为odown。当一个哨兵认为主节点挂了标记的是sdown，当半数哨兵都认为挂了其标记的状态是odown。这也就是配置哨兵为什么配置单数的原因。
对于一个哨兵认为主节点挂了称之为主观下线，半数哨兵认为主节点挂了称之为客观下线。
一旦被认为主节点客官下线后，哨兵就会进行下一步操作
推选新主节点
这时哨兵已经检测到问题所在了，那么到底是那个哨兵去负责推选新的主节点呢！
这个时候呢！五个sentinel就在一起开会了，所有的哨兵都在一个内网中，然后他们会做一件事情就是五个sentinel会同时发送指令sentinel is-master-down-by-address-port并且携带上自己竞选次数和runid。
一直发起投票直到有一个sentinel的票数为总sentinel数量的一半之多：
在上边哨兵已经选出了sentinel1为代表去所有的从节点找出一个作为主节点。这个挑选主节点不是随便拿一个是有一定的规则的。
1、先把不在线的干掉
2、响应慢的干掉，sentinel会给所有的redis发送信息，响应速度慢的就会被干掉
3、与原主节点断开时间最久的干掉
4、以上三个点都判断结束后还有多于一台从机，就会根据优先原则来进行筛选。
首先会根据优先级，如果优先级一样在进行其他判断
判断offset偏移量，判断数据同步性，假如说slave4的offset为90 slave5偏移量为100 那么哨兵就会认为slave4的网络是不是有问题啊！于是就会选slave5为新的主节点。那如果说是slave4和slave5的offset相同呢！还有最后一个判断
最后一步就是判断runid了，也就是职场中的论资排辈了，也就说根据runid的创建时间来判断，时间早的上位。
选出新的主节点后就要对所有的节点发送指令了。
天色已晚咯，各位不点个赞加关注吗？跟着博主不迷路
