Redis应用学习——缓存的使用与设计

时间 2019-11-06

标签 redis 应用学习缓存使用设计栏目 Redis 繁體版

原文原文链接

1. 缓存的收益与成本

1. 收益：java

经过缓存加速读写速度。在内存中读写比硬盘速度快
下降数据库服务器的负载。好比业务端的请求的数据大多数都由Redis服务器来处理，大大减轻MySQL服务器的压力

2. 成本：redis

数据不一致问题，好比Redis服务器与数据库服务器之间的某些数据可能会发生不一致问题，这是由两个服务器的数据更新策略不一样引发的
代码维护成本，须要添加数据缓存的逻辑代码
运维成本，好比须要维护RedisCluster

3. 使用场景：算法

使用缓存来下降关系型数据库服务器的负载，好比将某些业务须要读写的数据库服务器中的一些数据存储到缓存服务器中，而后这部分业务就能够直接经过缓存服务器进行数据读写
加快请求响应时间，Redis的数据是存储在内存中的，因此能够大大提升IO响应速度
对于关系型数据库服务器的大量写操做，能够先由Redis服务器进行批量写操做，而后再将Redis服务器中批量写操做的结果写入到数据库服务器中。好比计数器操做，若是要作1千万次计数，不可能每次都要对数据库服务器进行update操做，能够在Redis服务器中经过incr key命令进行计数，批量执行完成后再将最后的结果写入数据库服务器

2. 缓存更新策略

1. 超时删除数据：也就是设置key的过时时间，好比经过expire命令设置的超时key，该策略数据一致性较低，但维护成本也低数据库

2. LRU/LFU/FIFO算法剔除：主要是针对当Redis的缓存数据达到设置的最大内存如何处理的策略，该策略数据一致性很低，但维护成本也低后端

3. 主动更新：在开发过程当中经过编写逻辑代码，控制数据更新，数据一致性高，但维护成本也高缓存

4. 使用状况：数据一致性要求低就使用最大内存时数据淘汰策略，若是数据一致性要求高，就将主动更新和超时删除结合使用，最大内存时数据淘汰策略保底服务器

3. 缓存粒度控制

1. 缓存粒度：以用户信息为例，在MySQL中用户表包含多个字段，经过select语句查询得到用户信息时，到底是选择缓存用户每一个字段的数据，仍是选择某几个重要字段的数据进行缓存，缓存全部字段或部分字段就是指缓存粒度，能够理解为缓存粒度就是指缓存对象的数据的完整性并发

2. 缓存粒度控制：运维

从通用性角度来看，确定是使用全量属性更好
从占用空间角度来看，部分属性更好
代码维护上来看，全量属性更好，由于若是缓存部分属性须要增删属性时，比较麻烦

4. 缓存穿透问题

1. 缓存穿透：在实际应用中，业务层会先向缓存层发出数据请求，若是过这些请求没有命中（缓存层没有请求的数据），那么就会向关系型数据库层发出请求，从关系型数据库中取出数据回写到缓存层中，并返回给业务层，在下一次请求时就能够从缓存层返回数据；但若是数据库中也没有请求的数据，那么就会返回业务层空值，在后续业务层的请求同一个数据时，缓存层始终都没有数据，那么每次都会向数据库层请求数据，这样就形成了缓存穿透。异步

2. 产生缓存穿透的缘由：

业务逻辑代码自身问题
恶意攻击、爬虫等

3. 解决缓存穿透的方法：

缓存空对象，即当缓存层、数据库层皆没有业务层请求的数据时，就向缓存层中写入一个null，问题就是可能会须要更多的key，通常会给这些key设置一个较短的过时时间，另外一个问题就是缓存层和数据库层出现短期的数据不一致，这个也能够经过设置过时时间解决。
布隆过滤器：能够理解为将key放置在布隆过滤器中，若是请求数据的key存在，则经过请求，不然阻止请求经过。将全部可能存在的数据的key哈希到一个足够大的bitmap中，一个必定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。

5. 无底洞问题

1. 什么是无底洞问题：一般状况下，能够经过增长集群部署的机器数量来提高性能，可是在2010年，FaceBook发如今部署了3000个节点后发现性能反而降低；也就是说，集群中有更多的机器不表明有更好的性能，但随着数据量和并发处理量的提高，又必须提高集群的机器数量，这就是无底洞问题，这个问题没有好的解决办法，只能是经过在细节方面的优化处理来尽可能提升性能，好比优化IO操做、优化Redis集群中的批量命令执行等

6. 缓存雪崩

1. 问题描述：若是缓存中部分key集中在一段时间内失效，发生大量的缓存穿透，全部的查询都落在数据库上，形成了缓存雪崩。形成这个问题的缘由除了是key失效之外，还多是缓存集群宕机

2. 解决方案：

设置缓存永远不过时：

从缓存上看，确实没有设置过时时间，这就保证了，不会出现热点key过时问题，也就是“物理”不过时。
从功能上看，把过时时间存在key对应的value里，若是发现要过时了，经过一个后台的异步线程进行缓存的构建，也就是“逻辑”过时
从实战看，这种方法对于性能很是友好，惟一不足的就是构建缓存时候，其他线程(非构建缓存的线程)可能访问的是老数据

示例伪代码

String get(final String key) {  
        V v = redis.get(key);  
        String value = v.getValue();  
        long timeout = v.getTimeout();  
        if (v.timeout <= System.currentTimeMillis()) {  
            // 异步更新后台异常执行  
            threadPool.execute(new Runnable() {  
                public void run() {  
                    String keyMutex = "mutex:" + key;  
                    if (redis.setnx(keyMutex, "1")) {  
                        redis.expire(keyMutex, 3 * 60);  
                        String dbValue = db.get(key);  
                        redis.set(key, dbValue);  
                        redis.delete(keyMutex);  
                    }  
                }  
            });  
        }  
        return value;  
    }

能够在原有的失效时间基础上增长一个随机值，好比1-5分钟随机，这样每个缓存的过时时间的重复率就会下降，就很难引起集体失效的事件。

使用互斥锁(mutex key): 这种解决方案思路比较简单，就是只让一个线程构建缓存，其余线程等待构建缓存的线程执行完，从新从缓存获取数据就能够了，若是是单机，能够用synchronized或者lock来处理，若是是分布式环境能够用分布式锁就能够了（分布式锁，能够用memcache的add, redis的setnx, zookeeper的添加节点操做），能保证数据一致性，可是可能会引发死锁。

对应的示例伪代码

String get(String key) {
//首先尝试从redis（或redis集群）中获取key对应的数据  
   String value = redis.get(key); 
//若是为null，则使用redis中的分布式锁
   if (value  == null) {  
//经过setnx方法建立分布式锁
    if (redis.setnx(key_mutex, "1")) {  
        // 设置分布式锁的过时时间，能够避免死锁 
        redis.expire(key_mutex, 3 * 60)  
        value = db.get(key); //从数据库中取得数据 
        redis.set(key, value);//回写到缓存中  
        redis.delete(key_mutex);//释放锁  
    } else {  
        //其余线程休息50毫秒后重试  
        Thread.sleep(50);  
        get(key);  
    }  
  }  
}

"提早"使用互斥锁(mutex key)：在value内部设置1个超时值(timeout1),。当从cache读取到timeout1发现它已通过期时候，立刻延长timeout1并从新设置到cache。而后再从数据库加载数据并设置到cache中。

7. 缓存击穿

1. 对于一些设置了过时时间的key，若是这些key可能会在某些时间点被超高并发地访问，是一种很是“热点”的数据。这个时候，须要考虑一个问题：缓存被“击穿”的问题，这个和缓存雪崩的区别在于这里针对某一key缓存，前者则是不少key。缓存在某个时间点过时的时候，刚好在这个时间点对这个Key有大量的并发请求过来，这些请求发现缓存过时通常都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。

2. 解决方案：

使用互斥锁(mutex key): 这种解决方案思路比较简单，就是只让一个线程构建缓存，其余线程等待构建缓存的线程执行完，从新从缓存获取数据就能够了，若是是单机，能够用synchronized或者lock来处理，若是是分布式环境能够用分布式锁就能够了（分布式锁，能够用memcache的add, redis的setnx, zookeeper的添加节点操做），可是可能会引发死锁。分布式锁以及Java代码实现后面详细介绍

对应的示例伪代码

String get(String key) {
//首先尝试从redis（或redis集群）中获取key对应的数据  
   String value = redis.get(key); 
//若是为null，则使用redis中的分布式锁
   if (value  == null) {  
//经过setnx方法建立分布式锁
    if (redis.setnx(key_mutex, "1")) {  
        // 设置分布式锁的过时时间，能够避免死锁 
        redis.expire(key_mutex, 3 * 60)  
        value = db.get(key); //从数据库中取得数据 
        redis.set(key, value);//回写到缓存中  
        redis.delete(key_mutex);//释放锁  
    } else {  
        //其余线程休息50毫秒后重试  
        Thread.sleep(50);  
        get(key);  
    }  
  }  
}

"提早"使用互斥锁(mutex key)：在value内部设置1个超时值(timeout1),。当从cache读取到timeout1发现它已通过期时候，立刻延长timeout1并从新设置到cache。而后再从数据库加载数据并设置到cache中。

设置缓存永远不过时：

从缓存上看，确实没有设置过时时间，这就保证了，不会出现热点key过时问题，也就是“物理”不过时。
从功能上看，把过时时间存在key对应的value里，若是发现要过时了，经过一个后台的异步线程进行缓存的构建，也就是“逻辑”过时
从实战看，这种方法对于性能很是友好，惟一不足的就是构建缓存时候，其他线程(非构建缓存的线程)可能访问的是老数据

示例伪代码

String get(final String key) {  
        V v = redis.get(key);  
        String value = v.getValue();  
        long timeout = v.getTimeout();  
        if (v.timeout <= System.currentTimeMillis()) {  
            // 异步更新后台异常执行  
            threadPool.execute(new Runnable() {  
                public void run() {  
                    String keyMutex = "mutex:" + key;  
                    if (redis.setnx(keyMutex, "1")) {  
                        redis.expire(keyMutex, 3 * 60);  
                        String dbValue = db.get(key);  
                        redis.set(key, dbValue);  
                        redis.delete(keyMutex);  
                    }  
                }  
            });  
        }  
        return value;  
    }