如果用 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
在客户端去重也行吧,后端同步数据
|