面试题：Redis在MySQL读写分离架构下的故障处理策略

Question

假设在MySQL读写分离架构中，Redis出现故障，阐述可能对系统读写操作产生的影响，并说明如何设计一套有效的故障恢复和容灾策略，以保障系统的高可用性和数据一致性。

Answer 1

对系统读写操作产生的影响

1. 读操作影响：
   • 若Redis用作缓存，读请求通常先查询Redis。Redis故障时，缓存无法命中，大量读请求将直接穿透到数据库，可能导致数据库负载瞬间升高，响应时间变长，甚至引发数据库性能瓶颈，出现服务不可用情况。
   • 若Redis用于存储热点数据，如排行榜等，故障时这些数据无法快速获取，影响读业务逻辑，如排行榜展示等功能可能无法正常呈现。
2. 写操作影响：
   • 如果使用Redis实现分布式锁以保证写操作的原子性和一致性，Redis故障会导致分布式锁无法获取，可能出现并发写冲突，影响数据一致性。例如在库存扣减等场景下，可能导致超卖现象。
   • 若采用异步写Redis并结合消息队列等机制进行数据同步，Redis故障会使消息堆积，影响后续数据处理流程，可能导致数据更新不及时。

故障恢复和容灾策略

1. 故障恢复策略：
   • 快速检测：使用心跳检测机制，定时向Redis发送PING命令，若连续多次未收到响应，则判定Redis故障。例如每5秒发送一次PING命令，连续3次未响应则触发故障处理流程。
   • 重启Redis：尝试重启Redis服务，先通过系统命令优雅关闭Redis进程，然后重新启动。在重启过程中，监控Redis日志，查看是否有启动异常信息。若因内存、磁盘空间等资源问题导致故障，调整相应资源配置后再重启。
   • 数据恢复：如果Redis开启了持久化（RDB或AOF），重启后会自动加载持久化文件恢复数据。对于RDB，恢复速度快但可能存在数据丢失（上次快照后的数据）；对于AOF，数据丢失相对较少但恢复速度可能较慢。若持久化文件损坏，可尝试使用工具修复（如redis-check-rdb、redis-check-aof）。
2. 容灾策略：
   • 主从复制：部署Redis主从架构，主节点负责写操作，从节点复制主节点数据并提供读服务。当主节点故障时，通过选举机制（如Redis Sentinel或Redis Cluster自带的选举）将从节点晋升为主节点。例如，部署一个主节点和两个从节点，Sentinel监控主从节点状态，当主节点故障时，Sentinel自动将一个从节点提升为主节点。
   • 多副本部署：在不同机房或地理位置部署多个Redis副本，采用异步或同步复制方式保持数据一致性。当一个机房出现故障，其他机房的副本可继续提供服务。例如使用Redis Cluster的多节点多副本机制，数据在多个节点间分布，提高可用性。
   • 降级策略：当Redis故障时，启用降级策略。对于读操作，如缓存穿透情况，可设置一个短时间内的兜底数据（如默认值）返回给客户端，同时记录日志，后续再尝试从数据库获取真实数据并更新缓存。对于写操作，如分布式锁不可用时，可采用本地锁（如Java的synchronized关键字）作为临时替代方案，但需注意本地锁的性能和适用范围，避免影响系统并发性能。
   • 数据预加载：在系统启动或Redis恢复后，预先加载部分热点数据到Redis，减少缓存重建时的数据库压力。例如通过定时任务在系统启动时从数据库查询热门商品信息并加载到Redis。