首页
技术小册
AIGC
面试刷题
技术文章
MAGENTO
云计算
视频课程
源码下载
PDF书籍
「涨薪秘籍」
登录
注册
开篇词 | 阅读Redis源码能给你带来什么?
01 | 带你快速攻略Redis源码的整体架构
02 | 键值对中字符串的实现,用char*还是结构体?
03 | 如何实现一个性能优异的Hash表?
04 | 内存友好的数据结构该如何细化设计?
05 | 有序集合为何能同时支持点查询和范围查询?
06 | 从ziplist到quicklist,再到listpack的启发
07 | 为什么Stream使用了Radix Tree?
08 | Redis server启动后会做哪些操作?
09 | Redis事件驱动框架(上):何时使用select、poll、epoll?
10 | Redis事件驱动框架(中):Redis实现了Reactor模型吗?
11 | Redis事件驱动框架(下):Redis有哪些事件?
12 | Redis真的是单线程吗?
13 | Redis 6.0多IO线程的效率提高了吗?
14 | 从代码实现看分布式锁的原子性保证
15 | 为什么LRU算法原理和代码实现不一样?
16 | LFU算法和其他算法相比有优势吗?
17 | Lazy Free会影响缓存替换吗?
18 | 如何生成和解读RDB文件?
19 | AOF重写(上):触发时机与重写的影响
20 | AOF重写(下):重写时的新写操作记录在哪里?
21 | 主从复制:基于状态机的设计与实现
22 | 哨兵也和Redis实例一样初始化吗?
23 | 从哨兵Leader选举学习Raft协议实现(上)
24 | 从哨兵Leader选举学习Raft协议实现(下)
25 | Pub/Sub在主从故障切换时是如何发挥作用的?
26 | 从Ping-Pong消息学习Gossip协议的实现
27 | 从MOVED、ASK看集群节点如何处理命令?
28 | Redis Cluster数据迁移会阻塞吗?
29 | 如何正确实现循环缓冲区?
30 | 如何在系统中实现延迟监控?
31 | 从Module的实现学习动态扩展功能
32 | 如何在一个系统中实现单元测试?
当前位置:
首页>>
技术小册>>
Redis源码剖析与实战
小册名称:Redis源码剖析与实战
### 25 | Pub/Sub在主从故障切换时是如何发挥作用的? 在Redis的广阔功能中,发布/订阅(Pub/Sub)模式是一种强大的消息传递机制,它允许发送者(发布者)将消息发送到指定的频道(channel),而无需直接知道哪些订阅者(接收者)将接收这些消息。订阅了该频道的所有客户端都会接收到这些消息。当Redis部署在主从复制环境中时,Pub/Sub的行为变得尤为复杂且关键,特别是在主节点故障并触发故障切换时。本章将深入探讨Pub/Sub模式在主从架构中的工作机制,特别是它如何在主从故障切换过程中保持消息传递的一致性和可靠性。 #### 一、Redis主从复制基础 在深入Pub/Sub在主从故障切换中的作用之前,有必要先了解Redis的主从复制机制。Redis的主从复制是一个异步的过程,其中从服务器会连接到主服务器,并请求复制主服务器上的数据。复制过程主要分为三个阶段:连接、数据同步、命令传播。数据同步阶段,从服务器会加载主服务器发送的RDB快照文件,并通过后续的命令传播保持数据一致。 #### 二、Pub/Sub机制简介 在Redis中,Pub/Sub通过频道(channel)进行消息的分发。客户端可以订阅一个或多个频道,并接收发送到这些频道的所有消息。Redis服务器不保留任何历史消息,一旦消息被发送到频道,它就被分发给所有订阅了该频道的客户端,之后即被丢弃。这种设计使得Pub/Sub成为处理实时消息传递的理想选择。 #### 三、主从架构下的Pub/Sub挑战 在Redis的主从复制架构中,Pub/Sub模式面临几个挑战: 1. **消息同步的实时性**:由于主从复制是异步的,从服务器上的数据可能稍微滞后于主服务器。在Pub/Sub场景中,这意味着从服务器上的订阅者可能无法实时接收到所有消息。 2. **故障切换时的消息丢失**:当主服务器故障时,如果尚未同步的消息还在内存中,这些消息可能会丢失,除非使用了额外的持久化机制。 3. **客户端重新连接**:故障切换后,客户端需要重新连接到新的主服务器(或从服务器升级为新的主服务器),并重新订阅频道以继续接收消息。 #### 四、Pub/Sub在主从故障切换中的作用机制 在主从故障切换的上下文中,Pub/Sub机制通过一系列策略确保消息的可靠传递和系统的稳定性。 ##### 4.1 故障检测与切换 Redis主从复制环境通常依赖哨兵(Sentinel)系统来监控主服务器的健康状况,并在检测到故障时自动触发故障切换。哨兵会选举一个从服务器作为新的主服务器,并更新其他从服务器和客户端的配置,使其连接到新的主服务器。 ##### 4.2 消息同步策略 - **全量同步与部分同步**:在故障切换后,新晋升的主服务器(原从服务器)可能已经接收到了部分或全部未同步到旧从服务器的消息。为了最小化数据丢失,Redis支持部分同步,即只同步自上次同步以来更改的数据。然而,对于Pub/Sub消息,由于它们不被持久化,部分同步在此场景下不适用。 - **客户端重连与订阅恢复**:客户端在检测到连接断开后(如通过心跳检测),会尝试重新连接到Redis服务器。如果此时已发生故障切换,客户端应连接到新的主服务器,并重新订阅之前订阅的频道。这一过程通常是自动的,依赖于客户端库的实现。 ##### 4.3 消息持久化与恢复 尽管Redis的默认配置下Pub/Sub消息不被持久化,但可以通过外部系统(如Kafka、RabbitMQ等消息队列)或Redis自身的持久化机制(如AOF)来间接实现消息的持久化。例如,可以在发送Pub/Sub消息的同时,也将这些消息写入AOF文件中。然而,这种方法会增加I/O开销,并可能影响Redis的性能。 ##### 4.4 客户端策略 客户端在实现时可以采取一些策略来增强Pub/Sub的可靠性: - **确认机制**:虽然Redis原生的Pub/Sub不支持消息确认,但客户端可以通过实现自己的确认逻辑(如使用ACK消息)来确保消息被正确处理。 - **消息重试**:对于未能成功发送的消息,客户端可以配置重试机制,尝试重新发送到新的主服务器。 - **订阅持久化**:客户端可以维护一个订阅列表,并在重新连接后自动重新订阅这些频道。 #### 五、最佳实践与注意事项 - **监控与警报**:实施严格的监控和警报系统,以便在Redis服务器出现问题时及时响应。 - **测试故障切换**:定期进行故障切换测试,以确保系统能够按预期工作,并发现潜在的问题。 - **客户端库选择**:选择支持自动重连和重新订阅功能的客户端库,以减少开发工作量并提高系统的健壮性。 - **考虑消息持久化**:根据业务需求评估是否需要实现消息的持久化,并选择最适合的方案。 - **文档与培训**:为运维团队和开发团队提供充分的文档和培训,确保他们了解Redis主从复制和Pub/Sub的工作原理,以及如何在故障切换时保持系统的稳定性。 #### 六、结论 Redis的Pub/Sub模式在主从复制环境中面临着独特的挑战,但通过合理的架构设计、客户端策略以及外部系统的辅助,可以确保消息传递的可靠性和系统的稳定性。在主从故障切换时,Pub/Sub机制通过自动重连、重新订阅以及可能的消息持久化策略,有效地减少了消息丢失的风险,保障了系统的连续性和可用性。对于需要高可靠性和实时性的应用场景,深入理解并合理应用这些策略至关重要。
上一篇:
24 | 从哨兵Leader选举学习Raft协议实现(下)
下一篇:
26 | 从Ping-Pong消息学习Gossip协议的实现
该分类下的相关小册推荐:
Redis面试指南
Redis核心技术与实战
Redis零基础到实战
Redis的Lua脚本编程