Redis应用问题解决

应用问题解决

1.1 缓存穿透（访问不到）

概念

在默认情况下，用户请求数据时，会先在缓存(Redis)中查找，若没找到即缓存未命中，再在数据库中进行查找，数量少可能问题不大，可是一旦大量的请求数据（例如秒杀场景）缓存都没有命中的话，就会全部转移到数据库上，造成数据库极大的压力，就有可能导致数据库崩溃。网络安全中也有人恶意使用这种手段进行攻击被称为洪水攻击。

解决方案

1.对空值缓存

如果一个查询返回结果为空，我们仍然把这个空值进行缓存，设置空结果过期时间很短，一般不超过五分钟

2.设置可访问白名单

使用bitmaps定义一个白名单，名单id作为bitmaps的偏移量，每次访问和bitmap中的id进行比对，如果id不存在bitmap中，则拦截改访问

3==布隆过滤器==

对所有可能查询的参数以Hash的形式存储，以便快速确定是否存在这个值，在控制层先进行拦截校验，校验不通过直接打回，减轻了存储系统的压力。

4.进行实时监控

当redis命中率急剧下降时，开始排查访问对象和数据，设置黑名单限制访问

---

2.1 缓存击穿（访问量大，缓存过期）

概念

相较于缓存穿透，缓存击穿的目的性更强，redis中某个key过期了，但是突然大量访问这个key，造成数据库压力骤增，这就是缓存被击穿，只是针对其中某个key的缓存不可用而导致击穿，但是其他的key依然可以使用缓存响应。

比如热搜排行上，一个热点新闻被同时大量访问就可能导致缓存击穿。

解决方案

设置热点数据永不过期

这样就不会出现热点数据过期的情况，但是当Redis内存空间满的时候也会清理部分数据，而且此种方案会占用空间，一旦热点数据多了起来，就会占用部分空间。

加互斥锁(分布式锁)

在访问key之前，采用SETNX（set if not exists）来设置另一个短期key来锁住当前key的访问，访问结束再删除该短期key。保证同时刻只有一个线程访问。这样对锁的要求就十分高。

---

3.1 缓存雪崩（大量key过期）

概念

大量的key设置了相同的过期时间，导致在缓存在同一时刻全部失效，造成瞬时DB请求量大、压力骤增，引起雪崩。

解决方案

多级缓存架构

nginx缓存+redis缓存+其他缓存

使用锁或者队列

通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存，其他线程等待。

数据预热

数据加热的含义就是在正式部署之前，我先把可能的数据先预先访问一遍，这样部分可能大量访问的数据就会加载到缓存中。在即将发生大并发访问前手动触发加载缓存不同的key，设置不同的过期时间，让缓存失效的时间点尽量均匀。

---

4.1 分布式锁

概念

1.线程锁

主要用来给方法、代码块加锁。当某个方法或代码使用锁，在同一时刻仅有一个线程执行该方法或该代码段。线程锁只在同一JVM中有效果，因为线程锁的实现在根本上是依靠线程之间共享内存实现的，比如Synchronized、Lock等。

2.进程锁

为了控制同一操作系统中多个进程访问某个共享资源，因为进程具有独立性，各个进程无法访问其他进程的资源，因此无法通过synchronized等线程锁实现进程锁。

3.分布式锁

当多个进程不在同一个系统中，用分布式锁控制多个进程对资源的访问。

分布式锁的特点

1、互斥性：任意时刻，只能有一个客户端获取锁，不能同时有两个客户端获取到锁。

2、安全性：锁只能被持有该锁的客户端删除，不能由其它客户端删除。

3、死锁：获取锁的客户端因为某些原因（如down机等）而未能释放锁，其它客户端再也无法获取到该锁。

4、容错：当部分节点（redis节点等）down机时，客户端仍然能够获取锁和释放锁。

分布式锁一般有三种实现方式：

1. 数据库乐观锁；

2. 基于ZooKeeper的分布式锁;

   3.基于Redis的分布式锁；

Redis实现分布式锁

基于Redis命令：SET key value NX EX max-lock-time

这里补充下： 从2.6.12版本后, 就可以使用set来获取锁, Lua 脚本来释放锁。setnx是老黄历了，set命令nx,xx等参数, 是为了实现 setnx 的功能。

edis命令：SET key value NX EX max-lock-time

补充： 从2.6.12版本后, 就可以使用set来获取锁, Lua 脚本来释放锁。setnx是老黄历了，set命令nx,xx等参数, 是为了实现 setnx 的功能。