是先修改数据库再删除缓存，还是先删除缓存再修改数据库?

场景一：如果先修改数据库再删除缓存。一个线程查询时，缓存失效重新拉数据后写入数据，另一个线程修改了数据。写入缓存后，缓存和数据库会出现不一致。

场景二：如果先删除缓存，后修改数据库。一个线程删除了缓存，修改数据库之前，另一个线程因为没有缓存，会重新拉取数据库数据，加入缓存。这时数据库修改后，缓存和数据库会出现不一致。

所以，先删除缓存还是先修改数据库，都会出现问题。这时，我们就需要采取一些措施来规避。

延时双删：延时双删是一个比较常见的处理方式。在数据库修改之前，首先先进行一次缓存删除，然后修改数据库。后面延时一段时间再删除一次缓存。这样极大程度可以处理大部分不一致问题。这个延时时间一般为500ms，可以根据数据库主从同步时间 + 一次读请求耗时来估算时间。同时为了防止阻塞业务，可以开启一个延时线程池来处理。

Binlog消息同步：可以通过Canal等CDC工具，监听binlog的数据发送给kafka，通过消费kafka的数据，来实现缓存同步。这种方式解耦，可以保证最终一致性。

加锁：可以利用set nx ex来实现原子操作的分布式锁，或者使用Redisson实现分布式锁，在操作前加锁，在同时处理数据库和缓存后解锁。保证操作同步。这种方式可以保证强一致性，但是性能低。

TCC：可以利用TCC柔性事务，保证数据库和缓存操作的原子性。这种方式也能保证强一致性，性能相对锁来说会好很多。但是代码复杂度比较高。

缓存的三种复杂的场景

缓存穿透：当查一个不存在的数据时，由于缓存中不存在，所以会直接访问数据库。如果这种请求会很多，那么会造成数据库的查询压力。

解决的方式有：

• 向缓存中插入一个null数据。下次同样的请求就可以直接返回null。这种实现比较简单，但是需要注意缓存不一致的问题。
• 利用布隆过滤器，通过hash计算出位置，存储在布隆过滤器中。这种方式实现比较复杂，而且容易出现误判。

缓存击穿：当某个key缓存失效时，同一时间，有大量请求过来，造成同时访问数据库，造成数据库压力。

解决的方式有：

• 加锁，保证查询时同一时间只有一个请求处理。这种方式虽然可以避免缓存击穿，但是性能差。
• 逻辑过期，不使用redis的过期机制，在缓存数据中加一个过期时间的字段。当执行查询时判断如果过期了，并不用直接去访问数据库，还是返回缓存中数据。而是开启新的线程，执行同步缓存请求。

缓存雪崩：当大量缓存数据失效或者redis宕机超时时，大量请求直接访问数据库，造成数据库压力。

解决的方式有：

• 给不同的Key的TTL添加随机值
• redis使用集群方式部署，保证高可用
• 增加多级缓存，但要同时考虑一致性问题

缓存过期

redis数据过期后，就会将数据从内存中清除。清除是根据一定的删除策略的（过期策略）。过期策略有惰性删除，定期删除。

• 惰性删除：当数据过期时，并不会立即删除，而是下一次对数据进行访问时，如果发现已经过期，那么将数据进行清除处理。优点是不需要大量的过期计算，对CPU友好。缺点是如果长时间不访问数据，会有大量的无用内存占用。
• 定期删除：每隔一段时间，我们就对一些key进行检查，删除里面过期的key(从一定数量的数据中取出一定数量的随机key进行检查，并删除其中的过期key)。优点是定期删除，也能有效释放过期键占用的内存。缺点是难以确定删除操作执行的时长和频率。

数据淘汰策略

当Redis中的内存不够用时，此时在向Redis中添加新的key，那么Redis就会按照某一种规则将内存中的数据删除掉，这种数据的删除规则被称之为内存的淘汰策略。一共有八种策略：

• noeviction： 不淘汰任何key，但是内存满时不允许写入新数据，默认就是这种策略
• volatile-ttl： 对设置了TTL的key，比较key的剩余TTL值，TTL越小越先被淘汰
• volatile-lru： 对设置了TTL的key，基于LRU算法进行淘汰
• volatile-lfu： 对设置了TTL的key，基于LFU算法进行淘汰
• volatile-random：对设置了TTL的key ，随机进行淘汰
• allkeys-lru： 对全体key，基于LRU算法进行淘汰
• allkeys-lfu： 对全体key，基于LFU算法进行淘汰
• allkeys-random：对全体key ，随机进行淘汰

LRU（Least Recently Used）最近最少使用。用当前时间减去最后一次访问时间，这个值越大则淘汰优先级越高

LFU（Least Frequently Used）最少频率使用。会统计每个key的访问频率，值越小淘汰优先级越高

使用场景：

• 优先使用 allkeys-lru 策略。充分利用 LRU 算法的优势，把最近最常访问的数据留在缓存中。如果业务有明显的冷热数据区分，建议使用。
• 如果业务中数据访问频率差别不大，没有明显冷热数据区分，建议使用 allkeys-random，随机选择淘汰。
• 如果业务中有置顶的需求，可以使用 volatile-lru 策略，同时置顶数据不设置过期时间，这些数据就一直不被删除，会淘汰其他设置过期时间的数据。
• 如果业务中有短时高频访问的数据，可以使用 allkeys-lfu 或 volatile-lfu 策略。

缓存持久化

Redis缓存是可以持久化的，其持久化的方式有RDB，AOF。

RDB是快照的方式，通过bgsave命令，fork主线程得到一个子线程，并共享主线程的数据。fork完数据后，子线程就会读取内存数据并且写入RDB文件。fork采用的copy on write技术。

AOF是追加日志的方式，默认是不开启的。开启后有三种追加方式，always，everysec，no。

• always：每次执行数据操作时，立即记录到AOF文件中。数据全，性能差。
• everysec：每次执行数据操作时，先写入缓冲区，然后每秒刷盘。可能会丢失1s内数据。
• no：每次执行数据操作时，先写入缓冲区，由操作系统决定何时刷盘。性能最好，但可靠性较差，可能丢失大量数据。

AOF文件过大怎么办？AOF文件会比RDB文件大的多。通过执行bgrewriteaof命令，可以让AOF文件执行重写功能，用最少的命令达到相同效果。

混合模式：是4.0以后的新方式，结合了RDB和AOF两种方式的优势。默认是关闭的，使用aof-use-rdb-preamble开启。AOF文件的开头会先写入RDB数据，然后在后面追加AOF记录。