Redis高可用的三种实现方式

Redis高可用的三种实现方式

1、 高可用的概念

​ 高可用(High Availability,即HA)，指的是通过尽量缩短日常维护操作和突发的系统崩溃所导致的停机时间，以提高系统和应用的可用性。一个业务系统如果全年无一时刻不在提供服务，它的可用性可达100%。那么什么样的系统可以称之为高可用呢，业界一般用几个九来衡量系统的可用性，当系统运行时间达到4个九即99.99%时的系统为高可用的，全年宕机时间为52分钟左右。

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

2、 高可用的实现方式

​ Redis实现高可用，在于提供多个节点，通常有三种部署模式：主从模式，哨兵模式，集群模式。

1.主从模式

​ 主从模式就是，部署多台Redis节点，其中只有一台节点是主节点（master），其他的节点都是从节点（slave）。主从模式实现读写分离，只有master节点提供数据的事务性操作（增删改），slave节点只提供读操作。所有slave节点的数据都是从master节点同步过来的，该模式的结构图如下：

​ 上图是一种简单的主从结构模式，它的slave节点都挂在master节点上，这样做的优点是slave节点与master节点的数据延迟较小。缺点是如果slave节点数量很多，master同步一次数据的时间花费较长。可以只在master节点下只挂载一个slave节点，其他节点挂载在这个salve节点上，数据同步经过传递完成，如下图所示。Redis和大部分中间件的主从模式中的数据同步都是由slave节点主动发起的，这样可以减少master的性能消耗。

高可用原理和优点：主从模式做到了数据冗余，数据拥有备份，当主节点发生故障时，可以选择一个slave节点继续提供服务(但是主从模式没有解决怎么选择slave节点作为master节点的方法，无法保证高可用)。

优点：

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

缺点：

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

2.哨兵模式

​ 在主从模式中，一旦master节点发生宕机，为了保证高可用，需要找一个slave节点作为新的master节点。谁来确定宕机，选择哪一个slave节点，这些问题都没有解决。哨兵(sentinal)模式则是为了解决这些问题而产生的，它用于对主从模式中每个节点进行监控，当出现故障时通过投票机制，选择新的master节点，并将所有的slave节点连接到master节点，架构如下图所示。

哨兵模式有三个作用：监控、通知和自动故障转移。

• 监控(Monitoring)：不断地检查master和salve是否运行正常。master存活检测、master和slave运行情况检测。
• 通知(Notification)：当被监控的某个节点出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
• 自动故障转移(Automatic failover)：断开master与slave之间的连接，选取一个salve作为master，将其他slave连接到新的master，并告知客户端新的节点地址。

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

缺点：

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

3. 集群模式

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

​ 集群模式中数据通过数据分片的方式被自动分割到不同的master节点上，每个Redis集群有16384个哈希槽，进行set操作时，每个key会通过CRC16校验后再对16384取模来决定放置在哪个槽。数据在集群模式中是分开存储的，那么节点之间想要知道其他节点的状态信息，包括当前集群状态、集群中各节点负责的哈希槽、集群中各节点的master-slave状态、集群中各节点的存活状态等是通过建立TCP连接，使用gossip协议来进行集群信息传播。

​ 故障判断方法：判断故障的逻辑其实与哨兵模式有点类似，在集群中，每个节点都会定期的向其他节点发送ping命令，通过有没有收到回复来判断其他节点是否已经下线。具体方法是采用半数选举机制，当A节点发现目标节点疑似下线，就会向集群中的其他节点散播消息，其他节点就会向目标节点发送命令，判断目标节点是否下线。如果集群中半数以上的节点都认为目标节点下线，就会对目标节点标记为下线，从而告诉其他节点，让目标节点在整个集群中都下线。

优点：

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