浅谈APP流式分页服务端设计

1、传统Web式分页

web开发中常用的分页方式，根据页码进行分页。暂且称为Web式分页

根据页码pageIndex和分页大小pageSize进行分页。

-- offset = (pageIndex-1)*pageSize
select * from table limit offset,pageSize;

这种分页方式，在web中使用没有什么太大问题，但是在App分页中能否套用这种分页方式呢？

2、App上拉加载的流式分页

App流式分页

App上的分页方式从表现上看，基本都是上拉加载更多形式的流式分页。如果后台接口仍然按照Web式分页方式进行设计，会有如下问题：
a、数据重复

b、数据缺失

c、offset过大时查询效率低
MySQL的limit给分页带来了极大的方便，但数据量一大的时候，limit的性能就急剧下降。
由此可见，传统Web式分页接口并不适合App分页。

3、App流式分页服务端设计

a、cursor游标式分页

select * from table where id >cursor limit pageSize

优点：
1)、能够避免数据重复/遗漏
2)、limit性能不会cursor数值大小影响，性能稳定
缺点：
1)、适用于只是按照时间追加的方式的简单排序

b、按照时间分片缓存
非全量数据，只是部分热门数据，因为数据变化太快，可以基于时间段生成多个缓存。对于数据可以按时间段（5分钟）生成一个缓存分片。
具体流程如下：

按时间分片式缓存流程

此处的timestamp值，请求第1页数据时，timestamp传0，服务端检查timestamp<=0，就将当前系统时间赋值给timestamp返回，请求第2，3，...n页数据时，将系统返回的timestamp传入。
缓存的key是根据timestamp进行计算的，比如5分钟一个分片，key=list_201605231700。

if(timestamp>0){
  // 返回timestamp原值
}else{
  // timestamp=系统时间
}

应用场景

比如简书首页热门，只是一些热门文章，排序有一定的复杂性，且相对容易变动。

目前简书专题中列表排序是按照点赞数排序的，分页请求

出现了重复的数据，是因为该排序是实时数据，且没有游标，无法感知前面加载的数据。

c、id列表一次性下发给App

1、请求第一页数据之前先缓存所有id列表
2、请求每页数据时，只需带入相关的id列表参数

这种方式适用于id列表不会很大（数百条数据）的业务场景，例如腾讯新闻。