流式分页

https://aotu.io/notes/2017/06/27/infinite-scrolling/index.html

https://www.jianshu.com/p/13941129c826

分页类型

分页一般用于对信息列表进行分段。根据具体功能及交互方式的不同，大致可将分页分为两种类型：传统分页和流式分页。

传统分页

传统分页多用于 PC 页面，最常见于搜索结果页，如我们常用的搜索引擎Google：

而在移动端页面中，限制于点击区域的大小，因此较少使用传统分页。

结合上述例子，我们可分析出，传统分页有如下几个特点：

• 通过页码进行分页

• 通过点击上/下页按钮可实现页面切换

• 通过点击页码可实现页面切换

• 可直接跳转至指定页面

• 多用于 PC 端

流式分页

流式分页在 PC 端和移动端都有使用。

PC 页面可用于对多个商品信息的展示，通过滚动的方式加载更多商品信息，如：京东首页还没逛够、发现好货等。

而 H5 中，通过点击/上拉的方式来加载列表信息，也是很多见的，如京东首页为您推荐

就是使用点击加上拉的方式：

结合上述例子，我们可分析出，流式分页有如下几个特点：

• 通过滚动/上拉/点击等方式加载新一页

• 无页码

• 无上/下页按钮

• 不可跳转至指定页面

• pc端和移动端均有使用

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

数据重复数据缺失offset过大时查询效率低

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

App流式分页服务端设计

cursor游标式分页

select * from table where id >cursor limit pageSize

优点：

1. 能够避免数据重复/遗漏

2. limit性能不会

3. cursor数值大小影响，性能稳定

缺点：

1. 适用于只是按照时间追加的方式的简单排序

按照时间分片缓存

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

按时间分片式缓存流程：

此处的timestamp值，请求第1页数据时，timestamp传0，服务端检查timestamp<=0，就将当前系统时间赋值给timestamp返回，请求第2，3，...n页数据时，将系统返回的timestamp传入。

缓存的key是根据timestamp进行计算的，比如5分钟一个分片，key=list_201605231700。

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

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

id列表一次性下发给App

1. 请求第一页数据之前先缓存所有id列表

2. 请求每页数据时，只需带入相关的id列表参数

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