企业级架构下Redis存在的一些问题和解决方案

在企业级的互联网项目中，通常使用的是多级的缓存架构，如下的一个架构例子：

如上的这个架构存在这一些需要注意的问题， 这些问题也是通常使用缓存架构时都会遇到的问题，下面介绍了一些常见问题和解决方案：

缓存穿透

缓存存在的目的是为了保护后端， 让大量的访问请求都直接从缓存层返回数据，不用打到存储层的数据库里面去。缓存穿透就是大量的访问没有被缓存层有效的拦截，都直接访问到数据层去了。

通常导致缓存穿透的原因有：

1. 有人恶意的攻击，使用些不存在的产品代号，进行大量的访问，造成大量空命中。
2. 自身业务逻辑问题，造成大量的访问访的空命中

解决缓存穿透的方案：

1. 缓存空对象，将上次访问的空对象的key也缓存起来，下次相同的key来访问时，就不会打到后端
2. 使用布隆过滤器

布隆过滤器，就是定义一个很长的二进制的数组，每个数组的单元格存放一个二进制的位bit，值为0或者1. 当其值位1时表示，其的位数的值所对应的key在缓存中存在。

简单的说就是， 对于一个key，先进行hash，在对hash值取余后，往对应的位数上写1。其余的单元个保持默认0.

所以，当Boom过滤器存在说某个key不存在时，它肯定不存在，当boom过滤器说该key存在时，它不一定存在。注意布隆过滤器中的值是不能删除的，当有大量数据不一致时可以删除然后重新整个设置布隆过滤器。

使用布隆过滤其的简单实例：

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

Config config=newConfig();
config.useSingleServer().setAddress("redis://localhost:6379");
//构造Redisson
RedissonClient redisson = Redisson.create(config);
RBloomFilter<String> bloomFilter = redisson.getBloomFilter("nameList");
//初始化布隆过滤器：预计元素为100000000L,误差率为3%,根据这两个参数会计算出底层的bit数组大小bloomFilter.tryInit(100000000L,0.03);
//将zhuge插入到布隆过滤器中
bloomFilter.add("zhuge");
//判断下面号码是否在布隆过滤器中
System.out.println(bloomFilter.contains("guojia"));
System.out.println(bloomFilter.contains("baiqi"));

缓存击穿（缓存失效）

大量的商品信息在同一时间失效，就是一开始对每个缓存对象设置有效时间时都设置一样的，又在一个比较集中的时间设置了每个对象的有效值。

解决方案：

在位每个key设置有效时间的时候加一个随机时间，让他们失效的时间不一样。

缓存雪崩

缓存层遭遇超过预期的大量的请求，或缓存系统出现宕机。大量的请求会打到后台，后台的数据库支撑不住这么大量的请求，导致整个系统崩溃。

解决方案：

1. 使用Redis Sentinel/Redis Cluster集群保证系统的高可用
2. 使用Sentinel/Hystrix等限流工具对服务进行限流服务降级
3. 提前演练，在项目上线前提前预估将来可能遇到的访问请求数量级

热点缓存key重建优化

开发人员使用“缓存+过期时间”的策略，既可以加速数据读，又可以保证数据的定期更新，但是这个方式也存在一个问题：

即，当key是一个热点key当其失效时，会又大量的线程都来重建这个key，会导致DB负担严重。

解决方案，对应key的重建使用分布式锁来实现，字集群上值允许一个线程来重建key。

缓存于数据库双写不一致问题

即， 写数据库和写缓存中间存在时间差

解放军方案：

1. 加读写锁， 一旦又写操作的时候，加互斥锁，顺序执行。（影响效率）

2. 使用阿里开源的canal通过监听数据库的binlog日志即使取异步修改缓存。（增加系统复杂度，存在延迟）