面试题答案
一键面试1. 缓存更新策略
- 写后失效（Write - After - Invalidate）：在数据更新后，立即失效相关分片的缓存数据。例如，在电商系统中更新商品价格后，将该商品价格对应的缓存分片标记为无效，下次请求该数据时，缓存发现失效，从数据源重新读取并更新缓存。优点是实现简单，缺点是在缓存失效到重新加载期间，可能读到旧数据。
- 写前失效（Write - Before - Invalidate）：在数据更新前，先失效相关缓存分片。如在更新数据库中用户信息前，先删除该用户信息对应的缓存分片。这种方式能减少读取旧数据的概率，但如果更新操作失败，缓存已失效，可能导致一段时间内数据不可用。
- 写时更新（Write - Through）：当数据更新时，同时更新数据库和相关缓存分片。以订单系统为例，订单状态更新时，数据库和缓存中订单状态的对应分片同时更新。优点是能保证数据强一致性，但性能可能受影响，因为涉及两次写操作。
- 异步写后更新（Asynchronous Write - After - Update）：数据更新数据库后，通过异步任务更新缓存分片。比如在日志系统中，记录新日志到数据库后，通过消息队列异步通知更新缓存。优点是不影响主业务流程性能，但可能存在短暂的数据不一致。
2. 一致性哈希算法
- 基本原理：将整个哈希值空间组织成一个虚拟的圆环，即哈希环。节点和数据都通过哈希函数映射到这个环上。当有新节点加入或旧节点离开时，受影响的数据是该节点到其顺时针方向的下一个节点之间的数据，其他数据不受影响。例如，有节点A、B、C在哈希环上，数据D根据哈希值落在A和B之间，由节点B负责存储。若节点C加入，重新计算哈希后，只有部分原本由B存储的数据可能会被分配给C，其他数据仍由原节点存储。
- 优点：能较好地应对节点动态变化，减少数据迁移量，提高系统扩展性，适用于大规模分布式缓存场景。
3. 分布式锁机制
- 基于数据库锁：利用数据库的锁机制，如行锁、表锁。在更新缓存数据前，先获取数据库锁。例如，在库存管理系统中，更新库存缓存前，通过数据库语句锁定库存记录，防止其他进程同时更新缓存，保证缓存一致性。但性能较低，不适合高并发场景。
- 基于Redis的分布式锁：使用Redis的SETNX（SET if Not eXists）命令实现分布式锁。在更新缓存前，尝试在Redis中设置一个特定的键值对表示获取锁。如在秒杀系统中，多个请求尝试获取锁，只有成功设置键值对的请求能更新缓存，其他请求等待或重试。优点是性能较高，但需处理锁的过期时间、锁的续租等问题。
- 基于Zookeeper的分布式锁：利用Zookeeper的临时顺序节点特性。每个请求在Zookeeper中创建一个临时顺序节点，最小序号的节点获得锁。在文件系统缓存更新场景中，通过Zookeeper协调各节点对缓存更新的顺序，保证一致性。优点是可靠性高，能自动处理节点故障，但实现相对复杂。
4. 版本控制
- 数据版本号：为每个数据分片维护一个版本号。当数据更新时，版本号递增。缓存读取数据时，同时读取版本号并与缓存中的版本号比较。如在内容管理系统中，文章数据每次更新，版本号加1，缓存读取文章时，若版本号不一致，则从数据源重新获取最新数据并更新缓存。
- 时间戳：记录数据的最后更新时间戳。缓存读取数据时，对比时间戳，若数据源时间戳更新，则更新缓存。在日志记录系统中，通过时间戳判断缓存中的日志数据是否为最新，及时更新缓存。