类似微博抖音评论分页的简单设计与实现

最近在做一个评论分页的实际问题

假设以点赞数排序， 有page_index ，以及 每个评论有个id

我们假设以每一页的最后一个id在zset中的rank作为left ， rank+page_size 为right， 那么

对于实时的分页来说，存在这么一个问题

假设前端已经获取了列表1:

comment-1

comment-2

comment-3

comment-4

comment-5

当c5 和 c4 的位置发生了变换时，c4 会重复出现一次,这是问题1 

假设有

page_1:

c1

c2

c3

c4

c5

page_2:

c6

c7

c8

c9

c10

现在假如c5 和c8交换了位置，那么c6、c7 就丢失掉了。这是问题2

同理如果只以page_index 和 page_index 分页也会有类似的问题

 

 

想了一个解决方案：我们必须引入 点赞数x，且需要对点赞数相同的评论做一个id的排序

前端需要传一个id + 点赞数x，

我们需要维护的数据结构是： 点赞数第一优先级、id作为第二优先级(简单的实现方式可以是 score=点赞数.id )

获取到x 之后，我们可以先判断这个点赞数的位置，再根据id 去往后筛选page_size 个评论。

但这样存在一个问题就是：

如果该评论c5被取消点赞了，导致排名下降了很多，那么他在后面又会出现一次，如果是在page_index + 2以上的页面，就无法筛掉，这个该怎么解决呢？

或者 c4、c3、c2 被取消点赞，掉了很多排名，也会出现这种情况。

 

这样的话，看起来有两种处理方法： 一种是摒弃掉实时刷新的机制、换成5分钟或者十分钟刷新一次 第二种是 由于点赞数会变，所以不将其加入到排序规则中

调研一下抖音的功能可以发现：

前几个是热度（点赞数）最高的，这几个应该是没做分页直接拿的、 后面几个按时间从新到旧来展示（按时间做分页由于时间不会变，所以完全没有重复或丢失的问题)

 

2019-6-26 续

做的时候发现来几个问题

1 用 select * from xxx where id > x limit page_size 可以做sql分页查询，这样没有走redis ，所以我在想这个是否足够快，而且给数据库的压力是否足够小，需要压测和上限看看实际效果

2 如果走缓存，那么zset里面怎么load数据 ， 如果load所有评论，则必然有一个慢查询，这是我不想要的

如果只load一部分，那么做分页写起来挺麻烦的，需要for循环去找到属于那个部分，再查询，不够还需去下一个部分查询