像 tinder 探探 这一类的左滑右滑用户是怎么排除的呢？

[whatisnew]

如果用 mysql NOT IN 排除的话基本不可行，这怎么做的呢？

[jjianwen68]

redis 缓存可能性更大吧

[gam2046]

这个更偏向业务设计问题，而不是技术问题。

未付费用户一天只能划限定的数量，假如是 100 个，业务低谷时期，查出来 100 个就完成了，今天随你怎么玩，都不查库了。

付费用户假设可以无限划，可以以安全名义限定超过 200 个以后，5 秒最多划一次，那么一天峰值也就不到 2 万个，也可以在业务低谷期预先查询出来。

---

以上为假设，实际情况中，由于用户在地理位置上会移动，所以预先查询所有结果集是可能性不大的。

但是由于位置的限制，每次查询并不需要在所有用户中做排除条件，因此实际上 NOT IN 的性能开销很可能是可以接受的。偏僻的地区，可能周围 5 公里就几千个人，闹市区也许就几万人？

[whatisnew]

@gam2046 这个很明显是不可行的。每天 100 个，100 天就是 10000 个，NOT IN 一万个用户 ID 很明显不可行。

[ic2y]

布隆过滤器？为每个正在活跃的用户，加载一个布隆过滤器，不喜欢的人，加入过滤器； 后续的推荐列表里，如果布隆过滤器命中，则不推荐，直接尝试推荐下一位；布隆过滤器存在一些误报的问题，概率很低，就当两个人没有缘分。

[HeapOverflow]

为什么不能整一个字典，直接看有没有目标用户的 uid

[cxe2v]

查询可用用户列表时候随机查，然后使用者账号这边有个记录了左滑右滑的列表项，在随机查出来的用户列表里如果在这个用户账户下有记录，则跳过这个用户

[monsterxx03]

一般是要提取用户特征, 比如 20 ~ 25 岁, 男性, 注册 7 天内, 爱好 xxx, 根据特征预计算出成百上千个 segment, 用户匹配的时候根据自己的特征去不同的 segment 里抽用户, 选择不喜欢, 可能只是在 userA->userB 的关系里记录一个负权重.
怎么及时得更新 user segment, 用户关系怎么存储都是个技术活, 高度取决于产品和运营策略.
sql not in 这种属于学生作业级别操作...有用户量的社交产品不可能这么高

[watzds]

在客户端去重也行吧，后端同步数据