几种常见的API接口分页方案

妖狐艹你老母 2023-10-08 22:11 14阅读 0赞

#### 文章目录 ####

*   *  1 概述
     *  2 分页方案
     *   *  2.1 基于偏移量
         *  2.2 基于游标
     *  3 重复数据处理
     *   *  3.1 基于时间
         *  3.2 基于热度
         *  3.3 基于推荐

### 1 概述 ###

列表是互联网产品中很常见的一种内容排列形式，而且列表的数据集往往成千上万，一次性返回全量数据集的场景几乎不存在，所以出现了数据分页的需求。本文将总结常见的列表样式以及接口分页设计相关问题。

### 2 分页方案 ###

常见的列表样式有卡片流、瀑布流、信息流等，我们可以总结为两种分页方式：

*  **传统分页**：通过显示的页码查询指定页的数据，多用于 PC 端数据变化不频繁的列表展示。
 *  **流式分页**：通过滚动方式隐式加载更多的数据，适用 PC 和移动端大多场景。

#### 2.1 基于偏移量 ####

基于偏移是最常见的分页接口设计，其原理是通过页号和页大小指定某一分页的数据。例如：

// 请求
    {
        
      "page": 2,
      "count": 10
    }
    // 响应
    {
        
      "data": [],
      "total": 100
    }

具体到数据库可以通过 offset + limit 实现：

select xxx from xxx where xxx order by xxx limit $count offset ($page-1)*$count;

或使用内存分页：

list = list.stream()
        .skip((page-1)*count)
        .limit(count)
        .collect(Collecters.toList());

这种方案比较适合传统显示分页场景，有点是实现起来简单，支持分页跳转，支持向前、后翻页。

缺点也比较明显，主要来自两方面：

1.  慢查询：通过数据库 `limit` 和 `offset` 实现的分页性能较差，偏移量越大越明显。
2.  动态数据：偏移量方案对数据变动支持也差，数据的插入或删除可能会导致数据重复或跳过，比如用户在查看第 10 页内容，此时第 1 页一条数据被删除，此时整个列表会往迁移，这会导致第 11 页跳过了 1 条数据。

#### 2.2 基于游标 ####

基于游标（cursor）的分页设计适用于动态数据场景，其原理是根据已获取的最后一条数据的 ID 作为参数来请求下一页数据。例如：

// 请求
    {
        
      "cursor": "2",
      "count": 10
    }
    // 响应
    {
        
      "data": [],
      "nextCursor": "3",
    }

实现游标有很多方法，对于有自增主键 ID 的数据库表来说，按 ID 排序分页的实现比较简单，可以直接使用主键 ID 做 cursor：

select xxx from xxx where xxx and id>=$cursor limit $count+1;

*这里有一个小技巧，可以每次分页查询都多查询一个元素作为 nextCursor 使用，同时可以用来判断是否有剩余数据。*

游标分页方案优点就是性能好，对数据变动也有较好支持，不会因为数据的插入或删除导致数据重复或跳过。缺点是不能像偏移量方案可以任意跳转指定页，往前翻页也需要特别处理。

### 3 重复数据处理 ###

#### 3.1 基于时间 ####

比如我们的微信朋友圈或者微博关注列表，是基于一个维度固定排序的。此类场景中数据只会从最后新增或删除，因此只需要维护好每个用户或 Session 维度的缓存即可。

由其朋友圈关系类数据，由于用户朋友关系数量的限制，完全可以在用户发布动态时以写扩散的方式讲数据分别写入对应朋友的朋友圈数据列表。为了提高该列表的性能，此列表除了使用 MySQL 等数据库持久化外，还可以使用 Redis 的 Zset 数据结构进行高效的缓存。

#### 3.2 基于热度 ####