如何处理 api 分页导致的数据重复或丢失

[bigbyto]

我们的 api 目前是这样设计的

/users/?page=2&pre_page=20

客户端提交页数和每页的数量，服务端返回如下

{
   "code": 0,
   "pagination": {
      "page": 1,
      "limit": 20,
      "total": 100
   }
   
   "data": {}
}

不过这样会出现数据重复或丢失。比如当前用户正在 app 翻页刷新，如果正好在后台删除了一条消息，那么就会因为数据变化导致分页时有一条数据丢失了。

后来想到一个解决方案，通过 cursor 分页

/users/?cursor=2015-01-01 15:20:30&limit=10

上面就可以解决 app 端翻页时数据出现变化的情况，不过依然会有 2 个严重的问题。

1. 时间戳重复会导致永久丢失某条数据
2. 如果存在筛选条件(如饿了么按照经纬度排序获取数据)，此方法失效

对于第一个问题，我们想到使用主键作为过滤条件(主键递增),可以解决重复的问题。但第二个问题似乎想不出什么好的办法。

不知道大家怎么处理分页问题，有好的建议或方案还望不吝赐教。

[learnshare]

@dotudeth
@bigbyto 排序之后必须要拿第一页， itemId 是被忽略的

[814084764]

分页，连网易的微博都做不好，你还想做好？太天真了~ [手动滑稽]

[Magic347]

数据库读写不分离一下吗？

[NeinChn]

的确没有太好的办法吧...
一般都是用 SELECT * FROM table WHERE sort_field > last_id ORDER by sort_field LIMIT size.
要么就前端处理重复,后端每次多返回一些数据...

[alouha]

看 xx app 的分页那叫一个烂，之前遇到过你说的问题，当时偷懒，让客户端对重复数据进行处理 /捂脸

[JasperYanky]

题外话 强烈建议 下一页不要客户端拼参数，服务端的接口中直接指定 next url

[zvving]

一般都是按毫秒级的时间戳来分页的，别想太复杂

[kamal]

你看看豆瓣的评论怎么分页的

[zclzhangcl]

晚上刷百度贴吧时，发现贴吧的分页做的很差，经常连续很多都是前面已经出现过的。
这个问题不是那么好解决，或者说没那么重要

[bigbyto]

@zclzhangcl 目前看来还是无法用简单的方法去处理分页问题。不过像 feed 流这种业务场景，倒是可以用 twitter 的 since_id 和 max_id 来处理，因为 feed 数据本身就是有序的(发布时间)。不过一旦出现其他排序条件，普通的方法还是得跪。

[bigbyto]

@JasperYanky 为什么不要客户端拼参数呢? 这一版的 api 我们目前还没正式使用，目前打算服务端返回一个"next"字段取代"page"，当然还是由客户端这边提交过去。

[whow]

取排序后分页最后一项，将参与排序的字段拼接成一个 next ，客户端下次请求的时候把 next 作为参数回传到服务端，服务端通过这个字段计算出下一页。
```
?next=&size=
```
```
{
list:[],
next:""
}
```

[mrliusg]

逻辑删除，然后返回给客户端的时候不显示出来就好了吧？
或者直接在服务端删除，请求 20 条数据，只返回 19 条就好啦

[jyf]

多少无关紧要 请求 20 条 返回 22 条和 17 条都没什么大的关系 逻辑上没有问题就好了

对于用户过滤这种可以考虑第一页的时候就把结果的主键给放 redis 的 sortedset 里 后面如果新增可以在缓存期内无视 而删除则无非是多了一个而已

[yidinghe]

分页逻辑天然就有这个问题，最好的方式是接续查询，用上一页最后一条记录作为查询下一页的条件，这样查出来既不会多也不会少。

[JasperYanky]

@bigbyto 我倾向 所有需要分页的 API 外层都有一个 next 字段，里面是下次页的 url ；至于为什么不要客户端拼，很简单，你要是这个版本按照 id 分页 下个版本按照时间分页， API 能分分钟改掉并且完全不影响客户端~

[owt5008137]

你就不能给每条消息分配一个 ID ？然后拉到的消息和已有的 ID 相同就 update ，否则才 insert ？

[zclzhangcl]

@mrliusg 你这种处理方式会有问题，返回的总数与实际数量不符。对于一些严格的场景，这样是不行的。
如果需要严格的话，还是按 @yidinghe 的方式来。