Redis高可用方案

一.名词解释

二.主从复制

Redis主从复制模式可以将主节点的数据同步给从节点，从而保障当主节点不可达的情况下，从节点可以作为

后备顶上来，并且可以保障数据尽量不丢失（主从复制可以保障最终一致性）。第二，从节点可以扩展主节点的读

能力，一旦主节点不能支持大规模并发量的读操作，从节点可以在一定程度上分担主节点的压力。

主从复制面临的问题：

1.当主节点发生故障的时候，需要手动的将一个从节点晋升为主节点，同时通知应用方修改主节点地址并重启

应用，同时需要命令其它从节点复制新的主节点，整个过程需要人工干预。

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

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

三. 原始的故障迁移

1.主节点发生故障后，客户端连接主节点失败，两个从节点与主节点连接失败造成复制中断。

2.如果主节点无法正常启动，需要选出一个从节点(slave-1),对其执行slaveof no one命令使其成为新的主节

3.原来的从节点（slave-1）成为新的主节点后，更新应用方的主节点信息，重新启动应用方。

4.客户端命令另一个从节点（slave-2）去复制新的主节点

5.待原来的主节点恢复后，让它去复制新的主节点

四.Redis Sentinel的高可用

当主节点出现故障时，Redis Sentinel能自动完成故障发现和故障转移，并通知应用方，从而实现真正的高可用。

RedisSentine是一个分布式架构，其中包含若干个Sentinel节点和Redis数据节点，每个Sentinel节点会对数据节点和

其余Sentinel节点进行监控，当它发现节点不可达时，会对节点做下线标识。如果被标识的是“主节点”，它还会和

其他的Sentinel节点进行“协商”，当大多数Sentinel节点都认为主节点不可达时，它们会选举一个Sentinel节点来完

成自动故障转移的工作，同时会将这个变化实时通知给Redis应用方。整个过程是自动的，不需要人工干预，解决了

Redis的高可用问题。

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

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

2. Sentinel节点集合是由若干个Sentinel节点组成的，这样即使个别Sentinel节点不可用，整个Sentinel节点集合依

然是健壮的。

Redis Sentinel具有以下几个功能：

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

2.通知：Sentinel会将故障转移的结果通知给应用方。

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

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

五. Redis Sentinel拓扑结构

六. Redis Sentinel节点发现和监控机制

Redis Sentinel通过三个定时监控任务完成对各个节点的发现和监控：

1.每隔10秒，每个Sentinel会向主节点和从节点发送info命令获取最新的拓扑结构。

2.每隔2秒，每个Sentinel节点会向Redis数据节点的_sentinel_：hello频道上发送该Senitnel节点对于主节点的判断。

以及当前Sentinel节点的信息，同时每个Sentinel节点也会订阅该频道，来了解其他Sentinel节点以及他们对主节

点的判断。这个定时任务可以完成以下两个工作：

（1）发现新的Sentinel节点：通过订阅主节点的_Sentinel_:hello了解其他Sentinel节点信息。如果是新加入的

Sentinel节点，将该Sentinel节点信息保存起来，并与改Sentinel节点创建连接

（2）Sentinel节点之间交换主节点状态，作为后面客观下线以及领导者选举的依据

3.每隔1秒，每个Sentinel节点会向主节点、从节点、其余Sentinel节点发送一条ping命令做一次心跳检测，来确认

当前节点是否可达。与主节点，从节点，其余Sentinel都建立起连接，实现了对每个节点的监控。这个定时任务

是节点失败判定的重要依据。

七. Redis Sentinel部署技巧

1.Sentinel节点不应该部署在一台物理机上。

2.部署至少三个且奇数个的Sentinel节点

3.只有一套Sentinel，还是每个主节点配置一套Sentinel的讨论的建议方案是如果Sentinel节点集合监控的是同一个

业务的多个主节点集合，那么使用方案一，否则使用方案2.

八. Redis Cluster|数据分区

Redis数据分区：RedisCluster采用虚拟槽分区，所有的键根据哈希函数映射到0-16383整数槽内，

计算公式：slot=CRC16(key) &16383。每一个节点负责维护一部分槽以及槽所映射的键值数据。

Redis虚拟槽分区的特点：

1.解耦数据和节点之间的关系，简化了节点扩容和收缩的难度

2.节点自身维护槽的映射关系，不需要客户端或者代理服务维护槽分区元数据

3.支持节点、槽、键之间的映射查询，用于数据路由、在线伸缩等场景。

九. Redis Cluster|功能限制

1.Key批量操作支持有限。目前只支持同slot内的key执行批量操作（如mget,mset）。

2.Key事务操作支持有限。只支持多key在同一个节点上的事务操作，多个key分布在不同节点上时无法使用事务功能。

3.Key作为数据分区的最小粒度，因此不能将一个大的键值对象如hash，list等映射到不同节点。

4.不支持多数据库空间，集群模式下只能使用db0空间。

5.复制结构只支持一层，从节点只能复制主节点，不支持嵌套树状复制结构。

十. Redis Cluster|集群伸缩

Redis集群提供了灵活的节点扩容和收缩方案，在不影响集群对外服务的情况下，可以为集群添加节点进行

扩容也可以下线部分节点进行缩容。

扩容集群的步骤：

1.准备新节点

2.加入集群

3.迁移槽和数据

缩容集群的步骤：

1.首先要确定下线节点是否有负责的槽，如果是，需要把槽迁移到其他节点，保证节点下线后真个集群槽节点映射的完整性

2.当下线节点不再负责槽或者本身是从节点时，就可以通知集群内其他节点忘记下线节点，就可以通知集群内其他节点忘记下线节点当所有的节点忘记该节点后可以正常关闭。

十一. Redis Cluster|故障发现

Redis集群自身实现了高可用。高可用首先需要解决集群部分失败的场景：当少数节点出现故障时，可以通过

自动故障转移保证集群可以正常对外提供服务。

故障发现的类型：

1.主观下线：指某个节点认为另一个节点不可用，即下线状态，这个状态并不是最终的故障判定，只能代表一个节点的意见，可能存在误判情况。

2.客观下线：指标记一个节点真正的下线，集群内多个节点都认为该节点不可用，从而达成共识的结果。如果持有槽的主节点故障，需要为该节点进行故障转移。

十二. Redis Cluster|故障恢复

故障节点变为客观下线后，如果下线节点是持有槽的主节点，则需要在它的从节点中选出一个替换它。从而保证集群高可用。下线主节点的所有从节点承担故障恢复的义务，当从节点通过内部定时任务发现自身复制的主节点进入客观下线时，将会触发故障恢复流程。

https://blog.csdn.net/sunhuiliang85/article/details/78361211