資訊專欄INFORMATION COLUMN
摘要：游標(biāo)條數(shù)的分頁接口實(shí)現(xiàn)命令用于迭代數(shù)據(jù)庫中所有的，但是因?yàn)閿?shù)據(jù)中的數(shù)量是不能確定的，線上直接執(zhí)行會(huì)被打死的，而且的數(shù)量在你操作的過程中也是時(shí)刻在變化的，可能有的被刪除，可能期間又有新增的。
分頁接口的實(shí)現(xiàn)，在偏業(yè)務(wù)的服務(wù)端開發(fā)中應(yīng)該很常見，PC時(shí)代的各種表格，移動(dòng)時(shí)代的各種feed流、timeline。
出于對(duì)流量的控制，或者用戶的體驗(yàn)，大批量的數(shù)據(jù)都不會(huì)直接返回給客戶端，而是通過分頁接口，多次請(qǐng)求返回?cái)?shù)據(jù)。
而最常用的分頁接口定義大概是這樣的：
router.get("/list", async ctx => {
const { page, size } = this.query
// ...
ctx.body = {
data: []
}
})
// > curl /list?page=1&size=10
接口傳入請(qǐng)求的頁碼、以及每頁要請(qǐng)求的條數(shù)，我個(gè)人猜想這可能和大家初學(xué)的時(shí)候所接觸的數(shù)據(jù)庫有關(guān)吧- -，我所認(rèn)識(shí)的人里邊，先接觸MySQL、SQL Server什么的比較多一些，以及類似的SQL語句，在查詢的時(shí)候基本上就是這樣的一個(gè)分頁條件：
SELECTFROM LIMIT
, 或者類似的Redis中針對(duì)zset的操作也是類似的：
> ZRANGE所以可能習(xí)慣性的就使用類似的方式創(chuàng)建分頁請(qǐng)求接口，讓客戶端提供page、size兩個(gè)參數(shù)。
這樣的做法并沒有什么問題，在PC的表格，移動(dòng)端的列表，都能夠整整齊齊的展示數(shù)據(jù)。但是這是一種比較常規(guī)的數(shù)據(jù)分頁處理方式，適用于沒有什么動(dòng)態(tài)的過濾條件的數(shù)據(jù)。
頁碼+條數(shù) 的分頁接口的問題
而如果數(shù)據(jù)是實(shí)時(shí)性要求非常高的那種，存在有大量的過濾條件，或者需要和其他數(shù)據(jù)源進(jìn)行對(duì)照過濾，用這樣的處理方式看起來就會(huì)有些詭異。舉個(gè)簡(jiǎn)單的例子，我司是有直播業(yè)務(wù)的，必然也是存在有直播列表這樣的接口的。
而直播這樣的數(shù)據(jù)是非常要求時(shí)效性的，類似熱門列表、新人列表，這些數(shù)據(jù)的來源是離線計(jì)算好的數(shù)據(jù)，但這樣的數(shù)據(jù)一般只會(huì)存儲(chǔ)用戶的標(biāo)識(shí)或者直播間的標(biāo)識(shí)，像直播間觀看人數(shù)、直播時(shí)長(zhǎng)、人氣，這類數(shù)據(jù)必然是時(shí)效性要求很高的，不可能在離線腳本中進(jìn)行處理，所以就需要接口請(qǐng)求時(shí)才進(jìn)行獲取。而且在客戶端請(qǐng)求的時(shí)候也是需要有一些驗(yàn)證的，舉例一些簡(jiǎn)單的條件：
確保主播正在直播
確保直播內(nèi)容合規(guī)
檢查用戶與主播之間的拉黑關(guān)系
這些在離線腳本運(yùn)行的時(shí)候都是沒有辦法做到的，因?yàn)槊繒r(shí)每刻都在發(fā)生變化，而且數(shù)據(jù)可能沒有存儲(chǔ)在同一個(gè)位置，可能列表數(shù)據(jù)來自MySQL、過濾的數(shù)據(jù)需要用Redis中來獲取、用戶信息相關(guān)的數(shù)據(jù)在XXX數(shù)據(jù)庫，所以這些操作不可能是一個(gè)連表查詢就能夠解決的，它需要在接口層來進(jìn)行，拿到多份數(shù)據(jù)進(jìn)行合成。
而此時(shí)采用上述的分頁模式，就會(huì)出現(xiàn)一個(gè)很尷尬的問題。
也許訪問接口的用戶戾氣比較重，將第一頁所有的主播全部拉黑了，這就會(huì)導(dǎo)致，實(shí)際接口返回的數(shù)據(jù)是0條，這個(gè)就很可怕了。let data = [] // length: 10 data = data.filter(filterBlackList) return data // length: 0這種情況客戶端是該按照無數(shù)據(jù)來展示還是說緊接著要去請(qǐng)求第二頁數(shù)據(jù)呢。
所以這樣的分頁設(shè)計(jì)在某些情況下并不能夠滿足我們的需求，恰巧此時(shí)發(fā)現(xiàn)了Redis中的一個(gè)命令：scan。
游標(biāo)+條數(shù) 的分頁接口實(shí)現(xiàn)scan命令用于迭代Redis數(shù)據(jù)庫中所有的key，但是因?yàn)閿?shù)據(jù)中的key數(shù)量是不能確定的，（_線上直接執(zhí)行keys會(huì)被打死的_），而且key的數(shù)量在你操作的過程中也是時(shí)刻在變化的，可能有的被刪除，可能期間又有新增的。
所以，scan的命令要求傳入一個(gè)游標(biāo)，第一次調(diào)用的時(shí)候傳入0即可，而scan命令的返回值則有兩項(xiàng)，第一項(xiàng)是下次迭代時(shí)候所需要的游標(biāo)，而第二項(xiàng)是一個(gè)集合，表示本次迭代返回的所有key。
以及scan是可以添加正則表達(dá)式用來迭代某些滿足規(guī)則的key，例如所有temp_開頭的key：scan 0 temp_*，而scan并不會(huì)真的去按照你所指定的規(guī)則去匹配key然后返回給你，它并不保證一次迭代一定會(huì)返回N條數(shù)據(jù)，有極大的可能一次迭代一條數(shù)據(jù)都不返回。如果我們明確的需要XX條數(shù)據(jù)，那么按照游標(biāo)多次調(diào)用就好了。
// 用一個(gè)遞歸簡(jiǎn)單的實(shí)現(xiàn)獲取十個(gè)匹配的key await function getKeys (pattern, oldCursor = 0, res = []) { const [ cursor, data ] = await redis.scan(oldCursor, pattern) res = res.concat(data) if (res.length >= 10) return res.slice(0, 10) else return getKeys(cursor, pattern, res) } await getKeys("temp_*") // length: 10這樣的使用方式給了我一些思路，打算按照類似的方式來實(shí)現(xiàn)分頁接口。
大致的結(jié)構(gòu)
不過將這樣的邏輯放在客戶端，會(huì)導(dǎo)致后期調(diào)整邏輯時(shí)候變得非常麻煩。需要發(fā)版才能解決，新老版本兼容也會(huì)使得后期的修改束手束腳。
所以這樣的邏輯會(huì)放在服務(wù)端來開發(fā)，而客戶端只需要將接口返回的游標(biāo)cursor在下次接口請(qǐng)求時(shí)攜帶上即可。對(duì)于客戶端來說，這就是一個(gè)簡(jiǎn)單的游標(biāo)存儲(chǔ)以及使用。
但是服務(wù)端的邏輯要稍微復(fù)雜一些：首先，我們需要有一個(gè)獲取數(shù)據(jù)的函數(shù)
其次需要有一個(gè)用于數(shù)據(jù)過濾的函數(shù)
有一個(gè)用于判斷數(shù)據(jù)長(zhǎng)度并截取的函數(shù)
function getData () { // 獲取數(shù)據(jù) } function filterData () { // 過濾數(shù)據(jù) } function generatedData () { // 合并、生成、返回?cái)?shù)據(jù) }實(shí)現(xiàn)node.js 10.x已經(jīng)變?yōu)榱?b>LTS，所以示例代碼會(huì)使用10的一些新特性。因?yàn)榱斜泶蟾怕实臅?huì)存儲(chǔ)為一個(gè)集合，類似用戶標(biāo)識(shí)的集合，在Redis中是set或者zset。
如果是數(shù)據(jù)源來自Redis，我的建議是在全局緩存一份完整的列表，定時(shí)更新數(shù)據(jù)，然后在接口層面通過slice來獲取本次請(qǐng)求所需的部分?jǐn)?shù)據(jù)。
P.S. 下方示例代碼假設(shè)list的數(shù)據(jù)中存儲(chǔ)的是一個(gè)唯一ID的集合，而通過這些唯一ID再?gòu)钠渌臄?shù)據(jù)庫獲取對(duì)應(yīng)的詳細(xì)數(shù)據(jù)。
redis> SMEMBER list > 1 > 2 > 3 mysql> SELECT * FROM user_info +-----+---------+------+--------+ | uid | name | age | gender | +-----+---------+------+--------+ | 1 | Niko | 18 | 1 | | 2 | Bellic | 20 | 2 | | 3 | Jarvis | 22 | 2 | +-----+---------+------+--------+列表數(shù)據(jù)在全局緩存// 完整列表在全局的緩存 let globalList = null async function updateGlobalData () { globalList = await redis.smembers("list") } updateGlobalData() setInterval(updateGlobalData, 2000) // 2s 更新一次獲取數(shù)據(jù) 過濾數(shù)據(jù)函數(shù)的實(shí)現(xiàn)因?yàn)樯线叺?b>scan示例采用的是遞歸的方式來進(jìn)行的，但是可讀性并不是很高，所以我們可以采用生成器Generator來幫助我們實(shí)現(xiàn)這樣的需求：
// 獲取數(shù)據(jù)的函數(shù) async function * getData (list, size) { const count = Math.ceil(list.length / size) let index = 0 do { const start = index * size const end = start + size const piece = list.slice(start, end) // 查詢 MySQL 獲取對(duì)應(yīng)的用戶詳細(xì)數(shù)據(jù) const results = await mysql.query(` SELECT * FROM user_info WHERE uid in (${piece}) `) // 過濾所需要的函數(shù)，會(huì)在下方列出來 yield filterData(results) } while (index++ < count) }同時(shí)，我們還需要有一個(gè)過濾數(shù)據(jù)的函數(shù)，這些函數(shù)可能會(huì)從一些其他數(shù)據(jù)源獲取數(shù)據(jù)，用來校驗(yàn)列表數(shù)據(jù)的合法性，比如說，用戶A有一個(gè)黑名單，里邊有用戶B、用戶C，那么用戶A訪問接口時(shí)，就需要將B和C進(jìn)行過濾。
抑或是我們需要判斷當(dāng)前某條數(shù)據(jù)的狀態(tài)，例如主播是否已經(jīng)關(guān)閉了直播間，推流狀態(tài)是否正常，這些可能會(huì)調(diào)用其他的接口來進(jìn)行驗(yàn)證。// 過濾數(shù)據(jù)的函數(shù) async function filterData (list) { const validList = await Promise.all(list.map(async item => { const [ isLive, inBlackList ] = await Promise.all([ http.request(`https://XXX.com/live?target=${item.id}`), redis.sismember(`XXX:black:list`, item.id) ]) // 正確的狀態(tài) if (isLive && !inBlackList) { return item } })) // 過濾無效數(shù)據(jù) return validList.filter(i => i) }最后拼接數(shù)據(jù)的函數(shù)上述兩個(gè)關(guān)鍵功能的函數(shù)實(shí)現(xiàn)后，就需要有一個(gè)用來檢查、拼接數(shù)據(jù)的函數(shù)出現(xiàn)了。
用來決定何時(shí)給客戶端返回?cái)?shù)據(jù)，何時(shí)發(fā)起新的獲取數(shù)據(jù)的請(qǐng)求：async function generatedData ({ cursor, size, }) { let list = globalList // 如果傳入游標(biāo)，從游標(biāo)處截取列表 if (cursor) { // + 1 的作用在下邊有提到 list = list.slice(list.indexOf(cursor) + 1) } let results = [] // 注意這里的是 for 循環(huán)， 而非 map、forEach 之類的 for await (const res of getData(list, size)) { results = results.concat(res) if (results.length >= size) { const list = results.slice(0, size) return { list, // 如果還有數(shù)據(jù)，那么就需要將本次 // 我們返回列表最后一項(xiàng)的 ID 作為游標(biāo)，這也就解釋了接口入口處的 indexOf 為什么會(huì)有一個(gè) + 1 的操作了 cursor: list[size - 1].id, } } } return { list: results, } }非常簡(jiǎn)單的一個(gè)for循環(huán)，用for循環(huán)就是為了讓接口請(qǐng)求的過程變?yōu)榇校诘谝淮谓涌谡?qǐng)求拿到結(jié)果后，并確定數(shù)據(jù)還不夠，還需要繼續(xù)獲取數(shù)據(jù)進(jìn)行填充，這時(shí)才會(huì)發(fā)起第二次請(qǐng)求，避免額外的資源浪費(fèi)。
在獲取到所需的數(shù)據(jù)以后，就可以直接return了，循環(huán)終止，后續(xù)的生成器也會(huì)被銷毀。以及將這個(gè)函數(shù)放在我們的接口中，就完成了整個(gè)流程的組裝：
router.get("/list", async ctx => { const { cursor, size } = this.query const data = await generatedData({ cursor, size, }) ctx.body = { code: 200, data, } })這樣的結(jié)構(gòu)返回值大概是，一個(gè)list與一個(gè)cursor，類似scan的返回值，游標(biāo)與數(shù)據(jù)。
客戶端還可以傳入可選的size來指定一次接口期望的返回條數(shù)。
不過相對(duì)于普通的page+size分頁方式，這樣的接口請(qǐng)求勢(shì)必會(huì)慢一些（因?yàn)槠胀ǖ姆猪摽赡芤豁摲祷夭涣斯潭l數(shù)的數(shù)據(jù)，而這個(gè)在內(nèi)部可能執(zhí)行了多次獲取數(shù)據(jù)的操作）。不過用于一些實(shí)時(shí)性要求強(qiáng)的接口上，我個(gè)人覺得這樣的實(shí)現(xiàn)方式對(duì)用戶會(huì)更友好一些。
兩者之間的比較這兩種方式都是很不錯(cuò)的分頁方式，第一種更常見一些，而第二種也不是靈丹妙藥，只是在某些情況下可能會(huì)好一些。
第一種方式可能更多的會(huì)應(yīng)用在B端，一些工單、報(bào)表、歸檔數(shù)據(jù)之類的。
而第二種可能就是C端用會(huì)比較好一些，畢竟提供給用戶的產(chǎn)品；
在PC頁面可能是一個(gè)分頁表格，第一個(gè)展示10條，第二頁展示出來8條，但是第三頁又變成了10條，這對(duì)用戶體驗(yàn)來說簡(jiǎn)直是個(gè)災(zāi)難。
而在移動(dòng)端頁面可能會(huì)相對(duì)好一些，類似無限滾動(dòng)的瀑布流，但是也會(huì)出現(xiàn)用戶加載一次出現(xiàn)2條數(shù)據(jù)，又加載了一次出現(xiàn)了8條數(shù)據(jù)，在非首頁這樣的情況還是勉強(qiáng)可以接受的，但是如果首頁就出現(xiàn)了2條數(shù)據(jù)，嘖嘖。而用第二種，游標(biāo)cursor的方式能夠保證每次接口返回?cái)?shù)據(jù)都是size條，如果不夠了，那就說明后邊沒有數(shù)據(jù)了。
小結(jié)
對(duì)用戶來說體驗(yàn)會(huì)更好一些。（當(dāng)然了，如果列表沒有什么過濾條件，就是一個(gè)普通的展示，那么建議使用第一種，沒有必要添加這些邏輯處理了）當(dāng)然了，這只是從服務(wù)端能夠做到的一些分頁相關(guān)的處理，但是這依然沒有解決所有的問題，類似一些更新速度較快的列表，排行榜之類的，每秒鐘的數(shù)據(jù)可能都在變化，有可能第一次請(qǐng)求的時(shí)候，用戶A在第十名，而第二次請(qǐng)求接口的時(shí)候用戶A在第十一名，那么兩次接口都會(huì)存在用戶A的記錄。
針對(duì)這樣的情況，客戶端也要做相應(yīng)的去重處理，但是這樣一去重就會(huì)導(dǎo)致數(shù)據(jù)量的減少。
這又是一個(gè)很大的話題了，不打算展開來講。。
一個(gè)簡(jiǎn)單的欺騙用戶的方式，就是一次接口請(qǐng)求16條，展示10條，剩余6條存在本地下次接口拼接進(jìn)去再展示。文中如果有什么錯(cuò)誤，或者關(guān)于分頁各位有更好的實(shí)現(xiàn)方式、自己喜歡的方式，不妨交流一番。
參考資料redis | scan
文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址：http://m.specialneedsforspecialkids.com/yun/99212.html
相關(guān)文章
Graphql實(shí)踐——像axios一樣使用Graphql
摘要：初始化項(xiàng)目使用初始化項(xiàng)目安裝項(xiàng)目結(jié)構(gòu)如下接口所有接口對(duì)封裝接下來對(duì)進(jìn)行封裝，加上中間件實(shí)現(xiàn)類似于攔截器的效果。 Graphql嘗鮮 在只學(xué)習(xí)graphql client端知識(shí)的過程中，我們常常需要一個(gè)graphql ide來提示graphql語法，以及實(shí)現(xiàn)graphql的server端來進(jìn)行練手。graphql社區(qū)提供了graphiql讓我們使用 graphiql (npm)：一個(gè)交互...
JDBC常見面試題
摘要：常見面試題操作數(shù)據(jù)庫的步驟操作數(shù)據(jù)庫的步驟注冊(cè)數(shù)據(jù)庫驅(qū)動(dòng)。可以防止注入，安全性高于。只有隔離級(jí)別才能防止產(chǎn)生幻讀。對(duì)象維護(hù)了一個(gè)游標(biāo)，指向當(dāng)前的數(shù)據(jù)行。一共有三種對(duì)象。 以下我是歸納的JDBC知識(shí)點(diǎn)圖： showImg(https://segmentfault.com/img/remote/1460000013312769); 圖上的知識(shí)點(diǎn)都可以在我其他的文章內(nèi)找到相應(yīng)內(nèi)容。 JDBC...
MongoDB指南---9、游標(biāo)與數(shù)據(jù)庫命令
摘要：例如在中，可以用產(chǎn)生一個(gè)的隨機(jī)數(shù)這樣，想要從集合中查找一個(gè)隨機(jī)文檔，只要計(jì)算一個(gè)隨機(jī)數(shù)并將其作為查詢條件就好了，完全不用偶爾也會(huì)遇到產(chǎn)生的隨機(jī)數(shù)比集合中所有隨機(jī)值都大的情況，這時(shí)就沒有結(jié)果返回了。指定本次查詢中掃描文檔數(shù)量的上限。 上一篇文章：MongoDB指南---8、特定類型的查詢下一篇文章：MongoDB指南---10、索引、復(fù)合索引 簡(jiǎn)介 數(shù)據(jù)庫使用游標(biāo)返回find的執(zhí)行結(jié)果...
MongoDB指南---9、游標(biāo)與數(shù)據(jù)庫命令
摘要：例如在中，可以用產(chǎn)生一個(gè)的隨機(jī)數(shù)這樣，想要從集合中查找一個(gè)隨機(jī)文檔，只要計(jì)算一個(gè)隨機(jī)數(shù)并將其作為查詢條件就好了，完全不用偶爾也會(huì)遇到產(chǎn)生的隨機(jī)數(shù)比集合中所有隨機(jī)值都大的情況，這時(shí)就沒有結(jié)果返回了。指定本次查詢中掃描文檔數(shù)量的上限。 上一篇文章：MongoDB指南---8、特定類型的查詢下一篇文章：MongoDB指南---10、索引、復(fù)合索引 簡(jiǎn)介 數(shù)據(jù)庫使用游標(biāo)返回find的執(zhí)行結(jié)果...
發(fā)表評(píng)論
0條評(píng)論
godruoyi
男|高級(jí)講師
TA的文章
閱讀更多
tensorflow用法
閱讀 3454·2023-04-26 01:45
#yyds干貨盤點(diǎn)#SELinux安全子系統(tǒng)
閱讀 2233·2021-11-23 09:51
Database：便宜美國(guó)GPU服務(wù)器，X3440/16GB/1TB SSD，100M不限流量，nv
閱讀 3644·2021-10-18 13:29
XIU主題8.2版本更新：新增文章和頁面對(duì)模版的支持、調(diào)整和修復(fù)一些問題
閱讀 3442·2021-09-07 10:12
庫克任蘋果CEO已滿10周年，下一任期有望推出“蘋果汽車”
閱讀 705·2021-08-27 16:24
echarts4.x雷達(dá)圖如何展示一維數(shù)據(jù)？
閱讀 1775·2019-08-30 15:44
深挖 NPM 機(jī)制
閱讀 2200·2019-08-30 15:43
CSS transition屬性實(shí)現(xiàn)滑動(dòng)式輪播圖
閱讀 2956·2019-08-30 13:11
最新活動(dòng)
閱讀需要支付1元查看
