使用 Java +mysql+redis 实现一个简易的类似随机的数据获取算法，有哪些比较好的方案？目前我都有点怀疑需求是不是有问题了。

• 資深大佬 : awanganddong

  将视频列表整个加载到 redis 内存中，
  然后用户已浏览记录也放入内存中，求这两者之间的差集。
  然后对差集进行排序。

  这里边时间与空间复杂度没考虑。

• 資深大佬 : zxCoder

  问题描述没看懂

  直接按你原来的方案然后存下标不行吗

  1 2 3 4 5 6 7 8 9 10
  7 1 9 2 3 5 4 10 6 8

• 資深大佬 : ylrshui

  笨方法：为每个用户维护一个未查询列表

• 資深大佬 : MoYi123

  我用 pg 尝试过类似的功能，用 hll 存用户看过的视频，和你的需求应该差不多 https://github.com/mmooyyii/mmooyyii/blob/master/docs/database/tiplist1.md

• 資深大佬 : lpts007

  上次在 V 站看到的，用户 id 哈希后 mod 视频数量，每次顺着取，记录下每个用户当前值。完事。

• 資深大佬 : zieglar

  redis 的 sdiff 命令，比较 set 返回差异值

• 資深大佬 : renmu123

  我提供一个非技术的方法。
  遇到这种事就直接怼回去，就说以现在技术水平做不到这件事，如果硬要做可能会产生性能问题。如果产品还在强硬，就把两人的聊天记录都整理好保存到项目软件中（以防之后出现问题倒打一耙），然后公开艾特你的老大和他以及他的老大说明其中问题，如果觉得没问题，那你就按他说的做。这样基本能保证之后就算出问题你也不用背锅，如果你的老大够给力会直接帮你怼回去。

• 主 資深大佬 : CandyMuj

  @renmu123 多谢，也是挺有用的一个办法，所有类似的事都可以这么处理的，做可以，出了问题我不负责，而且我之前也明确说过会出问题。遇到这种事是需要保存一些证据，尽量让自己少担责。如果遇到通情达理或者懂点技术的上级可能没问题。
  如果遇到不懂技术或者也不通情的上级，然后产品或上级给你来一句：“这不就是你该做的事吗？做不了两全其美，那就是你技术有问题。” 这就把我整蒙了啊。

• 主 資深大佬 : CandyMuj

  @MoYi123 谢谢

• 主 資深大佬 : CandyMuj

  @MoYi123 是挺类似的，学习了

• 資深大佬 : yzbythesea

  可以在手机端处理。App 缓存客户的视频列表然后在本地保存一个 bloom filter 记录客户看过的视频。到时候直接选择不在 bloom filter 里的视频 ID 然后向后台发送请求。

• 主 資深大佬 : CandyMuj

  @awanganddong 数据全都加载到 redis，如果只是记录 id 的话，那么在用 Sql 进行查询的时候可能不太方便的，而且数据还会存在频繁的增删操作，应该还是得以 mysql 为核心的。

• 資深大佬 : yzbythesea

  另外就是增加 redis 台数，反正你这个是可以很轻松地横向扩展的。我觉得钱到位，产品说得这个方案是推荐做法，也没有任何性能担忧。

• 主 資深大佬 : CandyMuj

  说一下和另一个同行进行讨论后的一个大致可行方案吧，使用最笨的办法，单独使用一张表记录用户观看过的视频（就类似一个观看记录的功能）；建立好索引，即使数据量很大速度也不会太慢；
  主要问题就是在用户看完所有视频后需要清除之前已看的数据重新记录，在删除的时候需要重建索引，为了不影响用户正常使用，可以使用队列或者 redis 发布订阅来进行异步的删除，这样数据就存在延迟，就可能出现我一边在插入一边在删除的情况，查询也存在问题（本应该从头开始查，但此时还没有删除之前的观看记录，因此实际查询的时候还会剔除之前已观看的）。
  解决这个的办法就是在往队列插入删除任务的时候同时记录需要删除的历史观看记录的最大 id，在删除的时候就通过 userid=? and historyId <= ?，如果数据量大可以进一步优化，进行分批删除。
  还有个问题就是管理员如果修改了精选视频的排序，是否需要用户实时展示最新的排列顺序，即是否也要清空观看记录的问题或者其他的处理方式（例如，只清除所有用户历史记录中管理员新设置精选的视频 id，让这些视频可以被用户再次查询，此时就不考虑重复问题，因为设置精选就是为了增加曝光量）。如果不考虑这一点的话就不用管了

• 資深大佬 : rrfeng

  先实现：根据上次访问的 lastid 分页

  再实现：精选的 lastid

  拼在一起即可。

• 主 資深大佬 : CandyMuj

  @zieglar 谢谢，和一的方法类似 需要数据在 redis 才好操作，因此筛选出 id 后使用 sql 操作存在性能问题，应该以 msyql 为核心

• 主 資深大佬 : CandyMuj

  @rrfeng 谢谢，最开始就是这个，主要问题就在于这个数据的顺序会变，如果顺序不变就没问题 可以看看 14 的方案

• 主 資深大佬 : CandyMuj

  不一一回复了，感谢所有回复的朋友，好的方案我会学习一下的，谢谢啦！ ^^

• 主 資深大佬 : CandyMuj

  @rrfeng 不过维护两个 lastid 这个想法挺不错的，是一个好的想法，谢谢。

• 主 資深大佬 : CandyMuj

  @ylrshui 笨方法有时反而是最有效的方法，只要优化的好也能成为好的方法，哈哈哈！
• 主 資深大佬 : CandyMuj

  @yzbythesea 这种方式用 sql 查询的时候会用到 in(id1,id2,ids…)，这样的话不走索引的，或者有什么方法可以替代 in 么？而且这种操作一般都不会在 app 端做处理的。

• 主 資深大佬 : CandyMuj

  @CandyMuj 还有一点，记录历史记录的时候是每次查询都记录视频 id，但是查询由于是分页的，在查询的时候需要加一个限制 historyId <= 第一页查询时的最大历史记录 id,不然就会出现下面的问题
  有数据 id：1 2 3 4 5 6 7 8 9 10
  首次查询不剔除数据
  第一页：limit 0,2 => 1 2 3 4
  记录看过的：1 2 3 4
  第二页查询：
  此时就剔除 1234：5 6 7 8 9 10
  查询：limit 2,2 => 7 8

  就会导致有些数据是被直接跳过了

• 主 資深大佬 : CandyMuj

  @CandyMuj 还有一点，记录历史记录的时候是每次查询都记录视频 id，但是查询由于是分页的，在查询的时候需要加一个限制 historyId <= 第一页查询时的最大历史记录 id,不然就会出现下面的问题
  有数据 id：1 2 3 4 5 6 7 8 9 10
  首次查询不剔除数据
  第一页：limit 0,2 => 1 2
  记录看过的：1 2
  第二页查询：
  此时就剔除 1234：3 4 5 6 7 8 9 10
  查询：limit 2,2 => 5 6

  就会导致有些数据是被直接跳过了

• 資深大佬 : zieglar

  @CandyMuj 其实都使用 redis 操作是可行的，首先维护好 redis 里对应的影片列表，在排序、新增、修改以后都同步到这个列表里，然后每个用户两个列表，一个是已看，一个是未看，初始数据时影片列表同步到未看，然后用 spop 来获取未看列表数据输出为 A 列表，然后把看 A 列表数据同步到已看列表里，后面的操作是当影片列表发生变化时，影片列表和已看进行 sdiff，把差异值覆盖到未看去，这样每次从未看拿到的数据符合影片列表的最新排序，且根据 A 列表数据也可以对从数据库的记录进行排序，并不觉得这样根据 ID 来搜索 mysql 的数据会早层什么性能问题

• 資深大佬 : YouLMAO

  标题写随机，内文没有，骗子

• 資深大佬 : xyjincan

  头一次见这么详细的说明帖子，管理员操作信息直接维护在列表数据库，用户已读数据单独建表，

• 資深大佬 : hma

  @CandyMuj #17 可以把精选列表独立出来。再记录精选的已阅列表。

• 資深大佬 : yzbythesea

  @CandyMuj 直接用 redis 存用户看不过没有？ App 端还真有类似做法。

• 資深大佬 : lldld

  还是需要对每个用户存储其看过的视频, 但是每个 id 都记不合适.

  大部分情况下, 给用户展示的视频是按 id 排序的, 少部分是随机的(精选).

  记录的 id 也分两种形式, 比如 [1, 30], [40, 48], {51, 72, 99} 表示看过 1~30, 40~48, 以及 51, 72, 99.

  那么当下要推荐给用户的视频, 应该是优先推荐精选, 然后就是以缩短上面的记录为原则.

  比如今天的精选是 {200, 210, 22}, 然后首页需要 5 个视频, 那么再补上 49, 50 比较好.
  sql 就是 select id in [200, 210, 22, 49, 50]

  这样新的记录变成 [1, 30], [40, 51], {72, 99, 200, 210}

• 主 資深大佬 : CandyMuj

  @YouLMAO 我说了这是一个类似随机的方案，因为直接采取随机的话，会出现重复的数据，不满足需求。如果想实现随机+不重复 你可以在取数据的时候进行随机获取并踢除已看视频，如果数据不足一页就一次查询多页，查询多页需要注意一个问题，看第 23

• 主 資深大佬 : CandyMuj

  @yzbythesea #28 我没有这样处理过

• 主 資深大佬 : CandyMuj

  @zieglar #24 这样确实也可以，谢谢你的思路。
  如果把数据全部维护到 Redis，个人不太喜欢这样的处理方式。
  处理方式挺不错的，如果后续有其他需求可以用到这个思路！

• 主 資深大佬 : CandyMuj

  @yzbythesea #28 关于用户一般就是存个 token，缓存一些用户数据，直接用 Redis 当用户表就没玩过了

• 主 資深大佬 : CandyMuj

  @hma 后续会考虑这方面的优化，谢谢！

• 主 資深大佬 : CandyMuj

  @xyjincan #26 最开始就是打算的这个方案，可能我当时技术欠缺或者没想到如何优化性能，然后就不打算采取这个方案。现在有了性能优化方案以及整个查询逻辑的细节处理方法，就可以用啦。

  问题不描述清楚，我光解释就要解释半天。

• 主 資深大佬 : CandyMuj

  @lldld 感谢，好的想法，学习到了！ ^^

• 主 資深大佬 : CandyMuj

  @lldld #29 暂时先记录所有吧，先出一个可以用的，然后再优化吧，这种不记录全部 id 的想法很棒！

• 主 資深大佬 : CandyMuj

  @YouLMAO #25 并且，我这是一篇求助帖，而不是教程帖。

• 資深大佬 : zxyroy

  我突然有个想法，既然没有要求每个用户顺序不能一样，不如直接生成一个乱序列表，每个用户都按这个乱序列表返回，新视频就攒 10 个再乱序追加到最后。每当有用户 load 完其中一个列表就再创建一个。每个用户一定要 load 完一个列表才能进入下一个。

• 資深大佬 : kkkkkrua

  给个 sort 列，专门用来排序，好像就可以解决你 id 乱序的问题吧

• 資深大佬 : qingluo

  redis 有一个 hyberloglog 的数据结构 可以做做参考

• 資深大佬 : Nillouise

  没详细看题目，但我考虑过类似的问题，即信息流推荐，因为信息的内容是实时更新的，所以什么生成固定序列，其实不是个好办法，无法处理这种情况，也无法处理不同信息有权值的情况。

  网上我看到有文章说，记录最多用户看过的 10000 个信息，然后直接过滤这 10000 个信息即可。

• 資深大佬 : pushback

  order by RAND()
  MySQL 无所不能

• 資深大佬 : simonlu9

  自己用 redis 有序集合存吧，优先推荐那些就把权重提高一点，我是用 es 做的，可以满足很多需求

• 資深大佬 : thinkmore

  我有一个想法。把所有数据分配到一个环中。

  然后给每个用户随机分配一个在环中的起始点。

  当有精品视频时，就将这些排序好的重新构成环即可

  @CandyMuj

• 資深大佬 : OldCarMan

  不知道，你说的不重复是什么样的时间频率，如果是每一天保证不重复（或者隔多长时间保证不重复）并且只靠 mysql 实现的话，加一个用户浏览记录表，然后每次查询加上一个 not in 之类的，最后加个定时任务，定时删除该频率内产生的这些记录数据。

• 資深大佬 : auh

  依赖 mysql 是没办法实现这种乱序操作的，必然带来 msyql 的压力。
  视频记录必须 load 到 redis 。

  分页，这种分页，本质上不是分页。而是单纯的下一批。
  每页 10 个。就读取 redis 集合存储的 Vid10 个。

  如果视频没有时效性，直接顺序读取 redis 列表就行。只为每个用户记录一个游标，因为对用户来说，用户感知不到随机性。兼容竞选列表也很简单。单独处理精选列表逻辑。合并两个结果集，保证一页总共 10 个就行了。

  如果视频具备特殊属性。不仅是时效性。可能就需要，为每个用户记录已读列表了。
  这个时候，优化的话，如果可以，对视频列表进行分片，用户读完一片之后，不需要再关心之前的片了。已读列表就很小了。
  如果分片不了，相当于用户面向的是整张视频表的随机。这种必须完整记录。但是，现在可以考虑针对用户分组。不同组群的用户共享一个已读列表。每个用户只持有游标。内存就又少了。

  ok 。不废话了。具体情况，具体分析。因为你遇到的可能比你描述的复杂的多。

• 資深大佬 : fkname

  1.建议客户端做随机操作，这样可以大大减少服务端的计算
  2.如果用新表存储已读记录，可以做逻辑删除，这样不会有重建索引的问题。当然插入时需要修改为 insertOrUpdate 方式

• 主 資深大佬 : CandyMuj

  @fkname #48 感谢，是个很好的办法！

• 主 資深大佬 : CandyMuj

  @auh 谢谢

• 主 資深大佬 : CandyMuj

  @auh #47 万分感激，我还一直在分页这里面琢磨。。。 实际上这里就是分批次拿数据，都不应该叫做分页了！