这是一个创建于 1370 天前的主题，其中的信息可能已经有所发展或是发生改变。
如果用 mysql NOT IN 排除的话基本不可行，这怎么做的呢？
 |
1
jjianwen68 2021-03-23 16:49:49 +08:00
redis 缓存可能性更大吧
|
 |
2
gam2046 2021-03-23 17:01:10 +08:00
这个更偏向业务设计问题，而不是技术问题。
未付费用户一天只能划限定的数量，假如是 100 个，业务低谷时期，查出来 100 个就完成了，今天随你怎么玩，都不查库了。 付费用户假设可以无限划，可以以安全名义限定超过 200 个以后，5 秒最多划一次，那么一天峰值也就不到 2 万个，也可以在业务低谷期预先查询出来。 --- 以上为假设，实际情况中，由于用户在地理位置上会移动，所以预先查询所有结果集是可能性不大的。 但是由于位置的限制，每次查询并不需要在所有用户中做排除条件，因此实际上 NOT IN 的性能开销很可能是可以接受的。偏僻的地区，可能周围 5 公里就几千个人，闹市区也许就几万人？ |
 |
3
whatisnew OP @gam2046 这个很明显是不可行的。每天 100 个，100 天就是 10000 个，NOT IN 一万个用户 ID 很明显不可行。
|
 |
4
ic2y 2021-03-23 17:19:32 +08:00
布隆过滤器？为每个正在活跃的用户，加载一个布隆过滤器，不喜欢的人，加入过滤器； 后续的推荐列表里，如果布隆过滤器命中，则不推荐，直接尝试推荐下一位；布隆过滤器存在一些误报的问题，概率很低，就当两个人没有缘分。
|
 |
5
HeapOverflow 2021-03-23 17:59:43 +08:00 via iPhone
为什么不能整一个字典，直接看有没有目标用户的 uid
|
 |
6
cxe2v 2021-03-23 18:20:11 +08:00
查询可用用户列表时候随机查，然后使用者账号这边有个记录了左滑右滑的列表项，在随机查出来的用户列表里如果在这个用户账户下有记录，则跳过这个用户
|
 |
7
monsterxx03 2021-03-23 18:23:10 +08:00
一般是要提取用户特征, 比如 20 ~ 25 岁, 男性, 注册 7 天内, 爱好 xxx, 根据特征预计算出成百上千个 segment, 用户匹配的时候根据自己的特征去不同的 segment 里抽用户, 选择不喜欢, 可能只是在 userA->userB 的关系里记录一个负权重.
怎么及时得更新 user segment, 用户关系怎么存储都是个技术活, 高度取决于产品和运营策略. sql not in 这种属于学生作业级别操作...有用户量的社交产品不可能这么高 |
 |
8
watzds 2021-03-23 19:20:41 +08:00 via Android
在客户端去重也行吧，后端同步数据
|
Select Language