06.Redis 的击穿，穿透，雪崩，简单实现锁以及缓存一致性问题

1. Redis 的击穿，穿透，雪崩

1.1 Redis 击穿

产生原因：在高并发的情况下，在某一时间点，在高频获取的key在此时过期，大量请求直接请求到服务器上，导致缓存击穿

解决方案：

• 可以将热点数据设置为永远不过期；

• 基于 redis or zookeeper 实现互斥锁，等待第一个请求构建完缓存之后，再释放锁，进而其它请求才能通过该 key 访问数据。

  redis的分布式锁主要是通过 setnx 命令，设置锁的过期时间，只有返回是ok的才能去数据库中获取数据

  产生问题：在db端超时导致锁过期

  解决方案： 通过zookeeper 实现分布式锁

1.2 Redis穿透

一般是出现这种情况是因为恶意频繁查询才会对系统造成很大的问题: key缓存并且数据库不存在，所以每次查询都会查询数据库从而导致数据库崩溃。

解决方案：使用布隆过滤器

布隆过滤器缺点：只能增加不能删除

可使用布谷鸟过滤器 ，设置空key

1.3 Redis雪崩

雪崩指的是多个key查询并且出现高并发，缓存中失效或者查不到，然后都去db查询，从而导致db压力突然飙升，从而崩溃。

解决方案：

• 时点性无关:均匀的设计过期时间

• 时点性有关:强依赖击穿的方案

  ​ 也可在程序设计的时候在业务层进行时点进行请求延时操作

  ​ 当知道时点之后的数据也可以进行预加载工作

• 事前：redis 高可用，主从+哨兵，redis cluster，避免全盘崩溃。

• 事中：本地 ehcache 缓存 + hystrix 限流&降级，避免 MySQL 被打死。

• 事后：redis 持久化，一旦重启，自动从磁盘上加载数据，快速恢复缓存数据。

  时点性有关指某一个时间段某些key必须要过期使用新数据

2. Redis 的分布式锁实现

最好是使用zookeeper实现分布式锁

原理需要三个关键元素
1. setnx
2.过期时间
3.多线程（守护进程），延长过期

2.1 Redis加锁实现

public class RedisTool {

    private static final String LOCK_SUCCESS = "OK";
    private static final String SET_IF_NOT_EXIST = "NX";
    private static final String SET_WITH_EXPIRE_TIME = "PX";

    /**
     * 尝试获取分布式锁
     * @param jedis Redis客户端
     * @param lockKey 锁
     * @param requestId 请求标识
     * @param expireTime 超期时间
     * @return 是否获取成功
     */
    public static boolean tryGetDistributedLock(Jedis jedis, String lockKey, String requestId, int expireTime) {

        String result = jedis.set(lockKey, requestId, SET_IF_NOT_EXIST, SET_WITH_EXPIRE_TIME, expireTime);

        if (LOCK_SUCCESS.equals(result)) {
            return true;
        }
        return false;

    }

}

2.2 redis 解锁代码

public class RedisTool {

    private static final Long RELEASE_SUCCESS = 1L;

    /**
     * 释放分布式锁
     * @param jedis Redis客户端
     * @param lockKey 锁
     * @param requestId 请求标识
     * @return 是否释放成功
     */
    public static boolean releaseDistributedLock(Jedis jedis, String lockKey, String requestId) {

        String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
        Object result = jedis.eval(script, Collections.singletonList(lockKey), Collections.singletonList(requestId));

        if (RELEASE_SUCCESS.equals(result)) {
            return true;
        }
        return false;

    }

}

Redis的弊端

• 数据库事务超时，导致锁过期
• redis cluster集群环境下，假如现在A客户端想要加锁，它会根据路由规则选择一台master节点写入key mylock，在加锁成功后，master节点会把key异步复制给对应的slave节点。如果此时redis master节点宕机，为保证集群可用性，会进行主备切换，slave变为了redis master。B客户端在新的master节点上加锁成功，而A客户端也以为自己还是成功加了锁的。此时就会导致同一时间内多个客户端对一个分布式锁完成了加锁，导致各种脏数据的产生。

Redis 缓存一致性

出现场景

在高并发的情况下涉及到数据更新：数据库和缓存更新，就容易出现缓存(Redis)和数据库（MySQL）间的数据一致性问题。

不管是先写MySQL数据库，再删除Redis缓存；还是先删除缓存，再写库，都有可能出现数据不一致的情况。举一个例子：

1.如果删除了缓存Redis，还没有来得及写库MySQL，另一个线程就来读取，发现缓存为空，则去数据库中读取数据写入缓存，此时缓存中为脏数据。

2.如果先写了库，在删除缓存前，写库的线程宕机了，没有删除掉缓存，则也会出现数据不一致情况。

因为写和读是并发的，没法保证顺序,就会出现缓存和数据库的数据不一致的问题。

解决方案

1.第一种方案：采用延时双删策略

在写库前后都进行redis.del(key)操作，并且设定合理的超时时间。

伪代码如下：

public void write(String key,Object data){
 redis.delKey(key);
 db.updateData(data);
 Thread.sleep(500);
 redis.delKey(key);
 }

具体的步骤就是：

• 先删除缓存；
• 再写数据库；
• 休眠500毫秒；
• 再次删除缓存

该方案的弊端

结合双删策略+缓存超时设置，这样最差的情况就是在超时时间内数据存在不一致，而且又增加了写请求的耗时。

2、第二种方案：异步更新缓存(基于订阅binlog的同步机制)

MySQL binlog增量订阅消费+消息队列+增量数据更新到redis

• 读Redis：热数据基本都在Redis
• 写MySQL:增删改都是操作MySQL
• 更新Redis数据：MySQ的数据操作binlog，来更新到Redis

1）数据操作主要分为两大块：

• 一个是全量(将全部数据一次写入到redis)
• 一个是增量（实时更新）

这里说的是增量,指的是mysql的update、insert、delate变更数据。

2）读取binlog后分析 ，利用消息队列,推送更新各台的redis缓存数据。

这样一旦MySQL中产生了新的写入、更新、删除等操作，就可以把binlog相关的消息推送至Redis，Redis再根据binlog中的记录，对Redis进行更新。

其实这种机制，很类似MySQL的主从备份机制，因为MySQL的主备也是通过binlog来实现的数据一致性。

消息推送工具你也可以采用别的第三方：kafka、rabbitMQ等来实现推送更新Redis。