一、数据一致性问题
如果缓存里的数据和数据库里的数据不一致，那么应用程序从缓存读取的数据是一个错误的数据。
1、新增数据的一致性问题
如果有业务需要在新增数据时，写入redis和mysql，可以使用消息中间件推送给redis或mysql，这样即使出现消费失败也可以自动重发，从而避免数据不一致问题。所以新增数据的不一致性很少发生。
2、修改/删除的一致性问题
在修改数据时，比较容易出现数据不一致问题。基本的修改数据方法有以下几种：
1、先更新数据库，后更新缓存。
2、先更新缓存，后更新数据库。
3、先更新数据库，后删除缓存。
4、先删除缓存，后更新数据库。
3、更新数据库和缓存
4、先删除缓存，后更新数据库
5、先更新数据库，后删除缓存
根据更新数据的流程图可知：线程在执行更新操作时，无法保证执行的先后顺序，比较容易出现数据不一致问题。
但是出现数据不一致问题概率不高，由于一般情况下更新数据库的耗时要多于查询数据库，所以出现上图的情况很少。推荐使用。
二、延迟双删
这时我们该怎么办呢？
有一个方法是先删除缓存，更新完数据库以后，再删除一次缓存。这样下一个线程读取的时候判断缓存为空，就到数据库读取数据并且更新缓存。这种方法叫延迟双删。
为什么要延迟？
为了确保其他已读取到数据库旧数据但是没写入redis缓存的线程执行完成了。
// 先删除缓存
redis.del(key);// 更新数据库
dataBase.update();// 等待1000ms
Thread.sleep(1000);// 再删除缓存
redis.del(key);1、数据库读写分离时的延迟双删
在一些项目中可能会遇到数据库是读写分离架构，在对主库写入数据后，从库要同步这些数据，这个过程需要消耗一定的时间。所以如果使用延迟双删的方案，需要等待从库同步完数据后，再做第二次删除缓存。所以Thread.sleep需要延长等待时间。
如果不想延长线程睡眠时间，那么可以让读数据库的操作从主库读取数据。这样不必等待从库同步完数据。
2、延迟双删的缺点
由于延迟双删的机制是等待一定的时间后再执行，这样无端延长了线程的执行时间，降低响应速度。
解决办法也有，可以使用异步操作实现延迟双删，比如启动一个子线程等待1000ms，或者使用rocketMQ的延迟消息。这样对主线程的响应速度没影响。
3、异步延迟双删
可以使用RocketMQ的延迟消息功能，异步实现删除Redis缓存。
4、消息中间件的异步延迟双删的缺点
如果原本系统中没加入消息中间件，为了数据一致性加一个消息中间件，代价比较大。
5、订阅binlog：canal
canal是阿里提供的异步双删的组件，不用自己再开发。
三、缓存穿透
1、概念
进入系统的请求去查询不存在的数据，先到redis没查到，又到数据库也没查到。大量这样的请求会给数据库造成很大的压力。
2、解决方案
① 缓存空值
如果redis缓存没查到数据，数据库也没查到数据，就向redis放一个value为null的数据，这样相同的请求再进来的时候就可以从redis中获取一个null，避免数据库压力过大。
② 布隆过滤器
redis提供一个数据类型是：bitMap，底层是一个二进制数组，可以记录某些key。
当过来一个key的时候，使用布隆过滤器计算是否属于这个集合，如果不属于就返回null，避免请求进入数据库。
四、缓存击穿
1、概念
热点key过期的瞬间，大量的请求同时涌入数据库，压垮数据库。
2、解决方案
① 针对热点key，不设置过期时间。
② 加入分布式锁，只允许一个请求进入数据库，其他请求等待缓存恢复。
/*** 防止缓存击穿的代码写法** @Author: AllWe* @Date: 2024/09/06/11:19*/
@Slf4j
@Component
public class GetValue {@Resourceprivate JedisPool jedisPool;@Resourceprivate DataBaseTest dataBaseTest;private static final String LUA = "return redis.call('SET', KEYS[1], ARGV[1], 'EX', ARGV[2], 'NX')";private static final Long EXPIRE_TIME = 300L;private String getValue(String key) {Jedis jedis = null;String value = null;try {jedis = jedisPool.getResource();value = jedis.get(key);// 如果查询结果为空 - 缓存过期if (StrUtil.isBlank(value)) {// 注意这里加入一个互斥操作,使用了NX参数,确保只有一个线程进入数据库查询,将查询结果放回缓存if("OK".equals(jedis.eval(LUA, Collections.singletonList("key_mutext"), Arrays.asList("1", "180")))) {value = dataBaseTest.get(key);jedis.setex(key, EXPIRE_TIME, value);jedis.del("key_mutext");} else {// 等待进入数据库查询的线程将数据放入缓存 - 50msThread.sleep(50);// 再次从缓存取数据value = jedis.get(key);}}} catch (Exception e) {log.info("查询异常!");}return value;}
}五、缓存雪崩 - stampeding herd
1、概念
redis中大量的缓存失效，导致大量的请求需要直接访问数据库。缓存这一层基本崩溃了。
2、解决方案
错开缓存的失效时间，避免同一时刻失效，可以加一个随机过期时间。
六、服务降级
在并发特别高的时候，可以关掉一些不重要的功能，将资源让给重要的功能。
七、数据倾斜问题 - 热点key问题
1、产生原因
在一个应用程序中，有大量的请求去访问个别的几个key，导致只有少量的redis节点去处理这些请求，而其他的节点没参与运算。造成访问倾斜，运算压力不平衡。
比如微博因为某某明星结婚导致请求集中，扛不住压力崩溃。
2、危害
请求太多会占满某一台redis服务器的带宽。
可能导致缓存穿透、击穿、雪崩等情况。
建议：单台redis节点存储的数据量别太大，最好别超过8GB，否则在主从架构中同步数据压力会很大。
3、发现热点key
在电商平台可以对一些商品做预估，提前准备一些热点key。
但是对于社交平台，比如微博，无法预测会出现哪些热点数据，这时候该怎么办呢？
① 客户端使用 concurrentHashMap
在应用程序代码中记录key的访问次数，每访问一次value +1，提前设定阈值 = 100W，到达阈值的判定为热点key。
优点：实现简单。
缺点：
1、对业务程序侵入大。
2、如果有其他程序共享了相同redis数据库的相同key，这时也需要在其他程序中维护相同的功能，开发成本高。
3、如果记录的key数量很多，会导致concurrentHashMap很大，占用内存太多。
② Redis 的 monitor 命令
使用monitor命令可以实现对redis中的所有命令监控，通过监控到的历史命令获取热点key。
redis-faina就是使用monitor实现对redis的分析。
优点：可以不侵入业务代码的方式获取热点key。
缺点：
1、给了redis一个额外的任务，造成了额外的开销，redis性能下降。
2、针对redis集群，需要额外的汇总工作。
3、适合短时间内监控redis数据的走向，给开发人员提供一些信息，用完再关闭。
③ Redis 的 hotkeys
在4.0.3版本之后发布，专门统计热点key。
# 查询redis热点key
./redis.cli --hotkeys缺点：
1、不能按自定义规则查询热点key，只能按redis默认的规则查询。
2、是一个全局命令，会把所有的key扫描出来，最后再汇总。如果key的数量很多，会很消耗redis性能。
④ 抓取TCP的包
在redis的服务器上面抓取TCP的包，实现对热点key的统计。
优点：不侵入应用程序。
缺点：
1、开发、学习成本高：ES -> ELK体系提供了packetbeat插件，实现了对redis数据的分析。
2、可能导致服务器网络波动，有丢包的可能。
3、维护成本高。
4、解决热点key
1、使用二级缓存，使用Guava-cache，Hcache，JVM对象等方式将热点数据保存到内存中，不必再通过网络访问redis服务，提升响应速度。
2、分散热点key的热度。1拆分热点key的数据，可以将一个热点key拆分成多个子key，如果是集群就分散存储到不同的redis节点上，这样每个子key只分担了原来一小部分的请求。
八、数据倾斜问题 - bigKey问题
1、概念
某个key对应的value值太大，超出预设的阈值，就认为这个key是bigKey。一般有两个分类：
String：占用空间达到阈值。
非String：hash、list、set、zset，元素数量到达阈值。
value值太大或元素太多在进行操作的时候时间复杂度会很高。
2、危害
造成数据量倾斜，使每个节点的负载不同。
redis内部是单线程执行，在操作bigKey的时候阻塞时间太长，可能导致请求超时。
网络拥塞。如果一个key是bigKey的同时还是一个热点key，这时每秒响应的数据量太大，造成网络拥塞。
3、发现bigKey
① redis全局命令
redis-cli --bigkeys全局扫描，效率低下，不推荐使用。
不能按自定义阈值做判断。
② debug 命令
debug object 'key'
通过debug命令可以读取到指定key对应的value详细信息，比对serializedlength参数的值可以获取value的长度，如果超出定义的阈值就在应用程序中标记为bigKey。
优点：可以按自定义阈值判断哪些key是bigKey。
缺点：必须先知道要查询哪个key。
③ scan 命令
# scan cursor MATCH pattern COUNT countscan 0 count 5
渐进式扫描。
scan命令支持分页扫描key，避免了keys * 的全局扫描，对redis缓存的性能消耗比较小。
优点：结合scan命令和debug命令发现bigKey的好处是避免了全局扫描，也支持自定义阈值设置。
缺点：由于每一次scan是独立执行的，在这个过程中如果新增了新的key，是不会扫描到的，导致最终的结果不是精确的。
当精度缺失在可以容忍的范围内时，如果有主从架构，可以在从节点上做这样的数据分析工作，不去影响主节点的工作性能。
4、解决bigKey
拆分：将一个bigKey的value分散到不同的key上，分散存储压力。
九、脑裂问题
在主从-哨兵架构下，由于网络波动，可能出现主节点掉线后，哨兵节点从从节点中选举出来两个主节点，这时称为脑裂问题。
redis如何解决脑裂问题？在conf配置文件中配置相关参数可以减少脑裂问题的发生。
min-replicas-to-write 3：最小副本写入数量。
min-replicas-max-lag 10：最小副本范围内最大延迟时间。
说人话：当一个应用程序向redis集群中写入数据时，要求最少向3台redis节点写入成功，且这三台redis节点写入的延迟不超过10s。否则，写入失败。
基于CAP理论，在分布式系统中，不可能完全杜绝脑裂问题的发生。
但是在redis-cluster中可以通过修改配置文件参数：cluster-require-full-coverage yes 来开启集群保护机制，使得当一个分配了槽位的主节点掉线时集群进入保护状态，整个集群不可用，不会再写入新数据，从而减少脑裂问题。
而且在搭建redis集群的时候要求主节点数量尽量是奇数，且最少节点数是3，进一步减少脑裂问题。