Redis缓存穿透案例

表关系描述

类似于好友之间的关联关系，有表N，M以及N与M的关联关系表，N表与M表假设均有100W的数据，M与N两者关系是一个稀疏矩阵（只有少部分之间有关系，大约10%）。

业务场景

通过表N中的一条记录，来查询关联的M有哪些人，并且这是一个高频次操作。

存在的问题

mysql单库承受如此多的查询请求，容易拖垮整个库。

解决方案

以下解决方案的目的是为了过滤掉空查询。

Redis设置空值

方案描述

在查询到N与M关联关系表中的空值时，就往Redis存储一个空值，设置一个的过期时间（固定时间+随机时间），大约是3天。

问题

这个关系的N*M，需要把所有的空值都放进去，按照假设的数据量，极限情况下Redis中需要存储100W * 100W的数据，这个数据量是很大的。按照实际项目预估值，Redis大小是128G，每天增长在7GB左右，Redis满了以后，会出现部分打在DB上的情况。

方案优化

1. 优化Key的长度，降低内存占用；
2. 慢慢缩短过期时间，直到DB能够承受的穿透查询量；
3. 调整Redis的缓存淘汰策略，从noevication（默认，除了del请求，不会继续服务写请求）改为volatile-lru（淘汰设计了过期时间的key，最少使用的key被淘汰）；
4. 加内存，硬件相对人力成本很便宜。

将Redis当做数据库

方案描述

因为N与N关系表是一个稀疏矩阵，按照10%的比例，数据大概在1000w左右，可以将Redis作为数据库，直接将1000W数据放入Redis中。

问题

1. 缓存与数据库双写存在数据一致性问题;
2. 业务变得更复杂，当业务数据量增长后，需要付出很大的迁移代价。

方案优化

针对问题1，可以通过订阅mysql的binlog，主动变更Redis的缓存。问题2是业务取舍，没有什么很好的办法。

使用布隆过滤器

布隆过滤器判断数据不存在，则一定不存在。判断数据存在，存在误判概率。

方案描述

对于新增的数据，写入Redis实现的布隆过滤器，删除的数据不进行处理。定时的重建布隆过滤器，例如每小时重建一次，那么在单位时间内删除量不是很大的情况下，打到数据库层的空请求请求不会很多。并且，全量的数据使用布隆过滤器，对于3亿的数据，内存只需要大概十几MB。额外需要再保证存在的数据也缓存一份到Redis中，如果有必要可以通过Guava做JVM级别的缓存。
判断逻辑如下

1. 判断布隆过滤器中是否存在，若不存在，则返回；
2. 布隆过滤器中存在，则判断Redis是否存在，若存在，则返回；
3. 若Redis中不存在，则去数据库中查询。

问题

1. 布隆过滤器重建需要扫描全表，对与数据量多的表来说，mysql的压力还是比较大；

方案优化

需要小心平衡布隆过滤器重建间隔与mysql的访问压力。若布隆过滤器重建时间间隔太长，则被删除的空数据还是会打入DB，若布隆过滤器重建时间间隔太短，全表查询扫描会对mysql造成压力。