表关系描述
类似于好友之间的关联关系，有表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上的情况。
方案优化
- 优化Key的长度，降低内存占用；
- 慢慢缩短过期时间，直到DB能够承受的穿透查询量；
- 调整Redis的缓存淘汰策略，从noevication（默认，除了del请求，不会继续服务写请求）改为volatile-lru（淘汰设计了过期时间的key，最少使用的key被淘汰）；
- 加内存，硬件相对人力成本很便宜。
将Redis当做数据库
方案描述
因为N与N关系表是一个稀疏矩阵，按照10%的比例，数据大概在1000w左右，可以将Redis作为数据库，直接将1000W数据放入Redis中。
问题
- 缓存与数据库双写存在数据一致性问题;
- 业务变得更复杂，当业务数据量增长后，需要付出很大的迁移代价。
方案优化
针对问题1，可以通过订阅mysql的binlog，主动变更Redis的缓存。问题2是业务取舍，没有什么很好的办法。
使用布隆过滤器
布隆过滤器判断数据不存在，则一定不存在。判断数据存在，存在误判概率。
方案描述
对于新增的数据，写入Redis实现的布隆过滤器，删除的数据不进行处理。定时的重建布隆过滤器，例如每小时重建一次，那么在单位时间内删除量不是很大的情况下，打到数据库层的空请求请求不会很多。并且，全量的数据使用布隆过滤器，对于3亿的数据，内存只需要大概十几MB。额外需要再保证存在的数据也缓存一份到Redis中，如果有必要可以通过Guava做JVM级别的缓存。
判断逻辑如下
- 判断布隆过滤器中是否存在，若不存在，则返回；
- 布隆过滤器中存在，则判断Redis是否存在，若存在，则返回；
- 若Redis中不存在，则去数据库中查询。
问题
- 布隆过滤器重建需要扫描全表，对与数据量多的表来说，mysql的压力还是比较大；
方案优化
需要小心平衡布隆过滤器重建间隔与mysql的访问压力。若布隆过滤器重建时间间隔太长，则被删除的空数据还是会打入DB，若布隆过滤器重建时间间隔太短，全表查询扫描会对mysql造成压力。
