Redis优化

目录

缓存设计

缓存穿透 ：缓存穿透是指查询一个不存在的数据，查询将穿过缓存层到达db层。
造成缓存穿透的原因通常有两个：第一：自身业务代码问题。第二：一些恶意攻击或者爬虫。
缓存穿透的解决方案如下：
1、缓存空对象（伪代码如下）

String get(String key) { 
   // 从缓存中获取数据 
   String cacheValue = cache.get(key); 
    // 缓存为空 
    if (StringUtils.isBlank(cacheValue)) { 
     // 从存储中获取 
     String storageValue = storage.get(key); 
      cache.set(key, storageValue);
    if (storageValue == null) {  
    //要设置一个过期时间，万一之后的业务中用到了此key，避免以后查询该key一直结果为null
    
      cache.expire(key, 60 * 5); 
          } 
      return storageValue;
         } 
    else { 
         // 缓存非空 
          return cacheValue; 
        } 
    } 

2、布隆过滤器

可以使用redisson实现布隆过滤器。引入以下依赖

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

伪代码如下

//初始化布隆过滤器
RBloomFilter<String> bloomFilter=redisson.getBloomFilter("myFilter");
//根据自身业务初始化布隆过滤器：预计元素为100000000L,误差率为3% 
bloomFilter.tryInit(100000000L,0.03); 
static 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重构优化
场景如下：
1、当前key是一个热点key（例如一个热门的娱乐新闻），并发量非常大。
2、重建缓存不能在短时间完成， 可能是一个复杂计算， 例如复杂的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、就算并发很高，如果业务上能容忍短时间的缓存数据不一致(如商品名称，商品分类菜单等)，缓存加上过期 时间依然可以解决大部分业务对于缓存的要求。 3、如果不能容忍缓存数据不一致，可以通过加读写锁保证并发读写或写写的时候按顺序排好队，读读的时候相 当于无锁。
4、也可以用阿里开源的canal通过监听数据库的binlog日志及时的去修改缓存，但是引入了新的中间件，增加 了系统的复杂度。

开发规范与性能优化

BigKey问题
bigkey主要是指那些value占用空间特别大的key。
1、字符串类型：单个value值很大，超过10k
2、非字符串类型：体现在元素个数太多。
对于非字符串类型的bigkey一般不要使用del删除，可以借助hscan，sscan，zscan等命令进行渐进式分批删除。同时要注意bigkey的过期自动删除会导致线程阻塞。

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

产生原因
一般来说，bigkey的产生都是由于程序设计不当，或者对于数据规模预料不清楚造成的，来看几 个例子：
(1) 社交类：粉丝列表，如果某些明星或者大v不精心设计下，必是bigkey。
(2) 统计类：例如按天存储某项功能或者网站的用户集合，除非没几个人用，否则必是bigkey。
(3) 缓存类：将数据从数据库load出来序列化放到Redis里，这个方式非常常用，但有两个地方需 要注意，第一，是不是有必要把所有字段都缓存；第二，有没有相关关联的数据，有的同学为了 图方便把相关数据都存一个key下，产生bigkey。

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

客户端使用
使用连接池

 JedisPoolConfig jedisPoolConfig = new JedisPoolConfig();      
 jedisPoolConfig.setMaxTotal(5); 
 jedisPoolConfig.setMaxIdle(2); 
 jedisPoolConfig.setTestOnBorrow(true);
 JedisPool jedisPool = new JedisPool(jedisPoolConfig, "192.168.0.60", 6379, 3000, null);
 Jedis jedis = null; 
  try {  jedis = jedisPool.getResource(); 
  //具体的命令 
   jedis.executeCommand() 
   } catch (Exception e) {
 logger.error("op key {} error: " + e.getMessage(), key, e); 
 } finally {
 //注意这里不是关闭连接，在JedisPool模式下，Jedis会被归还给资源池。 
   if (jedis != null)  jedis.close(); 
 } 

1、maxIdle实际上才是业务需要的大连接数，maxTotal是为了给出余量，所以maxIdle不要设置 过小，否则会有new Jedis(新连接)开销。 连接池的最佳性能是maxTotal = maxIdle，这样就避免连接池伸缩带来的性能干扰。但是如果 并发量不大或者maxTotal设置过高，会导致不必要的连接资源浪费。

2、 如果系统启动完马上就会有很多的请求过来，那么可以给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 { 
      } 
 }