一、前言

说到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集群模式的利大于弊，所以在较大规模的我的项目中个别应用该模式，但在中小规模的我的项目中，抉择主从模式 或 哨兵模式亦可。