07-10 02:23 阅读 59

redis 简单整理——哨兵简单介绍[二十八]

简单介绍一下哨兵模式。

Redis的主从复制模式下，一旦主节点由于故障不能提供服务，需要人工将从节点晋升为主节点，同时还要通知应用方更新主节点地址，对于很多应用场景这种故障处理的方式是无法接受的。

也就是我们前面提及的主从复制的模式下，主和从是固定的，当主宕机后，那么只能等待主的恢复，这样不利于高可用性，也就是没有一定的容错性。

Redis从2.8开始正式提供了Redis Sentinel（哨兵）架构来解决这个问题。

在了解sentinel 之前需要了解一些名词。

Redis Sentinel是Redis的高可用实现方案，在实际的生产环境中，对提高整个系统的高可用性是非常有帮助的。

Redis的主从复制模式可以将主节点的数据改变同步给从节点，这样从节点就可以起到两个作用：第一，作为主节点的一个备份，一旦主节点出了故障不可达的情况，从节点可以作为后备“顶”上来，并且保证数据尽量不丢失（主从复制是最终一致性）。

第二，从节点可以扩展主节点的读能力，一旦主节点不能支撑住大并发量的读操作，从节点可以在一定程度上帮助主节点分担读压力。

但是主从复制也带来了以下问题：

一旦主节点出现故障，需要手动将一个从节点晋升为主节点，同时需要修改应用方的主节点地址，还需要命令其他从节点去复制新的主节点，整个过程都需要人工干预。

·主节点的写能力受到单机的限制。

·主节点的存储能力受到单机的限制。

那么往上总结一下，单从主从这种模式上说呢，就是主只有一台，故而会受到单机影响。同时主从有两个作用，那就是可以分摊主库的读取能力，同样起到一个备份的作用。

同样单纯的主从还有一个问题，那么就是当起到一个备份容灾的作用的时候，那么不会自动将从库设置为主库，同样每个应用的主从都是固定死的，那么同样需要修改应用端。

这样就进入了人工阶段了，人工有一个缺点，就是恢复速度慢。

怎么说呢？可以看下下面的步骤。

其中的一个问题就是选取哪一台作为主库。

其中2 和 3可能反过来，但是无论如何，这样要花费大量的时间。

为了让下次恢复的时间更短一些，通常会写成一个或多个脚本。

那么问题是否就解决了呢？从工程学的角度上说远远没有解决。

为何这样说呢？因为脚本是固定的，不同的人操控熟练度不一样，难免出现问题。

其二脚本对于redis来说毕竟是外部程序，外部程序很难全面的去了解内部程序发生的变化。

第三呢，随着redis的更新，那么脚本可能出现不适用的情况，维护成本就来了。

redis sentinel 这个时候就来解决这个问题了。

Redis Sentinel是一个分布式架构，其中包含若干个Sentinel节点和Redis 数据节点，每个Sentinel节点会对数据节点和其余Sentinel节点进行监控，当它发现节点不可达时，会对节点做下线标识。

如果被标识的是主节点，它还会和其他Sentinel节点进行“协商”，当大多数Sentinel节点都认为主节点不可达时，它们会选举出一个Sentinel节点来完成自动故障转移的工作，同时会将这个变化实时通知给Redis应用方。

整个过程完全是自动的，不需要人工来介入，所以这套方案很有效地解决了Redis的高可用问题。

故障转移步骤:

故障转移后的拓扑结构图：

redis sentinel 有下面几个功能:

·监控：Sentinel节点会定期检测Redis数据节点、其余Sentinel节点是否可达。

·通知：Sentinel节点会将故障转移的结果通知给应用方。

·主节点故障转移：实现从节点晋升为主节点并维护后续正确的主从关系。

·配置提供者：在Redis Sentinel结构中，客户端在初始化的时候连接的是Sentinel节点集合，从中获取主节点信息。

同时看到，Redis Sentinel包含了若个Sentinel节点，这样做也带来了两个好处：

·对于节点的故障判断是由多个Sentinel节点共同完成，这样可以有效地防止误判。

·Sentinel节点集合是由若干个Sentinel节点组成的，这样即使个别Sentinel 节点不可用，整个Sentinel节点集合依然是健壮的。

但是Sentinel节点本身就是独立的Redis节点，只不过它们有一些特殊，它们不存储数据，只支持部分命令。

下一节redis sentinel 的部署。

原文：https://www.cnblogs.com/aoximin/p/15259857.html