常规的分页方式
API处理分页看似简单,实际上暗藏危机。最常见的分页方式,大概是下面这样的
/users/?page=1&limit=5
//服务端返回
最理想的情况下,客户端请求第一页的5条数据,服务端如常返回,比如下图:
![9dbf50c717eedb58632bb1fc1269e53c.png](https://i-blog.csdnimg.cn/blog_migrate/74e0a4da48984abfe21dcb21510a24b4.jpeg)
拿Twitter的图用一下,假设我们的数据库有10条数据,按照5条一页,正好有2页。
在理想情况下,客户端拉取数据时不会出现任何异常。但,这仅仅是正常情况,如果此时刚好有2条新数据插入。
![bb6a9dc59581a58c853447d0e3903b4d.png](https://i-blog.csdnimg.cn/blog_migrate/dccc930852937c5b76c12444530a3405.png)
数据库记录变为13。原来第二页的数据是[5, 4, 3, 2, 1],现在变为[7, 6, 5, 4, 3],我们再一次拿到了第一页的数据。同理,如果用户在拉取数据时正好有数据被删除,一样会出现类似的问题。
根据item_id分页
要解决此类问题