面试题：缓存设计之Redis发布订阅在高可用实时通知架构中的挑战与应对

Question

在构建一个分布式的高可用实时通知系统时，使用Redis发布订阅模式。考虑到Redis节点可能出现故障、网络分区等情况，阐述你会采取哪些措施来保证通知的可靠性和一致性。例如，如何处理发布者在发布消息时Redis节点故障导致消息丢失的问题，以及如何确保订阅者在网络恢复后能接收到所有未处理的通知。同时，说明在这种复杂环境下，如何进行系统的监控和故障排查。

Answer 1

保证通知可靠性和一致性的措施

1. 处理发布者发布消息时Redis节点故障导致消息丢失
   • 持久化：开启Redis的AOF（Append - Only File）或RDB（Redis Database）持久化机制。AOF将写操作追加到日志文件，RDB定期生成数据集快照。这样即使节点故障重启，已发布的消息仍可恢复。例如，在redis.conf中配置appendonly yes开启AOF持久化。
   • 主从复制与哨兵：搭建Redis主从集群，并使用哨兵（Sentinel）机制。主节点负责接收发布消息，从节点复制主节点数据。当主节点故障时，哨兵能自动选举新的主节点，发布者可重新连接新主节点继续发布，且消息不会丢失。例如，配置多个从节点，并在哨兵配置文件中定义监控主节点的相关参数。
   • 消息确认机制：发布者发送消息后，等待Redis返回确认。若未收到确认，可重试发布。如使用Redis的发布命令后，通过检查返回值判断消息是否成功发布到Redis。
2. 确保订阅者在网络恢复后能接收到所有未处理的通知
   • 持久化订阅：使用Redis的持久化订阅机制，如PSUBSCRIBE命令的持久化版本（部分Redis客户端库支持）。订阅者重新连接后，能从上次断开的位置继续接收消息。
   • 消息队列缓存：在订阅者端设置本地消息队列缓存，如使用RabbitMQ、Kafka等消息队列。当网络断开时，将未处理的通知缓存到消息队列。网络恢复后，从消息队列中读取并处理。
   • 记录偏移量：订阅者记录已处理消息的偏移量（offset），存储在Redis或其他持久化存储中。网络恢复后，根据偏移量请求未处理的消息。

系统监控和故障排查

1. 监控指标
   • 节点状态：通过Redis命令（如PING）或监控工具（如Prometheus + Grafana）监控每个Redis节点的存活状态。异常时及时报警。
   • 消息发布/订阅速率：统计单位时间内发布和订阅的消息数量，判断系统负载。若速率异常下降，可能存在故障。
   • 网络延迟：监控发布者、订阅者与Redis节点间的网络延迟，使用工具如ping、traceroute。高延迟可能导致消息处理缓慢或丢失。
2. 故障排查
   • 日志分析：查看Redis日志文件，了解节点故障、网络异常等信息。同时，在发布者和订阅者代码中添加详细日志，记录消息处理过程。
   • 模拟故障：在测试环境中模拟Redis节点故障、网络分区等情况，观察系统反应，验证故障处理机制是否有效。
   • 分布式跟踪：使用分布式跟踪工具（如Zipkin），跟踪消息在系统中的流转路径，定位故障发生位置。