面试题答案
一键面试缓存策略
- 缓存更新
- 读写后更新：在数据发生变更（写操作）时，先执行数据库的写操作，成功后立即更新缓存。这种方式实现简单，但在高并发场景下可能会出现短暂的数据不一致问题，因为写数据库和更新缓存并非原子操作。
- 读写前失效：写操作时，先删除缓存，再执行数据库写操作。这种策略能保证数据一致性，但在高并发读场景下，如果缓存失效期间大量读请求涌入，会导致缓存击穿，大量请求直接打到数据库。可以采用加互斥锁的方式来缓解该问题，即只允许一个请求去查询数据库并重建缓存，其他请求等待。
- 异步更新：写操作完成后，通过消息队列异步更新缓存。这种方式可以提高系统的响应速度，但同样会存在短暂的数据不一致问题，不过在电商产品详情页场景下，短暂的不一致通常是可以接受的。
- 缓存淘汰
- FIFO（先进先出）：优先淘汰最早进入缓存的数据。适用于数据实效性要求不高，且缓存空间有限的场景。例如对于一些不常更新且访问频率相对稳定的产品详情数据。
- LRU（最近最少使用）：淘汰最长时间未被使用的数据。该策略基于局部性原理，认为最近使用过的数据在未来也更可能被使用。在电商场景中，如果产品详情页的访问具有一定的时间局部性，LRU 能有效保证热点数据留在缓存中。
- LFU（最不经常使用）：淘汰一定时间内使用频率最低的数据。对于电商平台上一些小众、冷门产品的详情页缓存，LFU 能更好地将缓存空间留给访问频率高的热门产品。
消息队列的作用
- 削峰填谷：在高并发读请求到来时，消息队列可以作为一个缓冲区，接收大量的读请求。系统按照自身的处理能力，从消息队列中逐步取出请求并处理，避免因瞬间高并发读请求导致系统崩溃。例如在电商大促期间，产品详情页的读请求量可能会瞬间暴增，消息队列可以将这些请求暂存起来，使系统平稳处理。
- 异步处理：结合缓存更新策略中的异步更新方式，写操作完成后将更新缓存的任务发送到消息队列。消息队列异步处理这些任务，从而不影响主业务流程的响应速度。例如，当商家修改了产品详情后，写操作完成即返回成功响应给商家，而更新缓存的操作通过消息队列异步执行。
- 数据解耦：将读请求处理与其他系统模块解耦。即使下游的缓存服务或数据库服务出现短暂故障，消息队列中的请求也不会丢失，待服务恢复后可继续处理。比如缓存服务器进行维护时，读请求依然可以被消息队列接收，维护完成后继续处理队列中的请求，保证系统的高可用性。