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=系统时间
}
应用场景
比如简书首页热门，只是一些热门文章，排序有一定的复杂性，且相对容易变动。
目前简书专题中列表排序是按照点赞数排序的，分页请求
//www.greatytc.com/collections/47/notes?order_by=likes_count&page=48
出现了重复的数据，是因为该排序是实时数据，且没有游标，无法感知前面加载的数据。
c、id列表一次性下发给App
1、请求第一页数据之前先缓存所有id列表
2、请求每页数据时，只需带入相关的id列表参数
这种方式适用于id列表不会很大（数百条数据）的业务场景，例如腾讯新闻。
