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

96
江湖一键飘
0.2 2016.05.23 18:42* 字数 697

1、传统Web式分页

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=系统时间
}
分片缓存请求处理过程

应用场景

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

简书首页热门

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

http://www.jianshu.com/collections/47/notes?order_by=likes_count&page=48
简书专题页列表分页传参

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

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

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

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

架构设计