1、缓存

1.1、穿透

查询一个空数据，mysql也查不到也不会写入缓存可能导致多次请求数据库

方案一：缓存设空即可（可能发生数据不一致就是这条数据有了但此时缓存是空，消耗内存）

方案二：布隆过滤器（实现复杂，容易产生误判）

1.2、击穿

一个key缓存过期重建过程中来了大量请求，缓存无数据全来到了数据库

方案一：互斥锁（强一致、性能差、一个线程进来其他线程都得等待）

方案二：逻辑过期（高可用、性能优、不能保证数据一致性）

添加逻辑过期expire字段：

1.3、雪崩

同一时段大量key失效或redis宕机，导致大量请求来到数据库

方案一：给不同的key的TTL添加随机值

方案二：利用redis集群提高可用性（哨兵模式、集群模式）

方案三：缓存业务添加降级限流策略（nginx、gateway）

方案四：给添加多级缓存（Guava或Caffeine）

1.4、双写一致（mysql数据与redis同步）

当修改了数据库的数据，同时也要更新缓存的数据，缓存要与数据库数据保持一致

读操作：缓存命中直接返回、未命中查询数据库写入缓存设置超时时间

写操作：延时双删（删除缓存–>修改数据库–>删除缓存）（双删防止脏数据、延时为了让主从模式把数据同步到从节点，延时过程中可能出现脏数据不能保证强一致性）

分布式锁（强一致性）：

1. 共享锁：读锁readLock，加锁过后其他线程共享读操作

2. 排他锁：独占锁writeLock，加锁过后阻塞其他线程读写操作，底层setnx保证同一时刻只能一个线程操作锁住的方法

1.5、持久化

1.5.1、RDB

Redis Database Backup file（redis数据备份文件、数据快照）把内存所有数据存到磁盘，当redis故障重启后从磁盘快速读取快照文件恢复数据：命令1、save2、bgsave（子进程），redis.config也可设置自动备份策略（bgsave）

1.5.2、AOF

Append Only File（追加文件）redis处理的每一个写命令都会记录在AOF文件，可以看作命令日志文件，AOF默认关闭，在redis.config配置文件把appendonly的值改为yes也可修改AOF文件的名称

由于AOF是记录命令，文件要比RDB大得多。且AOF会记录同一个key的多次写操作，但实际上只有最后一次才有意义。通过bgrewriteaof命令重写。也可在配置文件设置重写阈值。

对比：

1.6、数据过期策略

1. 惰性删除：该key过期后不管它，当需要该key后检查是否过期，若过期就删掉，反之返回该key（对cpu友好，对内存不友好存在大量用不到的key一直占内存）
2. 定期删除：每隔一段时间检查一定量的key，删除其中过期的key（SLOW、FAST）

==》redis默认两种策略配合使用

1.7、淘汰策略

当redis的内存不够用，此时再添加key那么redis会按照某一逻辑将内存中的数据删除掉

面试：数据库1000万数据，redis只能存20万，如何保证redis的数据都是热点数据？（LRU）

2、集群

2.1、主从

1. 主从全量同步：

2. 主从增量同步：

2.2、哨兵

实现主从集群的自动故障修复（监控、恢复、通知）

1秒一个ping，哨兵选主（slave-priority越小优先级越高，offset越大，优先级越高）

脑裂：由于网络波动，发现ping不了master，之后选了个slave作为master，这就出现了两个master，但client还是向老master写数据，老master网络恢复后，无新增数据的新master把自个数据同步到老master，那么就丢失了此段时间的数据。更改配置文件解决：

2.3、分片集群

多个master集群，每个master数据不同，一个master有多个slave，master之间通过ping相互心跳检测

解决海量数据存储问题、高并发写的问题

redis分片引入了哈希槽的概念，redis集群有16384个哈希槽，每个key通过 CRC16 hash校验后对16384取模来决定放置在那个槽，集群每个节点负责一部分hash槽

3、分布式锁

本地锁只对本地起作用，因为jvm限制

3.1、setnx

添加锁：SET lock value NX EX 10（过期时间防止死锁业务超时或服务宕机会自动释放锁）

释放锁：DEL key

控制锁时长：1.根据业务执行时间预估（不推荐）2.给锁续期（redisson）

3.2、redisson

执行流程，新特性重试机制高并发下增加分布式锁的使用性能

基于Lua脚本保证命令执行原子性

可重入：跟据线程id判断，add1与add2属于同一线程所以add2会获取到锁

利用hash结构记录线程id和重入次数

主从一致性：当获取锁业务没结束后突然redis主节点（写、改、删数据）宕机，数据没来得及同步到子节点（读数据），那么集群默认选出一个子节点当作主节点替换掉宕机的，当另一个请求获取锁也是能够获取成功的这样两个线程公用一把锁就丧失了锁的互斥性，可能出现脏数据，方案：RedLock（红锁）（复杂、性能差）