1. 缓存的收益与成本

    1. 收益：

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

    2. 成本：

• 数据不一致问题，比如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;  
        }