面试题：缓存设计之专家难度：复杂业务下分布式缓存命中率与一致性权衡及优化

Question

在一个涉及多个微服务且数据交互复杂的金融系统中，既要保证分布式缓存的高命中率，又要兼顾数据一致性。请分析在这种情况下会面临哪些挑战，并提出一套完整的解决方案，包括但不限于缓存架构设计、数据同步机制、异常处理等，同时说明如何在不同业务场景下平衡命中率和一致性。

Answer 1

面临的挑战

1. 缓存穿透：查询不存在的数据，每次都绕过缓存直接查询数据库，导致数据库压力增大。
2. 缓存雪崩：大量缓存同时过期，大量请求直接涌向数据库，可能导致数据库崩溃。
3. 缓存击穿：热点数据缓存过期瞬间，大量请求同时访问该数据，击穿缓存直接访问数据库。
4. 数据一致性维护：微服务间数据交互复杂，缓存与数据库数据同步困难，不同微服务对同一数据操作顺序不同可能导致数据不一致。
5. 缓存更新策略：选择不当的更新策略（如先更新数据库再更新缓存、先删除缓存再更新数据库等）可能出现数据不一致情况。

解决方案

1. 缓存架构设计
   • 多级缓存：采用本地缓存（如 Caffeine）与分布式缓存（如 Redis）结合。本地缓存处理高频访问，减少对分布式缓存的压力；分布式缓存提供全局数据一致性。
   • 读写分离：对于读多写少的场景，设置多个只读缓存副本，写操作更新主缓存，然后同步到副本，提高读取性能和命中率。
   • 分片策略：根据业务数据特征，如用户 ID、账户 ID 等进行哈希分片，将数据均匀分布在多个缓存节点上，避免单个节点压力过大。
2. 数据同步机制
   • 异步消息队列：利用 Kafka 等消息队列，当数据发生变化时，数据库更新后发送消息到队列，相关微服务监听队列更新缓存，保证数据最终一致性。
   • 数据库 binlog 订阅：通过订阅数据库的 binlog，解析数据变更日志，实时同步到缓存，减少数据不一致的时间窗口。
   • 缓存更新策略：采用先更新数据库，再删除缓存的策略，并结合分布式锁保证操作原子性，防止并发操作导致数据不一致。
3. 异常处理
   • 缓存穿透处理：使用布隆过滤器，在查询缓存前先判断数据是否存在，不存在则直接返回，避免查询数据库。对于已查询过不存在的数据，也可在缓存中设置一个空值并设置较短过期时间，防止后续重复查询数据库。
   • 缓存雪崩处理：设置缓存过期时间时，添加随机值，避免大量缓存同时过期。同时，采用熔断机制，当数据库压力过大时，暂时停止部分非关键业务请求，返回兜底数据。
   • 缓存击穿处理：使用互斥锁（如 Redis 的 SETNX 命令），在缓存过期时，只允许一个请求去查询数据库并更新缓存，其他请求等待，避免大量请求同时访问数据库。

不同业务场景下平衡命中率和一致性

1. 读多写少场景：更注重缓存命中率，适当放宽一致性要求，采用异步更新缓存方式，优先保证数据快速读取，通过消息队列等机制最终保证数据一致性。
2. 读写均衡场景：在保证一定命中率前提下，采用同步更新缓存策略，如通过分布式锁确保缓存与数据库同步更新，在更新数据时短暂降低命中率，换取较高的数据一致性。
3. 写多读少场景：以数据一致性为主，每次写操作后及时更新缓存，可采用先更新数据库再更新缓存并加锁的方式，此时命中率可能会因频繁更新缓存受一定影响，但能保证数据的强一致性。