前言

分頁接口的實現，在偏業務的服務端開發中應該很常見，PC時代的各種表格，移動時代的各種feed流、timeline。

出于對流量的控制，或者用戶的體驗，大批量的數據都不會直接返回給客戶端，而是通過分頁接口，多次請求返回數據。

而最常用的分頁接口定義大概是這樣的：

router.get('/list', async ctx => { const { page, size } = this.query // ... ctx.body = { data: [] }})// > curl /list?page=1&size=10

接口傳入請求的頁碼、以及每頁要請求的條數，我個人猜想這可能和大家初學的時候所接觸的數據庫有關吧- -，我所認識的人里邊，先接觸MySQL、SQL Server什么的比較多一些，以及類似的SQL語句，在查詢的時候基本上就是這樣的一個分頁條件：

SELECT <column> FROM <table> LIMIT <offset>, <rows>

或者類似的Redis中針對zset的操作也是類似的：

> ZRANGE <key> <start> <stop>

所以可能習慣性的就使用類似的方式創建分頁請求接口，讓客戶端提供page、size兩個參數。

這樣的做法并沒有什么問題，在PC的表格，移動端的列表，都能夠整整齊齊的展示數據。

但是這是一種比較常規的數據分頁處理方式，適用于沒有什么動態的過濾條件的數據。

而如果數據是實時性要求非常高的那種，存在有大量的過濾條件，或者需要和其他數據源進行對照過濾，用這樣的處理方式看起來就會有些詭異。

頁碼+條數 的分頁接口的問題

舉個簡單的例子，我司是有直播業務的，必然也是存在有直播列表這樣的接口的。

而直播這樣的數據是非常要求時效性的，類似熱門列表、新人列表，這些數據的來源是離線計算好的數據，但這樣的數據一般只會存儲用戶的標識或者直播間的標識，像直播間觀看人數、直播時長、人氣，這類數據必然是時效性要求很高的，不可能在離線腳本中進行處理，所以就需要接口請求時才進行獲取。

而且在客戶端請求的時候也是需要有一些驗證的，舉例一些簡單的條件：

這些在離線腳本運行的時候都是沒有辦法做到的，因為每時每刻都在發生變化，而且數據可能沒有存儲在同一個位置，可能列表數據來自MySQL、過濾的數據需要用Redis中來獲取、用戶信息相關的數據在XXX數據庫，所以這些操作不可能是一個連表查詢就能夠解決的，它需要在接口層來進行，拿到多份數據進行合成。

而此時采用上述的分頁模式，就會出現一個很尷尬的問題。

也許訪問接口的用戶戾氣比較重，將第一頁所有的主播全部拉黑了，這就會導致，實際接口返回的數據是0條，這個就很可怕了。