【Redis】四种部署模式的介绍及其优缺点

一、前言

说到Redis的部署模式,很多同学第一时间想到的就是Redis Cluster集群模式,因为它可能是现在的主流模式。但其实这几种模式各有优劣,实际环境中我们应该选择合适的部署模式,否则适得其反,接下来简单介绍一下这几种部署模式

二、部署模式

2.1 单机模式

单机模式就是只有单个redis提供服务,如下图

  • 优点:

    1. 架构简单,易于维护
  • 缺点:

    1. 单台服务器内存空间有限,无法存放太多的数据量
    2. 存在单点故障
    3. 读写压力较大

单机模式适用于内部测试、项目规模小的场景

2.2 主从模式

由于单个redis节点的读写压力较大,所以引出了主从复制方式,可实现读写分离,读操作可以由slave节点来支持,降低master节点的压力。如下图

主从复制是redis实现高可用的基石,后续的两种高可用方案 哨兵模式 或者 cluster集群模式 都需要有主从复制的支撑。
  • 优点:

    1. 读写分离。通过读写分离来降低master节点的压力
    2. 拥有多个数据副本
  • 缺点:

    1. 单个master内存空间有限,无法存放太多的数据量
    2. 依然只有master节点可以处理写请求,存在瓶颈
    3. 当master节点发生故障下线时,需要人工地将某个slave节点切换为新的master节点,并且客户端需要切换到连接新的master节点

主从模式适用于内部性能测试、项目规模小的场景

2.3 哨兵模式

哨兵模式是在主从复制的基础上,添加哨兵(实际上就是个redis的应用进程)来监控master节点和slave节点,当master节点发生故障下线时,哨兵自动地将某个slave节点切换为master节点,且客户端不需要去切换连接新的master节点。(一般需要部署哨兵集群,防止哨兵的单点故障)

  • 优点:

    1. 读写分离。通过读写分离来降低master节点的压力
    2. 拥有多个数据副本
    3. 自动故障转移。当master节点发生故障下线时,哨兵自动地将某个slave节点切换为新的master节点,并且客户端不需要切换连接新的master节点(由于客户端连接哨兵集群,而不直接连接master节点)
  • 缺点:

    1. 单个master内存空间有限,无法存放太多的数据量
    2. 依然只有master节点可以处理写请求,存在瓶颈

哨兵模式适用于生产环境、项目规模中等的场景

2.3.1 故障转移 failover

当master节点下线之后,哨兵自动将slave节点切换为新的master节点,这一过程称为故障转移(failover)。故障转移的大致步骤如下:

  1. 检测master是否主观下线
    sentinel每隔1秒钟,向所有的master、slave、sentinel发送ping命令,通过其他服务器的回复来判断是否在线(当ping的实例在连续down-after-milliseconds配置的时间内返回无效命令或无响应,则当前sentinel认为其主观下线,对所有master、slave、sentinel都适用)
  2. 检测master是否客观下线
    当前sentinel要想判断master是否客观下线,需要询问其他sentinel,并且认为master主观下线的总数需要达到quorum配置的值,则当前sentinel将该master标记为客观下线
  3. 选举哨兵leader
    当前sentinel将该master标记为客观下线后,会给其他sentinel再发送命令,其他sentinel收到请求后将其设置为leader(这个设置是先到先得的,sentinel先收到谁的设置请求,就将谁设置为leader)。发送命令的sentinel会根据其他sentinel回复的结果来判断自己是否被该sentinel设置为leader,如果当前sentinel被其他sentinel设置为leader的数量超过半数sentinel,那么当前sentinel会认为自己已经成为leader,并开始后续故障转移工作。如果没有任何一个sentinel达到成为leader的要求,将会重新选举直到产生leader为止
  4. 故障转移由哨兵leader全权负责
    从slave列表中选择最佳的slave作为新的master。让其他slave复制新的master,并且继续监听旧master,如果其上线,将其设置为新的master的slave

2.4 集群模式

既然哨兵模式已经具备了高可用性,为什么还需要cluster模式?因为哨兵模式还是没有解决只有master节点可以处理写的问题,依然存在写瓶颈。而cluster集群模式使用"分片"(每个master处理一部分slot)的形式来处理所有key,可以有多个master来处理写操作,从而来解决写瓶颈问题。如下图

  • 优点:

    1. 自动故障转移。当某个master节点发生故障下线时,集群自动地将其对应的某个slave节点替代它
    2. 当现有redis集群不足以支撑整个系统的压力时,可以横向拓展集群
  • 缺点:

    1. 无法执行批量操作,如mget
    2. 当redis节点很多的时候,由于每个节点都需要跟其他节点通信,整个集群的性能会降低
    3. 维护成本较高

redis cluster模式适用于生产环境、项目规模大型的场景

2.4.1 故障转移 failover

与哨兵模式一样,从节点的故障并不会影响集群工作,对应的主节点只会记住自己的哪个从节点下线了,当从节点重连后,会继续复制主节点的数据。

只有主节点故障才需要故障转移。cluster集群模式不需要哨兵,自身已具备了故障转移功能。由于集群内的每个节点都会互相进行通信,节点之间通过gossip协议进行通信,通过这种机制来发现故障并进行故障转移。但是要达到故障转移,需要解决几个问题?

  • 故障发现:如何判断某个master节点故障了?redis采用多数投票的方案
  • 选取slave节点:master有多个slave节点的时候,应该选择哪个slave节点成为新的master

故障发现
和哨兵模式类似,故障发现也经历两个阶段:PFAIL(主观下线)和FAIL(客观下线)
假设现在有3个master节点,分别为节点1,节点2,节点3。比如节点1判断节点3下线,那么它会标记节点3的状态为PFAIL,节点1会通过gossip协议把这个信息发送给其他节点,接收到信息的节点会进行对节点3客观下线的状态判定。当集群中有超过半数的节点认为节点3处于PFAIL,那么节点1就判定节点3为FAIL,并立即向集群所有节点(包括节点3的子节点)广播这个信息。

故障转移
当节点3的slave发现自己的master变为fail状态时,便尝试进行故障转移failover,以成为新的master。由于一个master可能有多个slave,所以这些slave需要竞争成为master节点,过程如下:

  1. slave1、slave2都发现自己的master状态变为fail
  2. 它们将自己记录的集群currentEpoch(选举周期)加1,并使用gossip协议广播failover_auth_request信息
  3. 其他master节点收到slave1和slave2的消息,会给slave1或slave2发送failover_auth_ack,在一个选举周期中,一个master只会响应第一个给它发消息的slave
  4. slave们收集返回的failover_auth_ack,当收到超过半数的master的ack消息后变成新的master
  5. 最后向整个集群广播现在自己是master,同时负责旧master所有slots的信息
  6. 其他节点接收到信息后,更新自己的维护状态

三、总结

redis的部署模式介绍到这里,总体看下来redis cluster集群模式的利大于弊,所以在较大规模的项目中一般使用该模式,但在中小规模的项目中,选择主从模式 或 哨兵模式亦可。

作者:kamier原文地址:https://segmentfault.com/a/1190000043544891

%s 个评论

要回复文章请先登录注册