事倍功半是蠢蛋60 分页重映射（Pagination Re-mapping）

http://192.168.0.1:8888/api/v1/githubflow/projects/scan?source=github&order=desc&page=1

修改这个接口的逻辑，然后保留原来的然后生成新的githubflow/projects/scan-new（保证原项目不出错）：
1.githubapi我们最多返回999页，超过的弃掉不要
2.不能让前面的页数出现灰色的项目（分析过的项目）。
3.如果这个项目是灰色的（已经分析过了），就把他放到最后一页 如果最后一页满了就放到倒数第二页
4.也就是说前端的分页和github返回的分页是不相关的，但是要保证前端展示出我们抹平偏移量后的结果。

我的结论是
大概是在redis中构建这些东西：
user_id: 查询星数: 当前页数: 各种查询条件
user_id: 查询总数 ，查询总页数 ,正在构建的最后一页
user_id: 若干缓存页数列表
user_id: 末尾待构建已分析项目列表：
列表中的每一条应该是：
该项目信息-该项目原本存在的页数-该项目动了位置后实际应该存在的页数
user_id: 末尾待构建未分析项目列表：
列表中的每一条应该是：
该项目信息-该项目原本存在的页数-该项目动了位置后实际应该存在的页数

user_id: 若干缓存页数列表：
第X页 -该页数是否到头了

这个函数的伪代码流程是这样的 整体使用redis去做：
1.检测查询条件是否改变
2.如果查询条件已经改变 清空所有查询情况
3.获取当前的这一页是否有缓存，如果有缓存直接返回缓存
4.如果没有缓存，获取当前界面第X页的数据：
获取当前界面数据的概括逻辑是这样的：

重点。
*******用户访问非最后一页的时候所见即所得，看过了就不动了，确定构建
*******用户访问最后一页的时候所见非所得，除非该页面已经被已分析项目填满了。
获取当前界面数据的详细逻辑是这样的：
获取github-api对应的这一页的数据，并将数据进行比对。
如果存在已经被分析过的项目，将他们放到待构建未分析项目列表中，记得记录该项目动了位置后实际应该存在的页数
递归请求下一页的数据回来补足挪动的（被分析过的项目）数目，并将剩余的项目放到待构建已分析/未分析项目列表中(这里需要递归的原因是因为下一页所有数据都有可能是已经分析过的，你可能会一直递归，最极限的情况就是返回的1000个项目都是分析过的，如果请求到最后一页确定的页数之前，或者正在构建的最后一页之前都拿不到足够多的，比如一共有十页，用户先点击第一页 在点击第五页 再点击2，3，4页 如果存在过多项目都挪到后面了，我们这里选择让第四页空着《1=>5=>2=>3=>4》
然后访问哪一页 就观察已分析/未分析项目列表更新 把挤出去的再往更前一页放。