如何对按日期合并的两个不同数据源返回结果进行分页处理

方案1：游标分页（优先推荐，性能最高） #

这是最适配你的场景的方案，完全避免offset分页需要计算偏移量的痛点：

• 前端放弃传统offset/limit传参，改为每次请求带上上一页返回的最后一条数据的游标值（首次请求不传），游标值用排序时间+唯一id拼接，避免时间重复导致的数据错乱
• 后端收到请求后，对comments和likes两个数据源同时发起查询：如果是按时间倒序返回，就查时间 <= 游标时间（首次查询无游标就查全量时间范围）的limit + 1条数据，两个数据源都按相同的时间倒序、id倒序规则排序
• 把两个数据源返回的最多共2*(limit+1)条数据在内存中合并排序，取前limit条返回给前端，同时把第limit条的时间+id作为下一页的游标返回
• 额外多查的1条用来判断是否还有下一页，不需要返回给前端

这种方案每次只需要拉取极少量数据做内存合并，完全不需要全量拉取数据，也不需要做数据存储同步，分页偏移量再大也不会有性能衰减。

方案2：传统offset/limit兼容方案 #

如果必须要保留原有的offset分页参数，可以用冗余拉取+预估的方式实现：

• 先分别查询两个数据源的总条数，计算各自的占比，比如comments总共有6000条，likes总共有4000条，占比为6:4
• 当收到offset=N, limit=M的请求时，按占比计算两个数据源的偏移量，分别偏移N*0.6和N*0.4，各自拉取M*2条数据（拉取2倍冗余量抵消占比预估误差）
• 把两个数据源返回的最多共4*M条数据在内存中合并排序，找到对应offset位置的M条数据返回
• 如果合并后的数据量不足M条，再按缺失条数补拉对应数据源的后续数据即可

方案3：时间分片预统计优化（适合数据量极大的场景） #

如果两个数据源的总数据量超过百万级，可以加一层预统计逻辑降低每次拉取的数据量：

• 定时按小时/天粒度，统计每个时间窗口内comments和likes的条数，存在Redis或本地小型数据库中
• 收到分页请求时，先通过预统计的窗口数据，计算出offset对应的位置落在哪些时间窗口内，只拉取对应窗口范围内的两个数据源的数据合并即可，不需要拉取窗口外的数据

内容的提问来源于stack exchange，提问作者Rambo_with_bo