复制带来的问题
- 主机（master）能读能写，从机（slave）只能读
-
- 无论主机已经写了多少数据，从机一旦启动，就会全部复制过来，后续主机写，从机跟
- 配置文件🆚命令配置
-
- 使用配置文件进行主从配置时，如果主机挂了，从机不会变化，还可以提供读的功能，等待主机恢复（重启后主从关系仍在）
- 使用命令配置时，主机A可以通过slaveof 主机B的IP 主机B的端口命令，动态的绑定成为主机B的从机，但只是单次生效，重启会失效
- 主从属性可以传递
-
- 上一个从机可以是下一个从机的主机，从机同样可以接收其他从机的连接和同步请求，那么该从机作为了链条中下一个的主机（但仍然是只读的），可以有效减轻主master（最开始的主机）的写压力
- 使用命令slaveof 新主库IP 新主库端口可以中途变更绑定的主机
-
-
- 会清除之前的数据，重新建立拷贝最新的
-
-
- 使用命令slaveof no one可以解除绑定，自己成为主机
- 复制原理和工作流程
-
- 从机启动，同步初请
-
-
- 从机启动成功连接到主机会发一个sync命令
- 从机首次全新连接主机会自动一次性全量复制，原有数据会被覆盖
-
-
- 首次连接，全量复制
-
-
- 主机节点收到sync命令后会开始在后台保存快照（即RDB持久化，主从复制时会触发RDB），同时收集所有接收到的用于修改数据集命令缓存起来，主机节点执行RDB持久化完后，master将rdb快照文件和所有缓存的命令发送到所有从机，以完成一次完全同步
- 而从机服务在接收到数据库文件数据后，将其存盘并加载到内存中，从而完成复制初始化
-
-
- 心跳持续，保持通信
-
-
- 默认10秒repl-ping-replica-period 10
-
-
-
-
进入平稳，增量复制
-
-
-
- 主机持续将新的所有收集到的修改命令自动依次传给从机，完成同步
-
-
- 从机下线，重连续传
-
-
- 主机会检查backlog中的offset，主机和从机都会保存一个复制的offset（保存在backlog中），还有一个masterId，主机只会把已经复制的offset后面的数据复制给从机（类似断点续传）
-
- 复制的缺点
-
- 复制延时，信号衰弱（从机的增加会使这个问题更严重）
- 主机挂了无法自动恢复
哨兵带来的问题
- 主机宕机，从机数据还在
- 会从剩下的两台主机中选出新的主机
- 如果宕机的主机恢复，不会出现主机冲突，恢复的主机将变为新主机的从机
故障转移
选举Leader实施故障转移
当主节点被判断客观下线后，各个哨兵节点会进行协商，先选举出一个领导者（leader），并由该leader进行接下来的故障迁移（failover），那么这个Leader是如何选择出来的呢？
我嫩还是从日志入手
由sentinel26379.log可以看到，sentinel26379的ID是047a7c7a62a803bf8fc63b7033f9b52b4279c9c2，他把票投给了ID为b60ef35fc9e900b792f3b54a6ce49cc8b8d19ecc的sentinel26381
由sentinel26380.log可以看到，sentinel26380的ID是a5b3bcfca0e27c760ef4d0b2a88022146600c16c，他把票投给了他自己
由sentinel26381.log可以看到，sentinel26381的ID是b60ef35fc9e900b792f3b54a6ce49cc8b8d19ecc，他也把票投给了他自己
此时sentinel26381有2票，sentinel26380有1票，因此，sentinel26381当选leader，并执行后续的故障转移流程选出新的主机
哨兵的Leader是怎么选的？
通过raft算法，这个算值得单独出一篇来讲(￣∇￣)/
故障转移具体步骤
-
"新主登基"
-
某个Slave被选中成为新Master
-
选出新master的规则（剩余slave节点健康前提下）
- redis.conf文件中，优先级slave-priority或者replica-priority最高的从节点（数字越小优先越高）
-
-
-
- 复制偏移位置offset最大的从节点
- 最小Run ID的从节点（字典顺序，ASCII码）
-
-
"群臣俯首"
- 朝天子一朝臣，换个码头重新拜
- 执行slaveof no one命令让选出来的从节点成为新的主节点，并通过slaveof命令让其他节点成为其从节点
- Sentinel leader会对选举出的新主机执行slaveof no one操作，将其提升为主节点
- Sentinel leaderl向其它从节点发送命令，让剩余的从机成为新的主节点的丛节点
-
"旧主拜服"
- 老主机回来也认怂
- 将之前已下线的老主机设置为新选出的新主机的从节点，当老主机重新上线后，它会成为新主节点的从节点
- Sentinel leader会让原来的主节点降级为从节点并恢复正常工作。
总结
上述的failover操作均由sentinel自己独立完成，完全无需人工干预
哨兵"食用"建议
- 哨兵节点数量应为多个（集群，保证高可用）
- 哨兵的数量应为基数（便于选举）
- 各个哨兵的配置应该一致（包括硬件等）
- 如果哨兵节点以Docker容器等方式部署，需要注意端口的映射问题
- 哨兵集群+主从复制，并不能保证数据零丢失（选举期间Redis无法写入）
由于复制带来了一些问题，于是有了哨兵，由于哨兵的一些问题，于是有了集群，其实技术就是这样一步一步查漏补缺发展而来的～～～～～～～～～