面试题答案
一键面试缓存架构设计
- 整体架构分层
- 应用层：各个业务模块（商品展示、订单处理、用户信息管理）通过各自的服务接口访问缓存。
- 缓存层：采用分布式缓存系统，如Redis。根据业务模块特点进行缓存分区，例如商品展示相关缓存放在一组Redis实例，订单和用户信息缓存放在其他实例或集群。
- 持久化存储层：使用关系型数据库（如MySQL）或NoSQL数据库（如MongoDB），依据业务场景选择，用于在缓存失效或数据更新时提供数据来源和持久化存储。
- 各业务模块与缓存交互
- 商品展示模块
- 读操作：首先从缓存中读取商品信息，包括商品详情、价格、库存等。若缓存命中，直接返回数据给前端；若缓存未命中，从数据库读取数据，将数据写入缓存并返回给前端。
- 写操作：当商品信息发生变化（如价格调整、库存更新），先更新数据库，再删除缓存中的对应商品数据，确保下次读取时能从数据库获取最新数据并更新缓存。
- 订单处理模块
- 读操作：订单相关信息（如订单状态、订单详情）的读取，优先从缓存获取。考虑到订单数据一致性要求较高，缓存设置较短的过期时间。若缓存未命中，从数据库读取并更新缓存。
- 写操作：订单状态更新等写操作，先在数据库执行事务确保数据持久化，成功后更新缓存中的订单状态，保证缓存数据与数据库一致。
- 用户信息管理模块
- 读操作：读取用户基本信息、会员等级等，从缓存获取。缓存命中率可设置较高，因为用户信息变动相对不频繁。若缓存未命中，从数据库加载并填充缓存。
- 写操作：用户信息修改时，先更新数据库，再删除或更新缓存中的用户相关数据，维持缓存与数据库同步。
- 商品展示模块
缓存高效、稳定运行策略
- 缓存容量规划：根据业务预估和历史数据，合理规划缓存容量。定期监控缓存使用情况，设置预警机制，当缓存使用率接近阈值时，及时进行扩容。
- 缓存集群化：采用Redis集群，通过分片（sharding）将数据分布到多个节点，提高缓存的读写性能和可扩展性。利用主从复制（master - slave replication）机制，主节点负责写操作，从节点负责读操作，增强系统的读写能力和容错性。
- 缓存预热：在系统启动或业务高峰来临前，提前将热点数据加载到缓存中，避免冷启动时大量缓存未命中导致数据库压力过大。
- 缓存监控与优化：使用监控工具（如Prometheus + Grafana）实时监控缓存的命中率、读写性能、内存使用等指标。根据监控数据，对缓存策略进行调整，如优化缓存过期时间、调整缓存数据结构等。
数据最终一致性保证
- 读写顺序控制：在写操作时，先更新数据库，再操作缓存。对于读操作，通过设置合理的缓存过期时间，确保在过期后能从数据库获取最新数据更新缓存。
- 缓存更新策略：采用“写后失效”策略为主，部分对一致性要求极高的场景可结合“写时更新”策略。例如订单状态更新采用写时更新缓存，商品库存更新采用写后失效缓存。
- 异步数据同步：对于一些对实时性要求不高的数据一致性场景，可采用异步消息队列（如Kafka）。当数据库数据更新后，发送消息到队列，由消费者异步更新缓存，确保最终一致性。
常见问题应对策略
- 缓存失效
- 设置不同过期时间：根据业务数据的变化频率，为不同类型的数据设置不同的过期时间。如商品库存过期时间短，商品描述过期时间长。
- 随机过期时间：对于热点数据，设置随机的过期时间，避免大量数据同时过期导致缓存雪崩。
- 缓存更新机制：除了设置过期时间外，结合业务逻辑，在数据发生变化时主动更新或删除缓存。
- 缓存穿透
- 布隆过滤器（Bloom Filter）：在查询数据前，先通过布隆过滤器判断数据是否存在。如果布隆过滤器判断数据不存在，则直接返回，不再查询数据库，避免无效查询穿透到数据库。
- 空值缓存：当查询数据库未命中时，将空值也缓存起来，并设置较短的过期时间，防止后续相同的无效查询穿透。
- 缓存雪崩
- 加锁排队：在缓存失效后，对同一类数据的查询请求进行加锁排队，只让一个请求去查询数据库并更新缓存，其他请求等待，避免大量请求同时查询数据库。
- 多级缓存：采用多级缓存架构，如一级缓存使用Redis，二级缓存使用本地缓存（如Guava Cache）。当一级缓存失效时，二级缓存可以提供一定的缓冲，减轻数据库压力。
- 服务降级：当缓存雪崩导致系统压力过大时，对一些非核心业务进行服务降级，如部分商品展示的个性化推荐功能暂时关闭，优先保证核心业务（如订单处理）的正常运行。