Redis缓存设计与性能优化

缓存设计

---

缓存穿透

说明：
缓存穿透是指查询一个根本不存在的数据，缓存层和存储层都不会命中；一般先查询缓存，如果缓存中查询不到就会查询数据库，大量的不会命中的查询会直接查询数据库，导致数据库宕机。这样缓存就失去了存在的意义。

造成缓存失效的基本原因有两个：

• 自身业务代码或者数据出现问题。
• 一些恶意攻击、爬虫等造成大量空命中。

解决方案一
1、缓存空对象——通过伪代码说明

/**
* @Author: juli
* @Created in: 2021/07/25/17:56
* @Description:redis缓存穿透伪代码
* @Slogan 致敬大师，致敬未来的你
*/
public class RedisCache {
   
   @Autowired
   private Jedis jedis;

   public String get(String key){
       //从缓存中获取数据
       String cacheValue =  jedis.get(key);
       
       //缓存为空
       if (StringUtils.isBlank(cacheValue)){
           //从存储中获取
           String storageValue = storage.get(key);
           
           jedis.set(key,storageValue);
           //如果存储层为空，需要设置一个过期时间(300秒)
           if (StringUtils.isBlank(storageValue)){
               jedis.expire(key,60*5);
           }
           return storageValue;
       }else {
           //缓存非空直接返回
           return cacheValue;
       }
   }
}

解决方案二：布隆过滤器
对于恶意攻击，向服务器请大量不存在的数据造成缓存穿透，还可以用布隆过滤器，对于不存在的数据布隆过滤器一般都能过滤掉，不让请求再往后端发送。当布隆过滤器某个值存在时，这个值可能不存在；当某个值在布隆过滤器中不存在时，这个是一定不存在
布隆过滤器就是一个大型的位数数组和几个不一样的无偏hash函数。所谓无偏就是能够把元素的hash值算的比较均匀。
向布隆过滤器中添加key时，会使用多个hash函数对hash算的一个整数索引值然后对位数组的长度进行取模运算得到一个位置，每个hash函数都会算得一个不同的位置。再把位数组的这几个位置都置为1就完成了add操作。
在向布隆过滤器询问key是否存在时，跟add一样，先根据key做hash运算，把几个位置都算出来，看看位数组中的这几个位置是否都为1，只要有一个位为0，那么说明布隆过滤器中这个key不存在。如果都是1这个key不一定存在，只是极有可能存在，因为这些位被置为1可能是因为其他的key存在所致。如果这个位数组比较拥挤，这个概率就会很高，如果位数组比较稀疏，发生误差的概率就会小
这种方法适用于数据命中不高、数据相对固定、实时性低(通常是数据集较大)的应用场景，代码维护较为复杂，但是缓存空间占用很少。

可以用redisson实现布隆过滤器，引入依赖：

<dependency>
   <groupId>org.redisson</groupId>
   <artifactId>redisson</artifactId>
   <version>3.6.5</version>
</dependency>

示例伪代码：

package com.redis;


import org.redisson.Redisson;
import org.redisson.api.RBloomFilter;
import org.redisson.api.RedissonClient;
import org.redisson.config.Config;

/**
 * Created with IntelliJ IDEA.
 *
 * @Author: juli
 * @Date: 2021/06/01/23:07
 * @Description: Redisson 实现布隆过滤器
 * @Slogan 致敬大师，致敬未来的你
 */
public class RedissonBloomFilter {
    
    public static void main(String[] args) {
        //Redisson连接
        Config config = new Config();
        config.useSingleServer().setAddress("redis://localhost:6379");
        //构造Redisson
        RedissonClient redissonClient =   Redisson.create(config);

        RBloomFilter<String> bloomFilter = redissonClient.getBloomFilter("nameList");
        //初始化布隆过滤器，预计元素为100000000L，误差率为3%，根据这两个参数会计算出底层的bit数组大小
        Long expectedElements = 100000000L;
        double  errorRate = 0.03;
        bloomFilter.tryInit(expectedElements,errorRate);
        //将juli插入到布隆过滤器中
        bloomFilter.add("居里");

        //判断下边号码是否在布隆过滤器中
        System.out.println(bloomFilter.contains("司马懿"));//false
        System.out.println(bloomFilter.contains("司马昭"));//false
        System.out.println(bloomFilter.contains("居里"));//true
    }
}

使用布隆过滤器需要把数据提前放入到布隆过滤器中，并且再增加数据时也要往布隆过滤器里放，布隆过滤器伪代码：

//初始化布隆过滤器
RBloomFilter<String> bloomFilter = redisson.getBloomFilter("nameList");
//初始化布隆过滤器：预计元素为100000000L,误差率为3%
bloomFilter.tryInit(100000000L,0.03);
        
//把所有数据存入布隆过滤器
void init(){
    for (String key: keys) {
        bloomFilter.put(key);
    }
}

String get(String key) {
    // 从布隆过滤器这一级缓存判断下key是否存在
    Boolean exist = bloomFilter.contains(key);
    if(!exist){
        return "";
    }
    // 从缓存中获取数据
    String cacheValue = cache.get(key);
    // 缓存为空
    if (StringUtils.isBlank(cacheValue)) {
        // 从存储中获取
        String storageValue = storage.get(key);
        cache.set(key, storageValue);
        // 如果存储数据为空， 需要设置一个过期时间(300秒)
        if (storageValue == null) {
            cache.expire(key, 60 * 5);
        }
        return storageValue;
    } else {
        // 缓存非空
        return cacheValue;
    }
}

注意：布隆过滤器不能删除数据，如果要删除得重新初始化数据

缓存雪崩

**说明：**由于大批量缓存在同一时间失效可能导致大量请求同时穿过缓存直达数据库，可能造成数据库瞬间压力过大甚至宕机，对于这种情况我们在批量增加缓存时最好将这一批数据的缓存时间设置为一个时间段内不同时间。
示例伪代码：

String get(String key) {
    // 从缓存中获取数据
    String cacheValue = cache.get(key);
    // 缓存为空
    if (StringUtils.isBlank(cacheValue)) {
        // 从存储中获取
        String storageValue = storage.get(key);
        cache.set(key, storageValue);
        //设置一个过期时间(300到600之间的一个随机数)
        int expireTime = new Random().nextInt(300)  + 300;
        if (storageValue == null) {
            cache.expire(key, expireTime);
        }
        return storageValue;
    } else {
        // 缓存非空
        return cacheValue;
    }
}

预防和解决缓存雪崩问题， 可以从以下三个方面进行着手。

1） 保证缓存层服务高可用性，比如使用Redis Sentinel或Redis Cluster。
2） 依赖隔离组件为后端限流熔断并降级。比如使用Sentinel或Hystrix限流降级组件。
比如服务降级，我们可以针对不同的数据采取不同的处理方式。当业务应用访问的是非核心数据（例如电商商品属性，用户信息等）时，暂时停止从缓存中查询这些数据，而是直接返回预定义的默认降级信息、空值或是错误提示信息；当业务应用访问的是核心数据（例如电商商品库存）时，仍然允许查询缓存，如果缓存缺失，也可以继续通过数据库读取。
3） 提前演练。 在项目上线前， 演练缓存层宕掉后， 应用以及后端的负载情况以及可能出现的问题， 在此基础上做一些预案设定。

缓存击穿

当前key是一个热点key（例如一个秒杀活动），并发量非常大。
重建缓存不能在短时间完成，可能是一个复杂计算，例如复杂的SQL、多次IO、多个依赖等。
在缓存失效的瞬间，有大量线程来重建缓存，造成后端负载加大，甚至可能会让应用崩溃。

解决方案：
利用互斥锁：
此方法只允许一个线程重建缓存， 其他线程等待重建缓存的线程执行完， 重新从缓存获取数据即可。
示例伪代码：

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);
            // 删除key_mutex
            redis.delete(mutexKey);
        }// 其他线程休息50毫秒后重试
        else {
            Thread.sleep(50);
            get(key);
        }
    }
    return value;
}

缓存与数据库双写不一致

在大并发情况下，同时操作数据库与缓存会存在不一致问题
1、双写不一致情况

2、读写并发不一致

解决方案：
1、对于并发几率很小的数据(如个人维度的订单数据，用户数据)，这种几乎不用考虑这个问题。很少会发生缓存不一致，可以给缓存数据加上过期时间，每隔一段时间触发读的主动更新即可。
2、就算并发很高，如果业务上能容忍短时间的缓存不一致(如商品名称、商品分类菜单等)，缓存加上过期时间依然可以解决大部分业务对于缓存的要求。
3、如果不能容忍缓存数据不一致，可以通过读写锁保证并发读写或写写的时候按顺序排好队，读读的时候相当于无锁。
4、也可以用阿里开源的canal通过监听数据库的binlog日志及时的修改缓存，但是引入了新的中间件，增加了系统的复杂度。

总结：
以上我们针对的都是读多写少的情况加入缓存提高性能，如果写多读多的情况又不能容忍缓存数据不一致，那就没必要加缓存了，可以直接操作数据库。放入缓存的数据应该是对实时性、一致性要求不高是很高的数据。切记不要为了用缓存，同时又要保证绝对一致性做大量的设计和控制，增加系统复杂性。

---

开发规范与性能优化

参考的阿里开发规范
一、键值设计
1、key名设计

1. （1）【建议】：可读性和管理性
   以业务名(或者数据库名)为前缀(防止key冲突)，用冒号分隔，比如业务名:表Id

trade：order：1

2. (2)【建议】：简洁性
   保证语义正确的前提下，控制key的长度，当key较多时，内存占用也不容忽视，例如：

user:{uid}:friends:messages:{mid} 简化为 u:{uid}:fr:m:{mid}

3. (3)【强制】：不要包含特殊字符
   反例：包含空格、换行、单双引号以及其他转义字符

2、value设计
4. (1)【强制】：拒绝bigkey（防止网络卡流量、慢查询)
在redis中，一个字符最大512M，一个二级数据结构(例如：hash、list、set、zset)可以存储大约40亿个(2^32-1)个元素，但实际中如果下面两种情况，我们就会认为它是bigkey。

5. 字符串类型：：它的big体单个value值很大，一般认为超过10kB就是bigkey。
   2.非字符串类型：hash、list、set、zset ，它们的big体现在元素个数太多。
   一般来说,string类型控制在10KB以内，hash、list、set、zset元素个数不要超过5000。
   反例：一个包含200万个元素的list
   非字符串的bigkey，不要使用del删除，使用hsan、sscan、zscan方式渐进式删除，同时要注意防止bigkey过期时间自动删除问题(例如一个200万的zset设置1小时过期，会触发del操作，造成阻塞)

bigkey危害
1、导致redis阻塞
2、网络阻塞
bigkey也就是意味着每次获取要产生的网络流量较大，假设一个bigkey为1MB，客户端每秒访问量为1000，那么每秒产生1000M的流量，对于普通的千兆网卡(按照字节算是128MB/s)的服务简直就是灭顶之灾，而且一般服务器会采用单机多实例的方式部署，也就是一个bigkey可能会对其他实例造成影响，其后果不堪设想。
3、过期删除
有个bigkey,只执行简单的命令，例如hget、lpop、zscore等，但是设置了过期时间，当他过期后，会被删除，如果没有使用redis4
.0的过期异步删除(lazyfree-lazy-expire yes)，就会存在阻塞redis的可能性

bigkey的产生
一般来说，bigkey的产生都是由于程序设计不当，或者对于数据规模预料不清楚造成的，来看几个例子：

1. 社交类：粉丝列表，如果某些明星或者大V不精心设计下，必是bigkey
2. 统计类：例如按天存储某项功能或者网站的用户集合，除非没几个用，否则会产生bigkey
3. 缓存类：将数据从数据库load出来序列化放到redis中，这个方式非常常用，当时有两个地方需要注意，第一，是不是有必要把所有字段都缓存；第二有没有相关联的数据，有的为了方便把相关数据都存在一个key下，产生bigkey。

如何优化bigkey
1、拆
big list：list1、…listN
big hash：可以将数据分段存储，比如一个大key，假设存了1百万的用户数据，可以拆分成200个key，每个key下面存放5000个用户数据
2. 如果bigkey不可避免，也要思考一下要不要每次把所有元素都取出来(例如有时候仅仅需要hmget，而不是hgetall)，删除也是一样，尽量使用优雅的方式来处理。

(2)【推荐】：选择适合的数据类型。
例如：实体类型(要合理控制和使用数据结构，但也要注意节省内存和性能之间的平衡)
反例：
set user:1:name tom
set user:1:age 19
set user:1:favor football

正例:
hmset user:1 name tom age 19 favor football

3.【推荐】：控制key的生命周期，redis不是垃圾桶。
建议使用expire设置过期时间(条件允许可以打散过期时间，防止集中过期)。