redis哨兵模式

redis主从复制

redis哨兵模式就是解决主从复制带来的问题，所以先介绍redis主从复制。

主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点（master/leader)，后者称为从节点(slave/follower)；数据的复制是单向的，只能由主节点到从节点。Master以写为主，Slave 以读为主。

默认情况下，每台Redis服务器都是主节点；且一个主节点可以有多个从节点（或没有从节点），但一个从节点只能有一个主节点。

主从复制的作用主要包括：

1. 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
2. 故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。
3. 负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。
4. 高可用基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。

一般来说，要将Redis运用于工程项目中，只使用一台Redis是万万不能的，原因如下：

1. 从结构上，单个Redis服务器会发生单点故障，并且一台服务器需要处理所有的请求负载，压力较大；
2. 从容量上，单个Redis服务器内存容量有限，就算一台Redis服务器内存容量为256G，也不能将所有内存用作Redis存储内存，一般来说，单台Redis最大使用内存不应该超过20G

注意

1. 主机可以写（当然也可以读），从机不能写（写的话会报错）只能读！主机中的所有信息和数据，都会自动被从机保存。

2. 主机宕机，从机依然是连接到主机的，但是没有写操作。如果主机恢复，从机依旧可以连接到主机。

3. 从机宕机，在此期间主机依然在写入数据，等从机恢复，还能获取到主机这段时间的数据。

复制原理

1. Slave 启动成功连接到 master 后会发送一个sync命令
2. Master接到命令，启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将传送整个数据文件到slave，并完成一次完全同步。
   • 全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。
   • 增量复制：Master继续将新的所有收集到的修改命令依次传给slave，完成同步
     但是只要是重新连接master，一次完全同步（全量复制）将被自动执行

宕机后手动配置主机
如果主机断开连接，我们可以使用slaveof no one让自己变成主机！其他的节点就可以手动连接到最新的这个主节点。
如果主机恢复，那就重新手动指定！

主从复制和哨兵模式的配置可以看这里

哨兵模式

为什么使用哨兵模式？

主从切换技术的方法是：当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用。

这不是一种推荐的方式，更多时候，我们优先考虑哨兵模式。Redis从2.8开始正式提供了Sentinel（哨兵）架构来解决这个问题。

能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库。

什么是哨兵模式？

哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。

Redis 哨兵模式是指在 Redis 集群中，有一组专门的进程（即哨兵进程）负责监控主节点和从节点的状态，并在发现故障时自动进行故障转移，以保证 Redis 集群的高可用性。

Redis哨兵模式是是一个管理多个 Redis 实例的工具，它可以实现对 Redis 的监控、通知、自动故障转移，是Redis实现高可用 的实现方案。

Redis 提供了哨兵的命令，哨兵命令是一个独立的进程，哨兵进程会周期性地向主节点和从节点发送 PING 命令来检测它们的状态，当哨兵进程发现 master主节点 不可用时，根据投票数自动将某一个 slave 转换 master，然后通过消息订阅模式通知其它 slave，让它们切换到新的 master主节点 上，从而实现故障转移。然而，一个哨兵进程对 Redis 服务器进行监控，可能会出现问题，为此，我们可以使用多哨兵进行监控。哨兵进程还可以监控 Redis 集群的配置变化，并在配置变化时通知客户端进行相应的调整。

这里的哨兵有两个作用

• 通过发送命令，让Redis服务器返回监控其运行状态，监控主机Redis和从机Redis是否运行正常
• 主机Redis出现故障后自动将从机转化为主机，当哨兵监测到master宕机，会自动将slave切换成master。然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。

然而一个哨兵进程对Redis服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。

假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行failover过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象成为主观下线。

当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover［故障转移］操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线

哨兵工作流程（了解）

在配置文件中通过 sentinel monitor 来定位master的IP、端口，一个哨兵可以监控多个master数据库，只需要提供多个该配置项即可。哨兵启动后，会与要监控的master建立两条连接：

• 一条连接用来订阅master的_sentinel_:hello频道与获取其他监控该master的哨兵节点信息
• 另一条连接定期向master发送INFO等命令获取master本身的信息

哨兵认为master客观下线后，故障恢复的操作需要由选举的领头哨兵来执行，选举采用Raft算法：

1. 发现master下线的哨兵节点（我们称他为A）向每个哨兵发送命令，要求对方选自己为领头哨兵
2. 如果目标哨兵节点没有选过其他人，则会同意选举A为领头哨兵
3. 如果有超过一半的哨兵同意选举A为领头，则A当选
4. 如果有多个哨兵节点同时参选领头，此时有可能存在一轮投票无竞选者胜出，此时每个参选的节点等待一个随机时间后再次发起参选请求，进行下一轮投票竞选，直至选举出领头哨兵

关于主节点故障选举流程（了解）

哨兵节点选出领头哨兵后，领头者开始对系统进行故障恢复，从出现故障的master的从数据库中挑选一个来当选新的master

规则如下

• 所有在线的slave中选择优先级最高的，优先级可以通过slave-priority配置
• 如果有多个最高优先级的slave，则选取复制偏移量最大（即复制越完整）的当选
• 如果以上条件都一样，选取id最小的slave

挑选出需要继任的slave后，领头哨兵向该数据库发送命令使其升格为master，然后再向其他slave发送命令接受新的master，最后更新数据。将已经停止的旧的master更新为新的master的从数据库，使其恢复服务后以slave的身份继续运行。

我们引导员工懂得高雅的文化与生活，积极、开放、正派地面对人生。人生苦短，不必自己折磨自己。不以物喜，不以己悲。同时也要牢记，唯有奋斗才会有益于社会。人生是美好的，美好并非洁白无暇。任何时候，任何处境都不要对生活失去信心。有机会去北京，可以去景山公园看看，从西门进去，那儿是一片歌的海洋，热得象海啸一样奔放，这些都是垂暮之年的老人，几十人一族，几百人一团，都在放声歌唱，多么的乐观，多么的豁达。看看他们的夕阳红，你为什么不等到那一天？快乐的人生，无论处境多么困难，只要你想快乐一定会快乐。

任正非：要快乐地度过充满困难的一生

部分内容转载自：
https://blog.csdn.net/sinat_25207295/article/details/117925174
https://www.bilibili.com/video/BV1S54y1R7SB?p=27&spm_id_from=pageDriver&vd_source=64c73c596c59837e620fed47fa27ada7
https://juejin.cn/post/7137104039753285645
https://zhuanlan.zhihu.com/p/648737280
https://blog.csdn.net/CSDN_LJK/article/details/135607790
https://blog.csdn.net/shiranyyds/article/details/139543007
https://www.cnblogs.com/jiaodaoniujava/p/17699943.html