Redis学习打卡-Day6-Redis 高可用(上)

Redis 高可用

  • Redis的高可用机制有持久化、复制、哨兵和集群。其主要的作用和解决的问题分别是:
    • 持久化:持久化是最简单的高可用方法(有时甚至不被归为高可用的手段),主要作用是数据备份,即将数据存储在硬盘,保证数据不会因进程退出而丢失。
    • 主从架构:主从复制是高可用Redis的基础,哨兵和集群都是在复制基础上实现高可用的。复制主要实现了数据的多机备份 ,以及对于读操作的负载均衡和简单的故障恢复。缺陷:故障恢复无法自动化;写操作无法负载均衡;存储能力受到单机的限制。
    • 哨兵:哨兵实现了主从复制中故障的自动化恢复。缺陷:写操作无法负载均衡;存储能力受到单机的限制。
    • 集群:通过集群,解决了写操作无法负载均衡,以及存储能力受到单机限制的问题,实现了较为完善的高可用方案。

Redis 主从架构

  • 单节点 Redis 的并发能力是有上限的,要进一步提高 Redis 的并发能力,就需要搭建主从集群,实现读写分离。
  • 所有的从节点都从主节点进行数据同步,这样会导致主节点的同步处理压力过大而成为瓶颈。为了解决这个问题,redis还支持了从slave节点分发的能力,也就是从服务器也可以有自己的从服务器, 多个从服务器之间可以构成一个主从链 。这样可以分摊主服务器压力。

全量同步

  • 何时执行?
    • slave 节点第一次连接 master 节点时。
    • slave 节点断开时间太久,repl_baklog中的 offset 已经被覆盖时。
  • master 如何判断 slave 是不是第一次来同步数据?
    • Replication ld:简称 replid,是数据集的标记,id 一致则说明是同一数据集。每一个master都有唯一的 replid,slave 则会继承 master 节点的 replid。
    • offset:偏移量,随着记录在 repl_baklog 中的数据增多而逐渐增大。slave 完成同步时也会记录当前同步的 offset。如果 slave 的 offset 小于 master 的 offset,说明 slave 数据落后于 master,需要更新。因此slave做数据同步,必须向master声明自己的replication Id 和 offset,master才可以判断到底需要同步哪些数据。
  • 流程:
    1. slave 节点请求增量同步。
    2. master 节点判断 replid,发现不一致,拒绝增量同步。
    3. master 将完整内存数据生成 RDB,发送 RDB 到 slave。
    4. slave 先清空当前本地数据,加载 master 的 RDB。
    5. master 将 RDB 期间的命令记录在 repl_baklog,并持续将 log 中的命令发送给 slave。
    6. slave 执行接收到的命令,保持与 master 之间的同步。
  • 主从服务器在完成第一次同步后,双方之间就会维护一个 TCP 连接,这个TCP连接是长连接。之后就会基于这个长连接进行命令传播。通过这种方式来保证第一次同步后的主从服务器的数据一致性。

增量同步

  • 何时执行?
    • slave 节点断开又恢复,并且在 repl_baklog 中能找到 offset 时。
  • repl_baklog 大小有上限,写满后会覆盖最早的数据。如果 slave 断开时间过久,导致尚未备份的数据被覆盖,则无法基于 log 做增量同步,只能再次全量同步。

主从复制存在的问题

  • Redis 的主从模式重点在于解决整体的承压能力,利用从节点分担读取操作的压力。但是其在容错恢复 等可靠性层面欠缺明显,不具备自动的故障转移与恢复能力

Redis 哨兵机制(Redis Sentinel)

  • 为了支持自动的故障恢复能力,Redis在主从模式的基础上进行优化增强,提供了哨兵(Sentinel)架构模式。
  • Redis的哨兵模式,就是在主从模式的基础上,额外部署若干独立的哨兵进程,通过哨兵进程去监视Redis主从节点的状态,一旦发现主节点宕机,则哨兵可以重新从剩余slave节点中推选一个新的节点并将其升级为master节点,以此保证整个系统功能可以正常使用。

哨兵负责三个任务:监控、选主、通知。

  • 监控:Sentinel会不断检查您的master和slave是否按预期工作。
  • 自动故障恢复:如果master故障,Sentinel会将一个slave提升为master。当故障实例恢复后也以新的master为主。
  • 通知:Sentinel充当Redis客户端的服务发现来源,当集群发生故障转移时,会将最新信息推送给Redis的客户端。
服务状态监控
  • Sentinel基于心跳机制监测服务状态,每隔1秒向集群的每个实例发送ping命令:
    • 主观下线:如果某sentinel节点发现某实例未在规定时间响应,则认为该实例主观下线。
    • 客观下线:若超过指定数量(quorum)的sentinel都认为该实例主观下线,则该实例客观下线。quorum值最好超过Sentinel实例数量的一半。
  • 哨兵误判:主库实际没有下线,但是哨兵以为它下线了。误判产生原因:比如集群网络压力较大,出现网络拥塞,或者主库本身压力较大,导致主节点没有在规定时间内响应哨兵的 PING 命令。
选举新的master
  • 一旦发现master故障,sentinel需要在salve中选择一个作为新的master,选择依据如下:
    • 首先判断每个slave节点与master节点断开时间长短,如果超过指定值(down-after-miliseconds*10),则会排除该slave节点。
    • 然后判断每个slave节点的slave-priority值,优先选择值小(优先级最高)的,如果是0则永不参与选举。
    • 如果slave-prority一样,则判断slave节点的offset值,优先选择值大(复制进度最大)的,越大说明数据越新。
    • 最后是判断slave节点的运行id大小,优先选择值小的。
通知
  • 在选举出从节点为新主节点后后,哨兵向被选中的从节点发送 SLAVEOF no one 命令,让这个从节点解除从节点的身份,将其变为新主节点。
  • sentinel给所有其它slave发送slaveof xxxxx 命令,让这些slave成为新master的从节点,开始从新的master上同步数据。
  • 最后,sentinel将故障节点标记为slave,当故障节点恢复后只能自动成为新的master的slave节点。

哨兵缺陷

  • 哨兵仍然没有解决写操作无法负载均衡、存储能力受到单机限制的问题。
相关推荐
科技小花7 小时前
全球化深水区,数据治理成为企业出海 “核心竞争力”
大数据·数据库·人工智能·数据治理·数据中台·全球化
X56618 小时前
如何在 Laravel 中正确保存嵌套动态表单数据(主服务与子服务)
jvm·数据库·python
Slow菜鸟8 小时前
AI学习篇(五) | awesome-design-md 使用说明
人工智能·学习
狐狐生风9 小时前
LangChain 向量存储:Chroma、FAISS
人工智能·python·学习·langchain·faiss·agentai
虹科网络安全9 小时前
艾体宝干货|数据复制详解:类型、原理与适用场景
java·开发语言·数据库
狐狐生风9 小时前
LangChain RAG 基础
人工智能·python·学习·langchain·rag·agentai
2301_771717219 小时前
解决mysql报错:1406, Data too long for column
android·数据库·mysql
小江的记录本10 小时前
【Kafka核心】架构模型:Producer、Broker、Consumer、Consumer Group、Topic、Partition、Replica
java·数据库·分布式·后端·搜索引擎·架构·kafka
dvjr cloi10 小时前
MySQL Workbench菜单汉化为中文
android·数据库·mysql
dFObBIMmai10 小时前
MySQL主从同步中大事务导致的延迟_如何拆分大事务优化同步
jvm·数据库·python