@FaceBug 算作 2 条数据

@wuqingdzx 定时重建的话，还是会在某个时间段内，关系是保持久的关系。这种不实时的话。业务上是不能接受的吧。个人理解，勿喷。

@luozic 好的，去了解一下。感谢建议

@wangluofansi 确实，可能之前的思路上是有问题的。这个是历史问题，暂时来说，还不可能推翻重来。肯定是在当前的基础上看怎么能优化出来使用先。

@wuqingdzx 数据要求实时的，如果定期的话，中间的空档时间。相当于还是没有关系(变更必须在定时重建之后)。

@Aidenboss 这个建议很好，感谢感谢

@sadfQED2 好的，研究一下。感谢

@Dganzh 对的，场景大概是这个兄弟说的场景。

目前还是比较支持 13 楼的答案，当前来说。

7 楼的方案问题，13 楼也做了答复。

@yzbythesea 业务逻辑上是判断不出来两者是否有关系的，业务需求最后就是要查询这个人和其他人是否有关系。所以要去关系表查（实际上少数人有关系），此时。其他没有关系的人，因为 redis 命中不到关系数据就会一直打到 db 。此时为了解决这个问题，引入了 db 查询不到的情况下，设置一个 value 为 null 的值到 redis 中。此时就会导致 redis 有很多为 null 的对象（但是可能这个对象是热点对象）。比如有的人，总是被查是否和其他人有关系。

@linvon 问题是缓存命中不到时，就会去 db 查。这个时候就大多数流量都会命中不到。所以去 db 查。就会导致大流量打入 db 。

@Dganzh 是的，当前会在下次版本发布时候，降低这个时间。但是也只能逐步降低。步子太大会扯到蛋。

@lucienhsu 场景，大概就是人和人的点对点关系。可以理解为微博的好友添加。
但是，大多数时候人和人不需要点对点关系。但因为一些业务上的需要，需要在接口返回中有一个内容就是是否和其他人存在点对点关系。此时会不停的去查库。因为不存在关系，redis 也命中不到。此时穿透到数据库。但是不能使用布隆过滤器（这个关系可能随时变化，布隆过滤器不支持随时的变更->多写的场景）。因此做的操作是，给 redis 放一个值为空的对象进来。来防止穿透到 db 。但是因为这个关系是 N X N 关系。比如，有 100W 用户，那就是 100W X 100W
这个数据量上限来说，是非常大的

@gBurnX 目前配置是 128GB 的 redis，已经使用了 100GB 左右，key 的数量大概是 2 个多亿，不到 3 亿。

redis 失效时间，设置的是 3 天。（当前，预计在下一版本，降低失效时间到 2 天，逐步降低）

@Numbcoder 这个目前也是我们在做的。
已经做了，缩短过期事件，以及迁移到单独的 redis db. 同时已经在探索淘汰策略了。目前我们 redis 的大小是 128GB 。单独给这个业务使用。目前每天增长大概在 7GB 左右。目前来说，redis 满了之后。会出现部分打在 db 。

@xiaoxinshiwo 这个解决方案，其实是 ok 的。除了，服务会强依赖缓存，这个目前来看。应该是最好的解决方式了。
#_# 不过强依赖 redis 还是有点蛋疼。

@leopod1995
这个方案，有考虑过。这么做的话，相当于强依赖 redis （这样子设计是不是有点蛋疼）
相当于 redis == db 了。一切以 redis 为准。db 相当于只是一个数据的存档了。

@xx6412223 目前就是设置的空值

@shoushi 场景就是上述的场景。
就是有一个表保存了点对点的关系。但是线上大多数点和点之间是没有关系的。所以 90%会打到数据库（如果 redis 不做缓存穿透的处理）。
为了做缓存穿透的处理，在数据库查到位空时，在 redis 放了一个 key 等于参数，value 为空的值。但是，这部分值太多了。