共计 2445 个字符，预计需要花费 7 分钟才能阅读完成。
Redis 常常用于零碎中的缓存（MySQL 与 Redis 缓存的同步计划），这样能够解决目前 IO 设施无奈满足互联网利用海量的读写申请的问题。
一、缓存穿透
缓存穿透是指缓存和数据库中都没有的数据，而用户一直发动申请，如发动 id 为 - 1 的数据或者特地大的不存在的数据。有可能是黑客利用破绽攻打从而去压垮利用的数据库。
1. 常见解决方案
对于缓存穿透问题，常见的解决方案有以下三种：
- 验证拦挡：接口层进行校验，如鉴定用户权限，对 ID 之类的字段做根底的校验，如 id<= 0 的字段间接拦挡；
- 缓存空数据：当数据库查问到的数据为空时，也将这条数据进行缓存，但缓存的有效性设置得要较短，免得影响失常数据的缓存；
public Student getStudentsByID(Long id) {
// 从 Redis 中获取学生信息
Student student = redisTemplate.opsForValue()
.get(String.valueOf(id));
if (student != null) {return student;}
// 从数据库查问学生信息，并存入 Redis
student = studentDao.selectByStudentId(id);
if (student != null) {redisTemplate.opsForValue()
.set(String.valueOf(id), student, 60, TimeUnit.MINUTES);
} else {
// 即便不存在，也将其存入缓存中
redisTemplate.opsForValue()
.set(String.valueOf(id), null, 60, TimeUnit.SECONDS);
}
return student;
}
- 应用布隆过滤器：布隆过滤器是一种比拟独特数据结构，有肯定的误差。当它指定一个数据存在时，它不肯定存在，然而当它指定一个数据不存在时，那么它肯定是不存在的。
2. 布隆过滤器
布隆过滤器是一种比拟非凡的数据结构，有点相似与 HashMap，在业务中咱们可能会通过应用 HashMap 来判断一个值是否存在，它能够在 O(1)工夫复杂度内返回后果，效率极高，然而受限于存储容量，如果可能须要去判断的值超过亿级别，那么 HashMap 所占的内存就很可观了。
而 BloomFilter 解决这个问题的计划很简略。首先用多个 bit 位去代替 HashMap 中的数组，这样的话贮存空间就下来了，之后就是对 Key 进行屡次哈希，将 Key 哈希后的值所对应的 bit 地位为 1。
当判断一个元素是否存在时，就去判断这个值哈希进去的比特位是否都为 1，如果都为 1，那么可能存在，也可能不存在（如下图 F）。然而如果有一个 bit 位不为 1，那么这个 Key 就必定不存在。
留神：BloomFilter 并不反对删除操作，只反对增加操作。这一点很容易了解，因为你如果要删除数据，就得将对应的 bit 地位为 0，然而你这个 Key 对应的 bit 位可能其余的 Key 也对应着。
3. 缓存空数据与布隆过滤器的比拟
上面对这两种计划都进行了简略的介绍，缓存空数据与布隆过滤器都能无效解决缓存穿透问题，但应用场景有着些许不同；
- 当一些歹意攻打查问查问的 key 各不相同，而且数量巨多，此时缓存空数据不是一个好的解决方案。因为它须要存储所有的 Key，内存空间占用高。并且在这种状况下，很多 key 可能只用一次，所以存储下来没有意义。所以对于这种状况而言，应用布隆过滤器是个不错的抉择；
- 而对与空数据的 Key 数量无限、Key 反复申请效率较高的场景而言，能够抉择缓存空数据的计划。
二、缓存击穿
缓存击穿是指以后热点数据存储到期时，多个线程同时并发拜访热点数据。因为缓存刚过期，所有并发申请都会到数据库中查问数据。
解决方案
- 将热点数据设置为永不过期；
- 加互斥锁：互斥锁能够管制查询数据库的线程拜访，但这种计划会导致系统的吞吐量降落，须要依据理论状况应用。
public String get(key) {String value = redis.get(key);
if (value == null) { // 代表缓存值过期
// 设置 3min 的超时，避免 del 操作失败的时候，下次缓存过期始终不能 load db
if (redis.setnx(key_mutex, 1, 3 * 60) == 1) { // 代表设置胜利
value = db.get(key);
redis.set(key, value, expire_secs);
redis.del(key_mutex);
} else { // 这个时候代表同时候的其余线程曾经 load db 并回设到缓存了，这时候重试获取缓存值即可
sleep(50);
get(key); // 重试
}
} else {return value;}
}三、缓存雪崩
缓存雪崩产生有几种状况，比方大量缓存集中在或者缓存同时在大范畴中生效，呈现了大量申请去拜访数据库，从而导致 CPU 和内存过载，甚至停机。
一个简略的雪崩过程：
- Redis 集群产生了大面积故障；
- 缓存失败，此时仍有大量申请去拜访 Redis 缓存服务器；
- 在大量 Redis 申请失败后，这些申请将会去拜访数据库；
- 因为利用的设计依赖于数据库和 Redis 服务，很快就会造成服务器集群的雪崩，最终导致整个零碎的瘫痪。
解决方案
【事先】高可用缓存：高可用缓存是防止出现整个缓存故障。即便个别节点，机器甚至机房都敞开，零碎依然能够提供服务，Redis 哨兵(Sentinel) 和 Redis 集群(Cluster) 都能够做到高可用；
【事中】缓存降级（长期反对）：当拜访次数急剧减少导致服务呈现问题时，咱们如何确保服务依然可用。在国内应用比拟多的是 Hystrix，它通过熔断、降级、限流三个伎俩来升高雪崩产生后的损失。只有确保数据库不死，零碎总能够响应申请，每年的春节 12306 咱们不都是这么过去的吗？只有还能够响应起码还有抢到票的机会；
【预先】Redis 备份和疾速预热：Redis 数据备份和复原、疾速缓存预热。
作者：周二鸭
起源：https://www.cnblogs.com/jojop…
