缓存雪崩产生的原因
由于原有缓存失效（或者数据未加载到缓存中），新缓存未到期间（缓存正常从 Redis中获取，如下图）所有原本应该访问缓存的请求都去查询数据库了，而对数据库CPU和内存造成巨大压力，严重的会造成数据库宕机，造成系统的崩溃。
通俗理解：在某一时刻大量的key过期，但有大量的请求进来，因为这些key过期了，大量的请求全都去查询数据库，可能导致DB崩掉。
缓存失效的时候如下图：
解决方案:
① 使用锁或队列：在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存，其他线程等待。虽然能够在一定的程度上缓解了数据库的压力但是与此同时又降低了系统的吞吐量。
public Users getByUsers(Long id) {
// 1.先查询redis
String key = this.getClass().getName() + “-” +
Thread.currentThread().getStackTrace()[1].getMethodName() + “-id:” + id;
String userJson = redisService.getString(key);
if (!StringUtils.isEmpty(userJson)) {
Users users = JSONObject.parseObject(userJson, Users.class);
return users;
}
Users user = null;
try {
lock.lock(); // 查询db
user = userMapper.getUser(id);
redisService.setSet(key, JSONObject.toJSONString(user));
} catch (Exception e) {
}
finally {
lock.unlock();
// 释放锁
}
return user;
}注意：加锁排队只是为了减轻数据库的压力，并没有提高系统吞吐量。假设在高并发下，缓存重建期间key是锁着的，这是过来1000个请求999个都在阻塞的。同样会导致用户等待超时，这是个治标不治本的方法。
② 过期时间给随机值(常用)：分析用户的行为，不同的key，设置不同、随机的过期时间，让缓存失效的时间点尽量均匀，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。
③ 构建多级缓存架构：nginx缓存 + redis缓存 +其他缓存（ehcache等）
2. 缓存穿透
缓存穿透是指用户查询数据，在数据库没有，自然在缓存中也不会有。这样就导致用户查询的时候，在缓存中找不到，每次都要去数据库再查询一遍，然后返回空。这样请求就绕过缓存直接查数据库，这也是经常提的缓存命中率问题。
通俗理解：指查询一个不存在的key，但redis没有将null值写入缓存，导致所有的请求全去查询数据库，大量请求进来DB有可能崩掉。
解决方案:
① 如果查询数据库也为空，直接设置一个默认值存放到缓存，这样第二次到缓冲中获取就有值了，而不会继续访问数据库，这种办法最简单粗暴。
② 把空结果，也给缓存起来，这样下次同样的请求就可以直接返回空了，既可以避免当查询的值为空时引起的缓存穿透。同时也可以单独设置个缓存区域存储空值，对要查询的key进行预先校验，然后再放行给后面的正常缓存处理逻辑。
public String getByUsers2(Long id) {
// 1.先查询redis
String key = this.getClass().getName() + “-” +
Thread.currentThread().getStackTrace() [1].getMethodName()+ “-id:” + id;
String userName = redisService.getString(key);
if (!StringUtils.isEmpty(userName)) {
return userName;
}
System.out.println(“######开始发送数据库DB请求########”);
Users user = userMapper.getUser(id);
String value = null;
if (user == null) {
// 标识为null
value = “”;
} else {
value = user.getName();
}
redisService.setString(key, value);
return value;
}注意：再给对应的ip存放真值的时候，需要先清除对应的之前的空缓存。
3. 缓存击穿
对于一些设置了过期时间的key，如果这些key可能会在某些时间点被超高并发地访问，是一种非常“热点”的数据。这个时候，需要考虑一个问题：缓存被“击穿”的问题，这个和缓存雪崩的区别在于这里针对某一key缓存，前者则是很多key。
通俗理解：有一个热点key突然过期，这时大量请求进来全部去查询数据库，可能导致数据库崩掉。
热点key:
某个key访问非常频繁，当key失效的时候有大量线程来构建缓存，导致负载增加，系统崩溃。
解决办法：
① 使用锁：单机用synchronized,lock等，分布式用分布式锁。
② 实时调整：缓存过期时间不设置，而是设置在key对应的value里。如果检测到存的时间超过过期时间则异步更新缓存。
③ 预先设置热门数据： 在redis高峰访问之前，把一些热门数据提前存入到redis里面，加大这些热门数据key的时长
分布式锁：
使用分布式锁要满足的几个条件：
- 系统是一个分布式系统（关键是分布式，单机的可以使用ReentrantLock或者synchronized代码块来实现）
- 共享资源（各个系统访问同一个资源，资源的载体可能是传统关系型数据库或者NoSQL）
- 同步访问（即有很多个进程同时访问同一个共享资源。）
什么是分布式锁？
① 线程锁：主要用来给方法、代码块加锁。当某个方法或代码使用锁，在同一时刻仅有一个线程执行该方法或该代码段。线程锁只在同JVM中有效果，因为线程锁的实现在根本上是依靠线程之间共享内存实现的，比如synchronized是共享对象头，显示锁Lock是共享某个变量（state）。
② 进程锁：为了控制同一操作系统中多个进程访问某个共享资源，因为进程具有独立性，各个进程无法访问其他进程的资源，因此无法通过synchronized等线程锁实现进程锁。
③ 分布式锁：当多个进程不在同一个系统中，用分布式锁控制多个进程对资源的访问。
应用的场景
线程间并发问题和进程间并发问题都是可以通过分布式锁解决的，但是强烈不建议这样做！因为采用分布式锁解决这些小问题是非常消耗资源的！分布式锁应该用来解决分布式情况下的多进程并发问题才是最合适的。
有这样一个情境，线程A和线程B都共享某个变量X。
如果是单机情况下（单JVM），线程之间共享内存，只要使用线程锁就可以解决并发问题。
如果是分布式情况下（多JVM），线程A和线程B很可能不是在同一JVM中，这样线程锁就无法起到作用了，这时候就要用到分布式锁来解决。
分布式锁可以基于很多种方式实现，比如zookeeper、redis… 不管哪种方式，他的基本原理是不变的：用一个状态值表示锁，对锁的占用和释放通过状态值来标识。
这里主要讲如何用redis实现分布式锁。
使用redis的setNX命令实现分布式锁
实现的原理
Redis为单进程单线程模式，采用队列模式将并发访问变成串行访问，且多客户端对Redis的连接并不存在竞争关系。redis的SETNX命令可以方便的实现分布式锁。
2、基本命令解析
1）setNX（SET if Not eXists）
语法：
SETNX key value
将 key 的值设为 value ，当且仅当 key 不存在。
若给定的 key 已经存在，则 SETNX 不做任何动作。
SETNX 是『SET if Not eXists』(如果不存在，则 SET)的简写
返回值：
设置成功，返回 1 。
设置失败，返回 0 。
例子：
redis> EXISTS job # job 不存在
(integer) 0
redis> SETNX job “programmer” # job 设置成功
(integer) 1
redis> SETNX job “code-farmer” # 尝试覆盖 job ，失败
(integer) 0
redis> GET job # 没有被覆盖
“programmer”所以我们使用执行下面的命令SETNX可以用作加锁原语(locking primitive)。比如说，要对关键字(key) foo 加锁，
客户端可以尝试以下方式：
SETNX lock.foo <current Unix time + lock timeout + 1>
如果 SETNX返回 1 ，说明客户端已经获得了锁，SETNX将键 lock.foo 的值设置为锁的超时时间（当前时间 + 锁
的有效时间）。 之后客户端可以通过 DEL lock.foo 来释放锁。
如果 SETNX返回 0 ，说明 key 已经被其他客户端上锁了。如果锁是非阻塞(non blocking lock)的，我们可以选
择返回调用，或者进入一个重试循环，直到成功获得锁或重试超时(timeout)。
2）getSET
