关于redis:Redis四种部署模式的介绍及其优缺点

1次阅读

共计 3110 个字符，预计需要花费 8 分钟才能阅读完成。

说到 Redis 的部署模式，很多同学第一工夫想到的就是 Redis Cluster 集群模式，因为它可能是当初的支流模式。但其实这几种模式各有优劣，理论环境中咱们应该抉择适合的部署模式，否则事与愿违，接下来简略介绍一下这几种部署模式

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

长处：
1. 架构简略，易于保护
毛病：
1. 单台服务器内存空间无限，无奈寄存太多的数据量
2. 存在单点故障
3. 读写压力较大

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

因为单个 redis 节点的读写压力较大，所以引出了 主从复制 形式，可实现 读写拆散，读操作能够由 slave 节点来反对，升高 master 节点的压力。如下图

主从复制是 redis 实现高可用的基石，后续的两种高可用计划哨兵模式或者 cluster 集群模式都须要有主从复制的撑持。

长处：
1. 读写拆散。通过读写拆散来升高 master 节点的压力
2. 领有多个数据正本
毛病：
1. 单个 master 内存空间无限，无奈寄存太多的数据量
2. 仍然只有 master 节点能够解决写申请，存在瓶颈
3. 当 master 节点产生故障下线时，须要人工地将某个 slave 节点切换为新的 master 节点，并且客户端须要切换到连贯新的 master 节点

主从模式实用于 外部性能测试、我的项目规模小 的场景

哨兵模式是在主从复制的根底上，增加哨兵（实际上就是个 redis 的利用过程）来监控 master 节点和 slave 节点，当 master 节点产生故障下线时，哨兵主动地将某个 slave 节点切换为 master 节点，且客户端不须要去切换连贯新的 master 节点。（个别须要部署哨兵集群，避免哨兵的单点故障）

长处：
1. 读写拆散。通过读写拆散来升高 master 节点的压力
2. 领有多个数据正本
3. 主动故障转移。当 master 节点产生故障下线时，哨兵主动地将某个 slave 节点切换为新的 master 节点，并且客户端不须要切换连贯新的 master 节点（因为客户端连贯哨兵集群，而不间接连贯 master 节点）
毛病：
1. 单个 master 内存空间无限，无奈寄存太多的数据量
2. 仍然只有 master 节点能够解决写申请，存在瓶颈

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

当 master 节点下线之后，哨兵主动将 slave 节点切换为新的 master 节点，这一过程称为 故障转移（failover）。故障转移的大抵步骤如下：

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

既然哨兵模式曾经具备了高可用性，为什么还须要 cluster 模式？因为哨兵模式还是没有解决只有 master 节点能够解决写的问题，仍然存在写瓶颈。而 cluster 集群模式应用 ” 分片 ”（每个 master 解决一部分 slot）的模式来解决所有 key，能够有多个 master 来解决写操作，从而来解决写瓶颈问题。如下图

长处：
1. 主动故障转移。当某个 master 节点产生故障下线时，集群主动地将其对应的某个 slave 节点代替它
2. 当现有 redis 集群不足以撑持整个零碎的压力时，能够横向拓展集群
毛病：
1. 无奈执行批量操作，如 mget
2. 当 redis 节点很多的时候，因为每个节点都须要跟其余节点通信，整个集群的性能会升高
3. 保护老本较高

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

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

只有主节点故障才须要故障转移。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 节点，过程如下：

slave1、slave2 都发现自己的 master 状态变为 fail
它们将本人记录的集群 currentEpoch（选举周期）加 1，并应用 gossip 协定播送 failover_auth_request 信息
其余 master 节点收到 slave1 和 slave2 的音讯，会给 slave1 或 slave2 发送 failover_auth_ack，在一个选举周期中，一个 master 只会响应第一个给它发消息的 slave
slave 们收集返回的 failover_auth_ack，当收到 超过半数 的 master 的 ack 音讯后变成新的 master
最初向整个集群播送当初本人是 master，同时负责旧 master 所有 slots 的信息
其余节点接管到信息后，更新本人的保护状态

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

正文完