从服务端加载分页数据的策略

我在查阅如何优雅地处理分页数据的时候偶然看到了这篇文章。说实话，本来只是想查查客户端在处理分页加载的数据时候怎么对请求进行封装，而不是每次面对分页数据都要额外写一大堆代码，但是这篇文章提到的问题是我之间没有考虑到的，觉得不错，就斗胆翻译一下。

说明一下，这篇文章到的本意是针对推特的时间轴的，时间轴里面由很多Tweets组成，我其实不太明白这到底是什么数据，所以文章后头就把Tweets都用数据进行替换了，主要学习的是这种避免读到冗余数据的策略，当然文末也说了，这种策略只适用于有序的数据集，若是乱序的，可能需要其他的解决方法。

转载出处：https://dev.twitter.com/rest/public/timelines

处理时间轴（Working with timeline）

简介

推特的API有一些方法，如 GET statuses / user_timeline， GET statuses / home_timeline和 GET search / tweets，这些接口会返回一个Tweet数据的时间轴。这个时间轴可能会非常的长，所以客户端在进行单次请求的时候请求的时间轴数量就有一个限制，因此客户端应用必须遍历时间轴结果来构建一个更为完整的列表。

因为推特的实时性和大数据的特性，可能会有大量的数据不断地添加到时间轴里，普通加载分页数据的方法可能是无效的，这篇文章的目的就是向您展示推特的开发人员在进行结果集分页时可能面对的问题，并给出处理这种问题的最佳实践方法。

分页存在的问题

在理想情况下，分页是一个非常同意实现的问题。假设这条时间轴有10条按时间倒叙排列的Tweets，一个应用可能尝试通过分两页加载，每次加载5条数据的方法去读取整条时间轴，如图所示：

那么问题来了，推特的这条时间轴可能不断地有新的元素添加进来，在先前那种加载策略下，如果读取第一次数据和第二次数据之间，时间轴又添加进两条数据，那么第二次请求的结果将会包含第一次请求已经得到的两条数据，如图所示：

事实上，如果有5条或是更多的数据在两次请求之间被添加进来，随后的请求可能最终得到的都是之前请求已经得到的数据，这就会使整个API请求完全冗余。

添加一个max_id参数

上述问题的解决方法是通过对处理的数据流添加一个标识，而不是一直相对于列表顶部的位置来取数据（列表顶部可能经常会改变），应用应该把处理过的最后一条数据作为参考点，这就需要在请求时添加一条max_id的参数。

为了正确使用max_id，在第一次请求数据时，提交的参数只包含一个count也就是请求数据的数量，在处理这条数据和随后的响应之后，持续追踪最后收到这条数据的id，这个id将被作为下一次请求的max_id，使服务端只返回这条数据（包含这条数据）之后的数据，值得一提的是，如果max_id所对应的这条数据被包含了，那么也会造成数据的冗余，如下图所示：

为具有64位的环境优化max_id

虽然仅仅一条冗余的数据不是非常影响效率，但是如果你处于64位的环境下，依然有可能在处理这个问题时优化max_id的策略，如果一个数据的ID不能被表示为一个具有64位精度(比如JavaScript)的整数，则应该跳过这一步，从上一个请求中的到的最后一条数据的id再减去1作为下一次请求的max_id，即时这条id并非有效也无关紧要，这个值只是决定去过滤哪些数据，如果以这种方式调整，可以避免读到冗余的数据:

使用since_id使其成为最有效的解决方法

一个应用处理完时间轴之后过了一段时间，在处理完时间轴之后又有新的数据插入时间轴，这种情况可以通过添加since_id参数对这个问题进行优化。

有这么一种情况，你已经从服务端拿到了1-10这几条数据。现在又有八条新的数据11-18插入了时间轴，这时候你必须从头开始读取数据，一种比较低效的方式是从列表头开始读取，每次读取五条，直到读到编号10这条数据，这会导致两条已经读过的数据被返回：

通过把之前读到的最高id的数据设置为since_id可以解决这个问题，与max_id不同，since_id对应的数据是不被包含的，所以不需要再次调整id的值，如下图所示，服务端只会返回高于since_id的数据：

同时使用max_id和since_id的方式可以让读到的冗余数据达到最小，保证得到的所有数据都是有效的。

当然，如果数据是乱序排列的，这种方法就不适用了。

参考文章： https://tech.jbangit.com/how-to-design-paging.html