面试题答案
一键面试选择预热的数据
- 热门商品:通过分析历史销售数据、浏览量、收藏量等指标,确定在以往大促活动中销量高、关注度高的商品。这些商品在本次大促期间大概率会成为用户访问的重点。
- 促销活动相关商品:参与大促活动的商品,如限时折扣、满减优惠等活动中的商品。这些商品是活动的核心,必然会吸引大量用户访问。
- 关联商品:与热门商品或促销商品相关联的商品,比如配套商品、互补商品等。用户在查看或购买目标商品时,可能也会对关联商品感兴趣。
预热的时机
- 活动开始前一段时间:例如提前1 - 2小时开始预热,既能保证缓存数据在活动开始时是新鲜有效的,又不会过早预热导致数据在活动开始前发生变化(对于变化频繁的数据,可采用定时更新缓存的方式)。
- 系统负载较低时:选择凌晨等系统业务量相对较少的时间段进行预热,避免预热操作对正常业务造成性能影响。
预热方式
- 批量查询预热:在后台通过数据库查询语句一次性获取需要预热的商品数据,然后将这些数据批量写入缓存。例如使用SQL语句
SELECT * FROM products WHERE product_id IN (热门商品ID列表)
获取数据,再通过缓存操作接口(如Redis的SET
命令)将数据存入缓存。 - 异步任务预热:将缓存预热操作封装成异步任务,利用消息队列(如RabbitMQ、Kafka等)来触发和管理这些任务。这样可以避免预热操作阻塞主线程,提高系统的响应性能。
- 分布式预热:如果系统是分布式架构,可以利用分布式缓存(如Redis Cluster),通过多个节点并行进行数据预热。每个节点负责一部分商品数据的预热,提高预热效率。
处理缓存不一致问题
- 缓存更新策略:
- 读写锁:在更新数据库数据时,获取写锁,禁止其他读操作,确保数据更新完成后再释放锁。读取数据时获取读锁,允许多个读操作并发进行。
- 先更新数据库,再更新缓存:在更新数据库成功后,立即更新缓存中的对应数据。但这种方式在并发情况下可能会出现缓存更新失败而数据库更新成功的情况,需要增加重试机制或补偿机制。
- 先删除缓存,再更新数据库:更新数据库前先删除缓存数据,这样下次读取时会从数据库重新加载最新数据到缓存。但这种方式在高并发场景下可能会出现数据库还未更新,缓存已被删除,导致脏数据读取的问题,可以通过设置缓存过期时间或使用延时双删策略(先删除缓存,更新数据库,过一段时间后再次删除缓存)来缓解。
- 缓存监控与补偿:
- 监控缓存状态:通过监控工具(如Prometheus + Grafana)实时监测缓存的命中率、缓存数据的一致性状态等指标。一旦发现缓存命中率异常下降或缓存数据与数据库数据不一致的情况,及时报警。
- 数据补偿:当发现缓存不一致问题时,可通过后台任务对不一致的数据进行重新同步。例如,从数据库中再次读取正确的数据并更新到缓存中。