對(duì)于設(shè)計(jì)和實(shí)現(xiàn) API 來(lái)說(shuō)，當(dāng)結(jié)果集包含成千上萬(wàn)條記錄時(shí)，返回一個(gè)查詢的所有結(jié)果可能是一個(gè)挑戰(zhàn)，它給服務(wù)器、客戶端和網(wǎng)絡(luò)帶來(lái)了不必要的壓力，于是就有了分頁(yè)的功能。
通常我們通過(guò)一個(gè) offset 偏移量或者頁(yè)碼來(lái)進(jìn)行分頁(yè)，然后通過(guò) API 實(shí)現(xiàn)類(lèi)似請(qǐng)求：GET /api/products?page=10{"items": [...100 products]}
如果要繼續(xù)訪問(wèn)后續(xù)數(shù)據(jù)，則修改分頁(yè)參數(shù)即可。
GET /api/products?page=11{"items": [...another 100 products]}
在使用 offset 的情況下，通常使用 ?offset=1000 和 ?offset=1100 這種大家都熟悉的方法。它要么直接調(diào)用 OFFSET 1000 LIMIT 100 的 SQL 查詢數(shù)據(jù)庫(kù)，要么使用 LIMIT 乘以 page 作為查詢參數(shù)。無(wú)論如何，這是一個(gè)次優(yōu)的解決方案，因?yàn)闊o(wú)論哪種數(shù)據(jù)庫(kù)都要跳過(guò)前面 offset 指定的 1000 行。而跳過(guò)額外的offset，不管是 PostgreSQL，ElasticSearch還是 MongoDB 都存在額外開(kāi)銷(xiāo)，數(shù)據(jù)庫(kù)需要對(duì)它們進(jìn)行排序，計(jì)數(shù)，然后將前面不用的數(shù)據(jù)扔掉。粉絲福利：手?jǐn)]了 50 個(gè) Java 項(xiàng)目實(shí)戰(zhàn)后，我超神了！
這是一種低效的方法，但由于它使用簡(jiǎn)單，所以大家重復(fù)地用這個(gè)方法，也就是直接把 API 參數(shù)映射到數(shù)據(jù)庫(kù)查詢上。那合適的方法是什么？介紹之前我們可以先看看數(shù)據(jù)庫(kù)的實(shí)現(xiàn)。在數(shù)據(jù)庫(kù)中有一個(gè)游標(biāo)（cursor）的概念，它是一個(gè)指向行的指針，然后可以告訴數(shù)據(jù)庫(kù)："在這個(gè)游標(biāo)之后返回 100 行"。這個(gè)指令對(duì)數(shù)據(jù)庫(kù)來(lái)說(shuō)很容易，因?yàn)槟愫苡锌赡芡ㄟ^(guò)一個(gè)索引字段來(lái)識(shí)別這一行。然后就不需要去取和跳過(guò)前面那些沒(méi)用到的記錄了。
舉個(gè)例子。
GET /api/products{"items": [...100 products], "cursor": "qWe"}
API 返回一個(gè)無(wú)業(yè)務(wù)意義的字符串（游標(biāo)），你可以用它來(lái)檢索下一個(gè)頁(yè)面。
GET /api/products?cursor=qWe{"items": [...100 products], "cursor": "qWr"}
實(shí)現(xiàn)游標(biāo)有很多方法。一般來(lái)說(shuō)，可以通過(guò)一些排序字段比如產(chǎn)品 id 來(lái)實(shí)現(xiàn)。在這種情況下，你可以用一些可逆算法對(duì)產(chǎn)品 id 進(jìn)行編碼。而在接收到一個(gè)帶有游標(biāo)的請(qǐng)求時(shí)，你會(huì)對(duì)它進(jìn)行解碼，并生成一個(gè)類(lèi)似 WHERE id > :cursor LIMIT 100 的查詢。下面是一個(gè)小小的性能對(duì)比，先看看 offset 是如何工作：
=# explain analyze select id from product offset 10000 limit 100; QUERY PLAN --------------------------------------------------------------------------------------------------------------------------------- Limit (cost=1114.26..1125.40 rows=100 width=4) (actual time=39.431..39.561 rows=100 loops=1) -> Seq Scan on product (cost=0.00..1274406.22 rows=11437243 width=4) (actual time=0.015..39.123 rows=10100 loops=1) Planning Time: 0.117 ms Execution Time: 39.589 ms
再看看 where (cursor) 語(yǔ)句如何工作：
=# explain analyze select id from product where id > 10000 limit 100; QUERY PLAN ------------------------------------------------------------------------------------------------------------------------------ Limit (cost=0.00..11.40 rows=100 width=4) (actual time=0.016..0.067 rows=100 loops=1) -> Seq Scan on product (cost=0.00..1302999.32 rows=11429082 width=4) (actual time=0.015..0.052 rows=100 loops=1) Filter: (id > 10000) Planning Time: 0.164 ms Execution Time: 0.094 ms
這是幾個(gè)數(shù)量級(jí)的差異! 當(dāng)然，實(shí)際的差異取決于表的大小以及過(guò)濾器和存儲(chǔ)的實(shí)現(xiàn)。有一篇不錯(cuò)的文章 (1) 提供了更多的技術(shù)信息，里面有 ppt，性能比較見(jiàn)第 42 張幻燈片。
(1) https://use-the-index-luke.com/no-offset當(dāng)然，用戶不會(huì)按 id 來(lái)檢索商品，而是會(huì)按一些相關(guān)性來(lái)查詢（然后按 id 作為關(guān)聯(lián)字段）。在現(xiàn)實(shí)世界中，需要根據(jù)你的業(yè)務(wù)來(lái)決定該怎么做。訂單可以按 id 排序（因?yàn)樗菃握{(diào)增加的）。購(gòu)買(mǎi)清單可以按 wishlist 時(shí)間排序。在我們的案例中，產(chǎn)品來(lái)自 ElasticSearch，自然支持游標(biāo)的特性。我們可以看到的一個(gè)不足是，使用無(wú)狀態(tài)的 API， 無(wú)法支持翻到“上一頁(yè)”這樣的功能。所以在面向用戶界面中，如果有 prev/next 或者 “直接進(jìn)入第10頁(yè)” 這樣的按鈕，就沒(méi)有辦法繞過(guò)前面提到的 offset/limit 這種實(shí)現(xiàn)。但是在其他情況下，使用基于游標(biāo)的分頁(yè)可以極大地提高性能，特別是在真正的大表和真正的深度分頁(yè)上。https://solovyov.net/blog/2020/api-pagination-design/https://news.ycombinator.com/item?id=25547716使用游標(biāo)的另一個(gè)原因是避免由于并發(fā)編輯而導(dǎo)致元素重復(fù)或跳過(guò)的問(wèn)題，比如你使用 offset 正在第 10 頁(yè)上，而有人在第 1 頁(yè)上刪除了一個(gè)項(xiàng)目，則整個(gè)列表會(huì)移動(dòng)，你可能會(huì)意外跳過(guò)第 11 頁(yè)上的一行數(shù)據(jù)。同樣，如果有人在第 1 頁(yè)上添加了一條記錄而你正在第 10 頁(yè)上，第 10 頁(yè)中的一項(xiàng)也會(huì)重復(fù)顯示在第 11 頁(yè)上。游標(biāo)優(yōu)雅地回避了這些問(wèn)題。有時(shí)候，你需要一個(gè)游標(biāo)，這樣你就可以從你剛才的地方繼續(xù)前進(jìn)，而不用擔(dān)心新的記錄進(jìn)來(lái)擾亂你的分頁(yè)。有時(shí)你想要基于位置的查詢，因?yàn)槟忝鞔_地希望所有的東西都是位置的。有時(shí)你想把這兩種技術(shù)結(jié)合起來(lái)，例如，如果你跳到一個(gè)大的、不斷變化的列表中間，然后想在剛才的位置之后檢索下一批結(jié)果。我喜歡 JMAP 最后的設(shè)計(jì)(https://tools.ietf.org/html/rfc8620#page-45)：你可以指定一個(gè)位置整數(shù)，或者一個(gè)錨 ID 和可選的 anchorOffset 整數(shù)。錨是游標(biāo)的一種實(shí)現(xiàn)，它使用結(jié)果集中一個(gè)實(shí)體 ID，而不是一個(gè)可以嵌入其他信息（比如 coroutine 地址）的不透明類(lèi)型，，它有一個(gè)明顯的優(yōu)點(diǎn)，就是可以由客戶端控制。我認(rèn)為作者在使用 OFFSET 時(shí)忽略了一些關(guān)鍵點(diǎn)。至少 postgres 文檔對(duì)此有明確的的說(shuō)法（https://www.postgresql.org/docs/13/queries-limit.html）When?using?LIMIT,?it?is?important?to?use?an?ORDER?BY?clause?that?constrains?the?result?rows?into?a?unique?order.?Otherwise?you?will?get?an?unpredictable?subset?of?the?query's?rows.?You?might?be?asking?for?the?tenth?through?twentieth?rows,?but?tenth?through?twentieth?in?what?ordering?
看起來(lái)作者提供的分頁(yè)查詢沒(méi)有考慮到排序，這意味著第 100 頁(yè)上的項(xiàng)目的 ID 大于 10000，但順序未定義。explain?analyze?select?id?from?product?where?id?>?10000?limit?100
鑒于對(duì)“游標(biāo)”一詞的重用感到困惑，我更喜歡 Google 為分頁(yè)所使用的術(shù)語(yǔ)：頁(yè)面令牌和頁(yè)面大小，詳細(xì)可以參閱：https://google.aip.dev/158
END
關(guān)注武哥聊編程
每天進(jìn)步一點(diǎn)點(diǎn)
點(diǎn)贊是最大的支持?
