缓存层在互联网应用中所起到的作用不言而喻，所以，如何设计和优化缓存是我们必须要深入了解的。在目前的大型互联网公司应用中，大量使用了Redis缓存的场景，那么在这么多使用的场景中，会有哪些应用的中的坑，怎样的设计可以避免这些问题的出现。
缓存穿透
缓存穿透就是指，客户端访问一个根本在缓存中不存在的数据，那么这个请求肯定不会命中缓存，然后直接打到数据库层中，那么如果存在大量的这种请求会把整个提供冲垮。那么造成缓存穿透的原因主要有两个：
1.自身业务代码逻辑问题造成数据问题。
2.恶意攻击，或者爬虫程序，造成大量的空命中。
解决方案有两个：
- 将空对象保存到缓存中
这个方案的思想就是，如果发现这个缓存没有命中，而且数据库中也查询不到，就直接保存为null，这样后面的访问都可以命中缓存而不用访问数据库。见伪代码实现。
public String getCache(String key){
//从缓存中获取数据
String cacheValue = cache.get(key);
//判断缓存中取到值没有
if(Strings.isNullOrBlank(cacheValue)){
//从DB中获取数据
String storageValue = db.get(key);
//将数据库中取出来的值保存到缓存中
cache.set(key, storageValue);
// 如果存储数据为空， 需要设置一个过期时间(300秒)
if (storageValue == null) {
cache.expire(key, 60 * 5);
}
return storageValue;
}
return cacheValue;
}
- 布隆过滤器
对于恶意攻击，向服务器请求大量不存在的数据造成的缓存穿透，还可以用布隆过滤器先做一次过滤，对于不存在的数据布隆过滤器一般都能够过滤掉，不让请求再往后端发送。当布隆过滤器说某个值存在时，这个值可能不存在；当它说不存在时，那就肯定不存在。布隆过滤器实际上就是一个巨长的位数字加上几个不一样的无偏hash函数组成。所谓无偏就是说这些hash函数能够算的比较均匀。我以上面这张图来向大家解释一下布隆过滤器的工作原理，上图中试一个19位的位数组，初始化后数组中的每一位都是0。
- 首先，我们需要将key1放入到布隆过滤器中，实际上就针对key1做若干次hash运算，得到若干个不同的hashCode，然后用这若干的hashCode对整个数组的length取模，得到若干数组的下标位置，最后将这些位置的0改为1.
- 然后如果判断key1是否存在于当前布隆过滤器中，只需要用相同的hash算法得到hashcode后取模得到下标位置，只要有一个位置不为1，那么就代表key1不存在。但是如果下标都为1也并不能说明这个key1就一定存在，只能说极有可能存在。
这种方法适用于数据命中不高、 数据相对固定、 实时性低（通常是数据集较大） 的应用场景， 代码维护较为复杂， 但是缓存空间占用很少。
缓存失效
由于大批量缓存在同一时间失效可能导致大量请求同时穿透缓存直达数据库，可能会造成数据库瞬间压力过大甚至挂掉，对于这种情况我们在批量增加缓存时最好将这一批数据的缓存过期时间设置为一个时间段内的不同时间。伪代码如下：
public String get(String key) {
// 从缓存中获取数据
String cacheValue = cache.get(key);
// 缓存为空
if (StringUtils.isBlank(cacheValue)) {
// 从db中获取
String storageValue = db.get(key);
//设置一个过期时间(300到600之间的一个随机数)
cache.set(key, storageValue);
int expireTime = new Random().nextInt(300) + 300;
if (storageValue == null) {
cache.expire(key, expireTime);
}
return storageValue;
} else {
// 缓存非空
return cacheValue;
}
}
缓存雪崩
缓存雪崩指的是缓存层支撑不住或宕掉后， 大量流量会打向后端存储层。由于缓存层承载着大量请求， 有效地保护了存储层， 但是如果缓存层由于某些原因不能提供服务(比如超大并发过来，缓存层支撑不住，或者由于缓存设计不好，类似大量请求访问bigkey，导致缓存能支撑的并发急剧下降)， 于是大量请求都会达到存储层， 存储层的调用量会暴增， 造成存储层也会级联宕机的情况。
预防和解决缓存雪崩问题， 可以从以下三个方面进行着手。
1） 保证缓存层服务高可用性，比如使用Redis Sentinel或Redis Cluster。如果条件允许，尽量使用集群。
2） 依赖隔离组件为后端限流并降级。比如使用Hystrix限流降级组件。
3） 提前演练。 在项目上线前， 演练缓存层宕掉后， 应用以及后端的负载情况以及可能出现的问题， 在此基础上做一些预案设定。
缓存重建问题
开发人员使用“缓存+过期时间”的策略既可以加速数据读写， 又保证数据的定期更新， 这种模式基本能够满足绝大部分需求。 但是有两个问题如果同时出现， 可能就会对应用造成致命的危害：
（1） 当前key是一个热点key，并发量非常大。
（2） 重建缓存不能在短时间完成， 可能是一个复杂的SQL或者是多次IO计算。
在缓存失效的瞬间， 有大量线程来重建缓存， 造成后端负载加大， 甚至可能会让应用崩溃。
要解决这个问题主要就是要避免大量线程同时重建缓存。我们可以利用互斥锁来解决，此方法只允许一个线程重建缓存， 其他线程等待重建缓存的线程执行完， 重新从缓存获取数据即可。伪代码如下：
public String get(String key) {
// 从Redis中获取数据
String value = redis.get(key);
// 如果value为空， 则开始重构缓存
if (value == null) {
// 只允许一个线程重建缓存， 使用nx， 并设置过期时间ex
String mutexKey = "mutext:key:" + key;
if (redis.set(mutexKey, "1", "ex 180", "nx")) {
// 从数据源获取数据
value = db.get(key);
// 回写Redis， 并设置过期时间
redis.setex(key, timeout, value);13 // 删除key_mutex
redis.delete(mutexKey);
}
else {
// 其他线程休息50毫秒后重试
Thread.sleep(50);
get(key);
}
}
return value;
}
开发规范与性能设计优化
一、键值设计
- 建议以业务名为前缀，用冒号分隔，例如：
trade:order:1
- 保证简洁性，在保证语义的情况下尽量控制key长度，例如：
user:{uid}:friends:messages:{mid} 简化为 u:{uid}:fr:m:{mid}
- 不要包含特殊字符（空格，换行，单双引号，以及其他转义字符）
- 绝对禁止出现bigkey。
一般来说bigkey的出现是由于程序设计不当导致的，如果单个value超过10K或者集合类元素超过5000个，那我们就认为是bigkey了。例如社交应用里面，粉丝的列表，如果是某些明星的粉丝列表，设计不当一定是bigkey；还有一类比较常见的就是把数据load到缓存中，有些同学图方便把所有数据都保存到缓存中，形成bigkey。
bigkey会产生的影响有哪些？
（1） 导致redis阻塞，redis是单线程的，如果一个key太大会导致执行时间过长将redis阻塞。
（2） 网络拥塞，获取bigkey意味着产生的流量较大，假设一个bigkey为1MB，客户端每秒访问1000次，那么每秒产生流量1000M，普通的千兆网卡差不多128M/s，直接就会把整个网络给塞满，其他的应用也没办法工作了。
（3） 过期删除，例如一个bigkey是个hash里面保存了10W的数据，但是每次使用我只拿一个，是不是没问题？当然不是，如果这个key设置了过期时间，当到了过期时间会被删除，如果没有使用redis4.0才有的过期异步删除（config文件中:lazyfree-lazyexpire yes），一样会阻塞redis。
那么如何优化bigkey？
（1）拆分bigkey
例如微博JAY的粉丝有5000W，那么我们可以把周杰伦的粉丝按照规律分为10000个Key，每个Key保存5000的粉丝数量。
（2）选择适合的数据类型存储。
（3）控制key的生命周期，建议设置expire过期时间，并且使用随机函数将过期时间打散，防止集中过期。
二、命令使用方面
- 禁止线上使用keys、flushall、flushdb等，通过redis的rename机制禁掉命令，或者使用scan方式渐进式处理。
- O(N)命令关注N的数量。
例如hgetall、lrange、smembers、zrange、sinter等并非不能使用，但是需要明确N的值。有 遍历的需求可以使用hscan、sscan、zscan代替。 - 合理使用select命令
Select 命令用于切换到指定的数据库，数据库索引号 index 用数字值指定，以 0 作为起始索引值，redis的多数据库较弱，使用数字进行区分，很多客户端支持较差，同时多业务用多数据库实际还是单线程处理，会有干扰。 - 可能的情况下尽量使用批量操作命令
（1） 可以优先使用原生的批量命令例如：mget、mset。
（2） 也可以使用pipeline将命令进行打包执行。
管道（Pipeline）
客户端可以一次性发送多个请求而不用等待服务器的响应，待所有命令都发送完后再一次性读取服务的响应，这样可以极大的降低多条命令执行的网络传输开销，管道执行多条命令的网络开销实际上只相当于一次命令执行的网络开销。需要注意到是用pipeline方式打包命令发送，redis必须在处理完所有命令前先缓起所有命令的处理结果。
打包的命令越多，缓存消耗内存也越多。所以并不是打包的命令越多越好。pipeline中发送的每个command都会被server立即执行，如果执行失败，将会在此后的响应中得到信息；也就是pipeline并不是表达“所有command都一起成功”的语义，管道中前面命令失败，后面命令不会有影响，继续执行。
5. Redis事务功能较弱，不建议过多使用，可以用lua替代.
Redis Lua脚本
Redis在2.6推出了脚本功能，允许开发者使用Lua语言编写脚本传到Redis中执行。使用脚本的好处如下:
1、减少网络开销：本来5次网络请求的操作，可以用一个请求完成，原先5次请求的逻辑放在redis服务器上完成。使用脚本，减少了网络往返时延。这点跟管道类似。
2、原子操作：Redis会将整个脚本作为一个整体执行，中间不会被其他命令插入。管道不是原子的，不过redis的批量操作命令(类似mset)是原子的。
3、替代redis的事务功能：redis自带的事务功能很鸡肋，报错不支持回滚，而redis的lua脚本几乎实现了常规的事务功能，支持报错回滚操作，官方推荐如果要使用redis的事务功能可以用redis lua替代。
注意，不要在Lua脚本中出现死循环和耗时的运算，否则redis会阻塞，将不接受其他的命令， 所以使用时要注意不能出现死循环、耗时的运算。redis是单进程、单线程执行脚本。管道不会阻塞redis。
三、 客户端使用
- 使用连接池链接redis，例如jedis：
JedisPoolConfig jedisPoolConfig = new JedisPoolConfig();
jedisPoolConfig.setMaxTotal(5);
jedisPoolConfig.setMaxIdle(2);
jedisPoolConfig.setTestOnBorrow(true);
JedisPool jedisPool = new JedisPool(jedisPoolConfig, "localhost", 6379, 3000, null);
Jedis jedis = null;
try {
jedis = jedisPool.getResource();
//具体的命令
jedis.executeCommand()
} catch (Exception e) {
logger.error("error: " + e.getMessage(), key, e);
} finally {
if (jedis != null)
//注意这里不是关闭连接，在JedisPool模式下，Jedis会被归还给资源池。
jedis.close();
}
连接池参数含义：
（1） maxTotal：最大连接数，早期的版本叫maxActive，需要设置这个参数，考虑的点有点多：
- 业务希望的并发量
- 客户端执行命令时间
- Redis资源：例如 应用个数 * maxTotal 是不能超过redis的最大连接数maxclients。
- 资源开销：例如虽然希望控制空闲连接(连接池此刻可马上使用的连接)，但是不希望因
为连接池的频繁释放创建连接造成不必靠开销。
举例说明：
例如一次请求的时间是1ms，那么一个连接的QPS大约是1000，如果业务方期望QPS到达50000，那么理论上，资源池大小应该是50000 / 1000 = 50个。但事实上这是个理论值，还要考虑到要比理论值预留一些资源，通常来讲maxTotal可以比理论值大一些。
但这个值不是越大越好，一方面连接太多占用客户端和服务端资源，另一方面对于Redis这种高
QPS的服务器，一个大命令的阻塞即使设置再大资源池仍然会无济于事。
（2） maxIdle和minIdle
maxIdle（最大空闲连接数）实际上才是业务需要的最大连接数，maxTotal是为了给出余量，所以maxIdle不要设置过小，否则会有新连接开销。连接池的最佳性能是maxTotal = maxIdle，这样就避免连接池伸缩带来的性能干扰。但是如果并发量不大或者maxTotal设置过高，会导致不必要的连接资源浪费。一般推荐maxIdle可以设置为按上面的业务期望QPS计算出来的理论连接数，maxTotal可以再放大一倍。
minIdle（最小空闲连接数），与其说是最小空闲连接数，不如说是"至少需要保持的空闲连接数"，在使用连接的过程中，如果连接数超过了minIdle，那么继续建立连接，如果超过了maxIdle，当超过的连接执行完业务后会慢慢被移出连接池释放掉。
- 连接池预热 当预先知道系统一启动就会有很多请求过来，那么可以给redis连接池做预热，比如快速的创建一些redis连接，执行简单命令，类似ping()，快速的将连接池里的空闲连接提升到minIdle的数 量。示例代码如下：
List<Jedis> minIdleJedisList = new ArrayList<Jedis>(jedisPoolConfig.getMinIdle());
for (int i = 0; i < jedisPoolConfig.getMinIdle(); i++) {
Jedis jedis = null;
try {
jedis = pool.getResource();
minIdleJedisList.add(jedis);
jedis.ping();
} catch (Exception e) {
logger.error(e.getMessage(), e);
} finally {
//注意，这里不能马上close将连接还回连接池，否则最后连接池里只会建立1个连接。。
//jedis.close();
}
}
//统一将预热的连接还回连接池
for (int i = 0; i < jedisPoolConfig.getMinIdle(); i++) {
Jedis jedis = null;
try {
jedis = minIdleJedisList.get(i);
//将连接归还回连接池
jedis.close();
} catch (Exception e) {
logger.error(e.getMessage(), e);
} finally {
}
}
- 高并发场景下，客户端添加熔断功能（例如 hystrix）
- 根据自身业务设置最大内存（maxmemory），选好maxmemory-policy(最大内存淘汰策略)，设置好过期时间。
Redis本身具有三种清除策略：
- 被动删除：当读/写一个已经过期的key时，会触发惰性删除策略，直接删除掉这个过 期key。
- 主动删除：由于惰性删除策略无法保证冷数据被及时删掉，所以Redis会定期主动淘汰 一批已过期的key
- 当前已用内存超过maxmemory限定时，触发主动清理策略。
需要说明的是，当REDIS运行在主从模式时，只有主结点才会执行被动和主动这两种过期删除策略，然后把删除操作”del key”同步到从结点。那么第三种策略是在redis内存超过设置maxmemory限定时，会触发主动清理策略，如果不设置maxmemory，当 Redis 内存超出物理内存限制时，内存的数据会开始和磁盘产生频繁的交换 (swap)，会让 Redis 的性能急剧下降。
最大内存淘汰策略说明：
- volatile-lru（默认）：即超过最大内存后，在过期键中使用lru算法进行key的剔除，保证不过期数据不被删除，但是可能会出现OOM问题。
- allkeys-lr：根据LRU算法删除键，不管数据有没有设置超时属性，直到腾出足够空间为止。
- allkeys-random： 随机删除所有键，直到腾出足够空间为止
- volatile-random： 随机删除过期键，直到腾出足够空间为止
- volatile-ttl： 根据键值对象的ttl属性，删除最近将要过期数据。如果没有，回退到
noeviction策略。
- noeviction： 不会剔除任何数据，拒绝所有写入操作并返回客户端错误信息"(error)
OOM command not allowed when used memory"，此时Redis只响应读操作。
