关于rust:小小的分页引发的加班血案

问题剖析

通过以上的对话，身为程序员的你是否也遇到过妹子这样的问题呢？传统的而且网上到处充斥着的也是这类形式，客户端依据本人的滚动一直的更新 pagesize 和 pageindex 两个参数，而后上传给服务端接口获取数据，而且网络上也很少阐明这种形式是否有问题，那到底有没有问题呢？

谈到分页，无论程序怎么写，分页这个业务的外围动作是依据开始地位和完结地位来获取一段数据，无论你的排序规定有多简单，最终的目标总是获取总列表数据中一段间断的数据。无论你是间接用的 sql 语句分页，还用的搜索引擎（比方 es），最终在客户端体现的成果就是下一页的数据展示。

当然体现在客户端的 UI 上的交互操作能够有很多款式

如果是瀑布流或者 app 段滚动展现的形式，或者其余不须要数据总个数的状况下，菜菜认为服务端千万不要查问这个总个数数据，展现方齐全能够以下一页有无数据作为是否持续拉取下一页数据的根据。

话题回归，如果客户端根据 pagesize 和 pageindex 参数来进行分页需要，有没有问题呢？当然有，要不然菜菜写这篇文章意义何在，我又不是一个喜爱爱扯淡的程序员~~

问题所在

这里以最简略也是最根本的 sql 语句分页为例，如果当初数据库现有数据为

1,2,3,4,5,6,7

排序的规定是依照大小倒序，即数据的全副列表为：

7,6,5,4,3,2,1

如果当初是获取第二页数据，pagesize 为 2，pageindex 为 2，正确后果为“5,4”。这无可非议，在数据未产生扭转的状况下，正确后果的确如此，那如果数据产生的变动呢，如果当初新退出一条数据 8，列表数据会变为

8,7,6,5,4,3,2,1

那根据以上分页准则，第二页获取的数据就变为了“6,5”，聪慧的你是不是发现了问题，这也可能是 D 妹子引发加班的起因。

分页的操作是建设在动态数据上的操作

解决问题

分页操作的数据源是动静变动的，有时候变动的局部正好产生在你获取的数据范畴内，就会产生数据反复或者谬误的状况。那怎么解决呢？

客户端

作为数据的需求方和展现方，客户端须要记住曾经加载的数据的主键列表，如果某条数据曾经展现过，依据业务需要来确定是否要反复展现，个别状况下须要去重。

如果数据量十分大，客户端保护一个数据池的计划其实也不够现实

服务端

1. 服务端分页接口参数新增上一页最初一条数据 id 参数 lastId，去掉 pageindex 参数，因为在少数状况下，pageindex 参数在服务端的作用是确定数据的终点而已，如果有了 lastid，pageinde 在很多状况下其实曾经不须要了。
2. 服务端把所有的数据做缓存，这样动态数据在肯定工夫内动态化，然而这样也是治标不治本。
3. 如果业务上对于排序无要求的话，服务端能够采纳程序分页，把获取的数据落在不会变动的数据段上

服务端要想把动静的数据搞成动态有点难度

业务方

无论程序怎么优化也扭转不了数据是在不停变动的实质，如果业务方（产品，经营）可能承受数据在偶然状况下能反复的景象，那能大幅度缩小程序员的工作了。

有时候你认为的数据 bug，在其余业务部门不肯定是什么重大问题

支付架构师进阶材料大礼包