面试题：缓存设计之本地缓存与分布式缓存性能综合考量

Question

假设有一个大型微服务架构的系统，其中不同微服务对缓存的需求差异较大，部分对读写性能要求极高，部分对数据一致性要求近乎实时。请你从整体架构层面出发，设计一套融合本地缓存与分布式缓存的方案，详细说明如何根据不同微服务的需求分配使用本地缓存或分布式缓存，以达到最优性能，同时阐述该方案在跨节点数据同步、缓存失效策略等方面可能面临的挑战及应对措施。

Answer 1

一、缓存方案设计

1. 本地缓存：
   • 适用场景：对于对读写性能要求极高的微服务，采用本地缓存。例如，某些实时性要求高的业务逻辑，像高频交易系统中的行情数据展示模块。本地缓存将数据存储在微服务所在的节点内存中，访问速度极快。
   • 选型：可以选择 Guava Cache 这类轻量级的本地缓存框架，它具有简单易用、支持多种缓存策略（如基于容量、基于时间等）的特点。
2. 分布式缓存：
   • 适用场景：对于对数据一致性要求近乎实时的微服务，使用分布式缓存。例如，涉及用户账户信息的微服务，多个节点可能同时读取和修改账户数据，需要保证数据的一致性。分布式缓存如 Redis，可通过集群部署提供高可用性和扩展性。
   • 选型：Redis 具备丰富的数据结构（如 String、Hash、List 等），支持数据的持久化，并且通过发布 - 订阅模式可以实现数据的实时同步。

二、根据微服务需求分配缓存

1. 高读写性能需求：
   • 当微服务主要处理读多写少且对响应时间极其敏感的业务时，优先使用本地缓存。本地缓存的使用可以大大减少网络开销，提高响应速度。例如，新闻资讯类微服务在展示新闻列表时，将热门新闻列表数据缓存在本地，每次请求直接从本地缓存读取，无需访问分布式缓存或数据库。
   • 对于写操作，在更新本地缓存的同时，异步更新分布式缓存，以保证最终一致性。例如，使用异步消息队列（如 Kafka）来处理写操作的异步化，将写请求发送到消息队列，由消息队列的消费者负责更新分布式缓存。
2. 高数据一致性需求：
   • 对于数据一致性要求近乎实时的微服务，主要依赖分布式缓存。通过分布式缓存的同步机制（如 Redis 的主从复制、哨兵模式或 Cluster 模式）来保证数据在各个节点之间的一致性。
   • 在读写操作时，直接与分布式缓存交互。例如，电商系统中订单状态的更新和查询，都直接操作分布式缓存中的订单状态数据，确保所有节点获取到的订单状态是一致的。

三、面临的挑战及应对措施

1. 跨节点数据同步：
   • 挑战：在使用本地缓存与分布式缓存结合的方案中，跨节点数据同步是一个关键问题。当分布式缓存的数据发生变化时，需要及时通知本地缓存进行更新，否则可能导致数据不一致。
   • 应对措施：
     • 使用分布式缓存的发布 - 订阅功能。例如，Redis 可以通过发布 - 订阅模式，当数据在分布式缓存中发生变化时，发布一个消息，本地缓存监听该消息，接收到消息后及时更新本地缓存数据。
     • 采用缓存版本号机制。为每个缓存数据设置版本号，当分布式缓存数据更新时，版本号加 1。本地缓存在读取数据时，同时读取版本号，与本地缓存中的版本号进行比较，如果不一致，则从分布式缓存重新获取数据。
2. 缓存失效策略：
   • 挑战：不同微服务对缓存失效策略的需求不同，同时要保证在缓存失效时系统的性能和数据一致性不受太大影响。
   • 应对措施：
     • 读写性能优先的微服务：采用基于时间的失效策略（如 Guava Cache 的 expireAfterWrite 或 expireAfterAccess），结合定期主动刷新机制。例如，对于热门商品信息的本地缓存，设置较短的过期时间，同时定时从分布式缓存或数据库中重新加载数据，以保证数据的及时性。
     • 数据一致性优先的微服务：采用基于事件的失效策略。当数据在分布式缓存中发生变化时，立即通知本地缓存失效。例如，在用户信息修改后，通过发布 - 订阅模式通知所有使用该用户信息本地缓存的微服务，使其缓存失效并重新从分布式缓存获取最新数据。同时，为了防止缓存击穿问题（大量请求同时访问刚失效的缓存键），可以采用互斥锁的方式，只允许一个请求去加载最新数据，其他请求等待。