面试题：缓存设计之专家难度：复杂业务场景下缓存降级与熔断的深度优化与权衡

Question

考虑一个金融交易系统，该系统对数据一致性和可用性要求极高。在交易过程中，会涉及到多个步骤和多个外部服务调用，例如身份验证服务、风险评估服务、资金托管服务等。同时，系统采用多级缓存架构（如本地缓存、分布式缓存等）来提高性能。现在要求设计一套缓存降级与熔断机制，不仅要满足在各种异常情况下保障核心交易流程的可用性，还要在恢复正常后尽量减少数据不一致性带来的风险。请详细描述整体设计方案、关键技术点以及如何在不同策略之间进行权衡。

Answer 1

整体设计方案

1. 缓存降级
   • 定义关键交易数据：确定哪些数据是核心交易流程必须的，如交易金额、用户身份信息等。对于这些关键数据，设置兜底策略，当缓存获取失败时，直接从数据库读取。
   • 设置降级开关：通过配置中心统一管理缓存降级开关，以便在出现大规模缓存故障时能快速手动或自动开启降级。例如，使用 Apollo 或 Spring Cloud Config 作为配置中心。
   • 异步更新缓存：当从数据库读取数据完成交易后，通过异步任务重新填充缓存，确保后续请求可以从缓存获取数据。可以使用消息队列（如 Kafka 或 RabbitMQ）来异步处理缓存更新任务。
2. 熔断机制
   • 服务调用监控：对于涉及的外部服务（身份验证、风险评估、资金托管等），使用断路器模式（如 Hystrix 或 Sentinel）来监控服务调用情况。记录调用成功、失败、超时的次数等指标。
   • 熔断触发条件：设定熔断触发的阈值，如连续 20 次调用中有 15 次失败，或者调用超时率达到 50%，则触发熔断。熔断后，不再调用该外部服务，直接返回预设的兜底数据或错误提示。
   • 熔断恢复：设置熔断恢复的检测周期，例如每 10 秒尝试恢复一次服务调用。如果在检测周期内，一定比例的调用成功（如 60%），则关闭熔断，恢复正常调用。

关键技术点

1. 缓存技术
   • 本地缓存：使用 Guava Cache 实现本地缓存，它具有简单易用、高效的特点，适合存储一些高频访问且不经常变化的数据。例如，用户身份验证的部分结果可以缓存在本地。
   • 分布式缓存：采用 Redis 作为分布式缓存，它支持丰富的数据结构，并且具备高可用和高性能。对于共享的交易数据，如交易限额等，存储在 Redis 中。
2. 断路器实现
   • Hystrix：通过注解或配置的方式在服务调用代码中集成 Hystrix。它提供了线程隔离、信号量隔离等机制，防止单个服务故障拖垮整个系统。
   • Sentinel：以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。它提供了丰富的规则配置和实时监控功能。
3. 数据一致性保障
   • 事务管理：在涉及数据库操作时，使用分布式事务框架（如 Seata）来保证数据的一致性。例如，在资金托管服务调用时，确保资金转移的原子性。
   • 版本控制：对关键数据引入版本号，每次数据更新时版本号递增。缓存中的数据也携带版本号，当缓存数据与数据库版本不一致时，及时更新缓存。

不同策略之间的权衡

1. 缓存降级与正常缓存使用：缓存降级虽然能保证核心交易流程的可用性，但会增加数据库的压力。因此，需要根据系统的负载情况和数据库的承受能力来调整降级策略。在缓存故障较小时，可以尝试部分降级，只对关键数据进行数据库读取，尽量减少对数据库的冲击。
2. 熔断与正常服务调用：熔断机制能快速切断故障服务，避免级联故障，但如果熔断阈值设置过低，可能会导致正常服务也被熔断，影响系统功能。所以，需要根据外部服务的历史性能数据和业务需求，合理设置熔断阈值和恢复检测周期。例如，对于稳定性较差的外部服务，可以适当放宽熔断阈值，延长恢复检测周期；对于核心且稳定的外部服务，应严格设置阈值，确保及时发现故障。
3. 数据一致性与可用性：在保障可用性的同时，要尽量减少数据不一致带来的风险。异步更新缓存可能会导致短时间内数据不一致，因此要根据业务场景评估可接受的数据不一致时间窗口。对于资金相关的关键数据，应优先保证一致性，可以采用同步更新缓存的方式，但可能会牺牲一定的可用性；对于一些非关键数据，如用户的个性化推荐信息，可以容忍一定时间的数据不一致，采用异步更新缓存来提高系统的整体可用性。