翻页数据重复思考总结
翻页数据重复的原因
-
由于翻页的时候，数据头部新增导致。
-
eg：
当前数据 ：1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
第一次查询参数： offset 0 limit 10
第一次查询结果：1 2 3 4 5 6 7 8 9 10
数据变更
当前数据：21 22 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
第二次查询参数： offset 10 limit 10
第二次查询结果：9 10 11 12 13 14 15 16 17 18
数据9 10 就是重复数据
解决方案
-
快照方式
-
实现
- 定时去拉取全量数据，在服务器端缓存快照。
- 客户端请求的时候，带着快照版本，如果服务器端快照版本不一致，提示用户数据已变更，需要重新拉取。
-
缺点
- 当快照版本不一致的时候，需要提示用户重新去重新拉取数据。
-
适用场景
- 数据量小的场景。
-
-
客户端去重
-
实现
- 客户端查询数据之后，首先数据去重，然后再本地缓存。
-
缺点
- 占用客户端内存
- 客户端关心业务
-
适用场景
- 数据变化相对频繁，翻页不深的场景。
-
-
服务端去重
-
实现
-
每次请求带着uid和version_id,
-
服务端维护一个set
key type value 备注 xx_{uid}_{version_id} set {value} uid用户id version_id 版本id -
服务端对每次请求去重
-
-
缺点
-
需要额外使用redis，多一次网络io。
-
如果数据量比较大，redis有大key问题
-
服务延迟增加
-
- 适用场景
- 适用于数据量比较小的场景
-
-
请求带标识
-
实现
- 每次请求带着标识fromId和limit，查询根据标识能够过滤掉已经查询到的数据。
-
缺点
- 应用范围有限 例如新闻资讯feed流，根据时间标识来过滤已经翻过的页面。
-
适用场景
-
新闻资讯feed流等有明确标识可以过滤掉已翻页的数据。
-
-
