Redis高可用的三种实现方式（主从、哨兵、集群）

西西o

已于 2022-11-26 16:23:40 修改

阅读量1k

点赞数

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

于 2022-11-26 16:18:29 首次发布

本文链接：https://blog.csdn.net/Xixi0864/article/details/128053012

版权

Redis 专栏收录该内容

7 篇文章 0 订阅

订阅专栏

1、什么是高可用

高可用一般来说有两个含义：一是数据尽量不丢失，二是保证服务尽可能可用。 AOF 和 RDB 数据持久化保证了数据尽量不丢失,而多节点来保证服务尽可能提供服务。单个节点的系统缺点明显，一旦发生故障会导致服务不可用。而且，单个节点处理所有的请求，吞吐量有限，容量也有限。

2、Redis的高可用的实现方式

Redis实现高可用，通常有三种部署模式：主从模式，哨兵模式，集群模式。

1.主从模式（不重点）

redis多机器部署时，这些机器节点会被分成两类，一类是主节点（master节点），一类是从节点（slave节点）。

一般主节点可以进行读、写操作，而从节点只能进行读操作。

同时由于主节点可以写，数据会发生变化，当主节点的数据发生变化时，会将变化的数据同步给从节点，这样从节点的数据就可以和主节点的数据保持一致了。

一个主节点可以有多个从节点，但是一个从节点会只会有一个主节点，也就是所谓的一主多从结构。

优点：

实现读写分离，降低master节点的读数据压力，提高系统的性能。写操作交给master节点，读操作交给slave节点，提供多个副本。
配置简单，容易搭建。只需要在slave节点上维护master节点的地址信息就可实现。

缺点：

当master节点宕机时，由于无法选择哪一个slave节点当master节点，无法保证高可用。
所有的写数据的压力都集中在master节点，没有解决master节点写的压力。

全量复制

（第一次数据打开时，就会进行全量复制，第二次才会采用增量复制）

增量复制

2、哨兵模式

        利用哨兵监控主机，当主机因为网络原因下线后，哨兵会先主观认为主机下线，发送询问请求给其他哨兵，其他哨兵超过半数认为主机下线，此时就是客观下线。一旦哨兵认为主机客观下线了， 就会开始重新选主操作。

选主操作是如下流程：

        三个哨兵会一起投票，选出一台哨兵领导机器，去选择master主机。三个哨兵内部会先选出一个领导，由这个哨兵领导去选择master

        三个哨兵如何选出哨兵领导，采用投票机制。当某个哨兵得到了超过半数哨兵的投票后，这个哨兵就成为领导哨兵。

        哨兵领导选择主机的策略是：看谁的数据最新，最新的会被选为主机；如果多台机器数据一致，那么看谁先启动。

        为什么要超过半数？？防止脑裂（防止出现多个哨兵领导，采用少数服从多数原则）

优点：哨兵机制，保证高可用。能够监控各个节点运行状况，进行自动故障转移。

缺点：

中心化集群实现方式，基于主从模式，切换节点时，会发生数据的丢失。
集群里所有节点保存的都是全量数据，浪费内存空间，没有真正实现分布式存储。数据量过大时，主从同步严重影响master的性能。
数据写的操作都集中在master上，仍然没有解决master写数据的压力。

3、Cluster集群（重点）

哨兵模式基本已经实现了高可用，但是每个节点都存储相同的内容，很浪费内存。而且，哨兵模式没有解决master写数据的压力。为了解决这些问题，就有了集群模式，实现分布式存储，数据与数据之间通过心跳的方式来存储数据。每个节点存储不同的内容。集群部署的方式能自动将数据进行分片，每个master上放一部分数据，提供了内置的高可用服务，即使某个master宕机了，服务还可以正常地提供

优点：

无中心结构，部署简单。所有的Redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽。
可扩展性，可扩展master节点，释放单个master的写数据压力，节点可动态添加或删除。
能够实现自动故障转移，节点之间通过gossip协议交换状态信息，用投票机制完成slave到master的角色转换。