1. 导致缓存与数据不一致的几个原因？
异常且无事物；并发读写。
2. 使用缓存时，先改数据库还是先改缓存？
(1) 先库后缓存，存在缓存更新失败导致数据不一致的问题(常规方案)。
(2) 先缓存再改库，增大了读写并发的数据库不一致问题的出现几率。T2删除缓存，T1读取旧数据，T2修改数据，T1将旧数据写入缓存。(这种方案在读取qps很高的情况下，很容易出现问题)。
3. 使用缓存时，修改完数据，直接更新缓存还是删除缓存？
(1) 简单值或不依赖其他操作的值 可以直接写入缓存(值一旦创建后不会发生修改或很少修改，可以使用这种方案)。
(2) 复杂值或依赖其他操作的值，应该直接删除缓存，等待读取线程的load。
4. 是否需要给缓存设置过期时间？
(1) 设置缓存过期时间是保证数据缓存最终一致性的有效方式。
(2) 大量的不活跃数据如果不过期的话会占用空间，使资源利用率低，甚至影响缓存读写性能。
(3) 尽量根据业务配置过期时间，可以使缓存在一个业务周期内有效，增加缓存命中率。
场景1：数据脏缓存
问题：
将数据加载到缓存的时候，在尚未缓存或者缓存失效的情况下，T2线程读取旧数据，T1线程修改数据，T1线程清除缓存，T2线程将旧数据写入缓存，导致了缓存不一致。
解决方案： 延迟双删
在修改数据后，进行清除缓存，再将缓存设置为为异步延时1秒后再删除。1秒内可能会出现旧数据，缓存命中率会受影响。删缓存 走主库查询 再写入缓存。可能影响接口性能。
场景2：大对象宽表缓存
问题：
有些平台对外提供大对象查询接口，一整份数据size很大，涉及到需要查询的表很多，甚至还需要跨平台查询数据，并且如果这个接口qps很高，接口性能就有可能不太理想。
解决方案：
对整份数据做缓存，对部分接口提供缓存数据查询，避免多表大量数据查询。经设计后，选用修改数据后删除缓存，读取时load到缓存的方案。
子问题：
如何保证数据一致性？
对于整份复杂类型的大数据，每一次查询几乎都需要10~20ms，并且高并发下，这就很容易产生脏缓存。
解决方案： 延迟缓存
为了保证数据一致性，采用对有修改的数据在一定时间内不信任的才做，即在修改后的一定时间，不将读出来的数据load到缓存，尽量规避读写并发产生的脏缓存。
场景3：分布式锁
问题：
部分接口需要保证幂等性。
解决方案：
利用redis setnx方法，实现简单的分布式锁，加在需要保证幂等性的接口上。
网友评论