redis主从、集群和哨兵模式

最新推荐文章于 2024-05-22 23:00:24 发布

五块三毛八

最新推荐文章于 2024-05-22 23:00:24 发布

阅读量889

点赞数 9

分类专栏： redis 文章标签： redis 数据库缓存

本文链接：https://blog.csdn.net/qq_35003684/article/details/124541722

版权

redis 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

Redis集群方式共有三种：主从模式，哨兵模式，cluster(集群)模式。

一、主从同步

正在上传…重新上传取消

主从同步是比较常见的架构，主（Master）和从（Slave）分别部署在不同的服务器上，当主节点服务器写入数据时，同时也会将数据同步至从节点服务器，通常情况下，主节点负责写入数据，而从节点负责读取数据。

Redis 主机会一直将自己的数据复制给 Redis 从机，从而实现主从同步。在这个过程中，只有 master 主机可执行写命令，其他 salve 从机只能只能执行读命令，这种读写分离的模式可以大大减轻 Redis 主机的数据读取压力，从而提高了Redis 的效率，并同时提供了多个数据备份。

主从同步是实现redis集群的最简单的一种方式。

主从同步复制过程

在启动一台从服务器(slave)后，slave会发送一个psync命令个给master，如果slave是第一次连接master的话，就会触发一个全量复制。master在收到命令后会启动一个线程去生成RDB快照（BGSAVE），还会把新的请求都写到缓存中。RDB文件生成后，master将文件发送个slave，slave收到后，写入本地磁盘，然后加载到内存中，然后master会将写到缓存中的命令都发送给slave（AOF）。

二、哨兵模式

哨兵模式是基于主从模式做的一定变化，它能够为Redis提供了高可用性。哨兵模式的核心还是主从复制。只不过相对于主从模式在主节点宕机导致不可写的情况下，多了一个竞选机制——从所有的从节点竞选出新的主节点。竞选机制的实现，是依赖于在系统中启动一个sentinel进程。

哨兵模式的原理是：哨兵通过发送命令(ping命令)，等待Redis服务器响应，如果在指定时间内，主机Redis无响应，从机则判断主机宕机，选举从机上位，从而监控运行的多个Redis实例。

sentinel特点：

1.监控：它会监听主服务器和从服务器之间是否在正常工作。

2.通知：它能够通过API告诉系统管理员或者程序，集群中某个实例出了问题。

3.故障转移：它在主节点出了问题的情况下，会在所有的从节点中竞选出一个节点，并将其作为新的主节点。

4.提供主服务器地址：它还能够向使用者提供当前主节点的地址。这在故障转移后，使用者不用做任何修改就可以知道当前主节点地址。

sentinel，也可以集群，部署多个哨兵，sentinel可以通过发布与订阅来自动发现Redis集群上的其它sentinel。sentinel在发现其它sentinel进程后，会将其放入一个列表中，这个列表存储了所有已被发现的sentinel。

集群中的所有sentinel不会并发着去对同一个主节点进行故障转移。故障转移只会从第一个sentinel开始，当第一个故障转移失败后，才会尝试下一个。当选择一个从节点作为新的主节点后，故障转移即成功了(而不会等到所有的从节点配置了新的主节点后)。这过程中，如果重启了旧的主节点，那么就会出现无主节点的情况，这种情况下，只能重启集群。

对于节点是否宕机下线的判断机制：

主观下线
主观下线适用于所有主节点和从节点。如果在 down-after-milliseconds 毫秒内，Sentinel 没有收到目标节点的有效回复，则会判定该节点为主观下线。只有半数个哨兵节点都主观判定主节点down掉，此时多个哨兵节点交换主观判定结果，才会判定主节点客观下线。
客观下线
客观下线只适用于主节点。如果主节点出现故障，Sentinel 节点会通过 sentinel is-master-down-by-addr 命令，向其它 Sentinel 节点询问对该节点的状态判断。如果超过个数的节点判定主节点不可达，则该 Sentinel 节点会判断主节点为客观下线。基本上哪个哨兵节点最先判断出这个主节点客观下线，就会在各个哨兵节点中发起投票机制，每个哨兵都投自己为领导者。最终被投为领导者的哨兵节点完成主从自动化切换的过程。当判断为主观下线时，不会进行主从切换过程

选举机制

每个发现主服务器进入客观下线的sentinel都可以要求其他sentinel选自己为领头sentinel，选举是先到先得。同时每个sentinel每次选举都会自增配置纪元，每个纪元中只会选择一个领头sentinel。如果所有超过一半的sentinel选举某sentinel领头sentinel。之后该sentinel进行故障转移操作。

哨兵模式优缺点

优点

监控主数据库和从数据库是否正常运行。
主数据库出现故障时，可以自动将从数据库转换为主数据库，实现自动切换。
如果redis服务出现问题，会发送通知。

缺点

主数据库出现故障时，选举切换的时候容易出现瞬间断线现象。

三、Redis Cluster集群（去中心化）

Redis Cluster是Redis3.0后官方提供的分布式解决方案。当遇到内存、并发、流量等瓶颈时，就可以采用Cluster架构达到负载均衡目的。

        为什么要用redis-cluster集群？

        1.首先Redis单实例主要有单点，容量有限，流量压力上限的问题。 Redis单点故障，可以通过主从复制replication，和自动故障转移sentinel哨兵机制。但Redis单Master实例提供读写服务，仍然有容量和压力问题，因此需要数据分区，构建多个Master实例同时提供读写服务（不仅限于从replica节点提供读服务）。

        2.并发问题
        redis官方声称可以达到 10万/s,每秒执行10万条命令假如业务需要每秒100万的命令执行呢？

        解决方案：
        正确的应该是考虑分布式，加机器，把数据分到不同的位置，分摊集中式的压力，一堆机器做一件事.还需要一定的机制保证数据分区，并且数据在各个主Master节点间不能混乱，当然最好还能支持在线数据热迁移的特性。

正在上传…重新上传取消

其中，master1,master2,master3互相通信；每个master保存了部分信息，所有master合起来保存了所有的信息

redis cluster是去中心化，去中间件的，也就是说，集群中所有的Master节点都可以进行读写数据，不分主次，集群中的每个节点都是平等的关系，都是对等的，每个节点都保存各自的数据和整个集群的状态。每个节点都和其他所有节点连接，而且这些连接保持活跃，这样就保证了我们只需要连接集群中的任意一个节点，就可以获取到其他节点的数据。也即master节点之间是互相连接的。

故障检测

集群中每个节点会定期向就那种其他节点发送ping消息，检测是否在线，如果收到ping消息的节点没有在规定时间内返回pong消息，那么发送者会将接受者标记为疑似下线。

集群中的各个节点会通过互相发送消息的方式来交换集群各个节点的状态信息。在标记了疑似下线的节点后，会将该节点的状态通过消息发送的方式告知其余节点，其余节点会对疑似下线的节点纪行状态判断。

当集群内超过半数的主节点认为该节点疑似下线，发现者会将疑似下线的节点标记为下线，并向集群内所有节点广播这个信息，集群内的节点收到信息后会标记节点为下线状态。

故障转移

故障转移是发生在检测出故障之后，但是必须保证下线节点有从节点，否则集群将不可用，整集群会变成下线状态。

当一个从节点发现主节点已经下线后，从节点会对下线主节点进行故障转移：

下线主节点中的所有从节点会选中一个
被选中的从节点执行 SLAVEOF no one 命令，成为新的主节点
新的主节点会撤销所有对已线下主节点的槽指派，并将这些槽全部指派给自己（接手任务）
新的主节点向集群广播一条pong消息，告知集群其余节点自己成为主节点，并已经接管原本负责的任务
新的主节点开始接受处理自己的任务，故障转移完成

选举机制
新的主节点是通过选举产生的：

集群的配置纪元是一个自增的计数器，初始值为0
当集群中某个节点发生故障转移的时候，配置纪元值加一
对于每个配置纪元，集群里每个在线的主节点都有一次投票的机会，第一个向主节点要求投票的从节点将获得主节点的投票（raft协议，竞争选举）
在一个配置纪元里，当一个从节点获得超过半数以上的投票，该从节点将变成新的主节点；如果在一个配置纪元里，没有一个从节点获得足够的支持票，集群将进入一个新的配置纪元，并重新开始选举，直到选出新的主节点为止

集群进入fail状态的必要条件（集群不可用）

A、某个主节点和所有从节点全部挂掉，我们集群就进入faill状态。
B、如果集群超过半数以上master挂掉，无论是否有slave，集群进入fail状态.
C、如果集群任意master挂掉,且当前master没有slave.集群进入fail状态

节点间的通信

集群中各个节点通过发送和接收消息来进行通信，消息类型主要有5种：

MEET消息：发送者请求接收者加入发送者所在的集群
PING消息：集群内每个节点默认一面从已知节点列表中随机选取五个节点，然后对于五个钟最长时间没有发送过PING消息的节点发送PING消息，用来检测节点是否在线。除此之外，如果距离收到PONG消息的时间超过节点的 cluster-node-timeout 设置时长一半的话，也会发送PING消息，防止对其他节点的信息更新滞后。
PONG消息：收到MEET或PING后，返回对方告知已收到消息。除此之外可以通过向集群广播PONG消息来刷新其余节点关于该节点的认知（故障转移后告知自己成为主节点）。
FAIL消息：当一个主节点判断另一个主节点已经下线（FAIL）后，会想集群广播一条关于另一个主节点FAIL的消息，收到消息的节点将其标记为已下线。
PUBLISH消息：当节点接收到一个PUBLISH命令后，节点会执行命令，并广播一个PUBLISH消息，所有收到这个消息的节点都会执行相同的PUBLISH命令。