1舒帮、傳統(tǒng)Web式分頁
web開發(fā)中常用的分頁方式蒙袍，根據(jù)頁碼進(jìn)行分頁其兴。暫且稱為Web式分頁
根據(jù)頁碼pageIndex和分頁大小pageSize進(jìn)行分頁骚烧。
-- offset = (pageIndex-1)*pageSize
select * from table limit offset,pageSize;
這種分頁方式浸赫，在web中使用沒有什么太大問題，但是在App分頁中能否套用這種分頁方式呢赃绊？
2既峡、App上拉加載的流式分頁
App流式分頁
App上的分頁方式從表現(xiàn)上看，基本都是上拉加載更多形式的流式分頁碧查。如果后臺(tái)接口仍然按照Web式分頁方式進(jìn)行設(shè)計(jì)运敢，會(huì)有如下問題：
a、數(shù)據(jù)重復(fù)
b么夫、數(shù)據(jù)缺失
c者冤、offset過大時(shí)查詢效率低
MySQL的limit給分頁帶來了極大的方便，但數(shù)據(jù)量一大的時(shí)候档痪，limit的性能就急劇下降涉枫。
由此可見，傳統(tǒng)Web式分頁接口并不適合App分頁腐螟。
3愿汰、App流式分頁服務(wù)端設(shè)計(jì)
a、cursor游標(biāo)式分頁
select * from table where id >cursor limit pageSize
優(yōu)點(diǎn)：
1)乐纸、能夠避免數(shù)據(jù)重復(fù)/遺漏
2)衬廷、limit性能不會(huì)cursor數(shù)值大小影響，性能穩(wěn)定
缺點(diǎn)：
1)汽绢、適用于只是按照時(shí)間追加的方式的簡單排序
b吗跋、按照時(shí)間分片緩存
非全量數(shù)據(jù)，只是部分熱門數(shù)據(jù)，因?yàn)閿?shù)據(jù)變化太快跌宛，可以基于時(shí)間段生成多個(gè)緩存酗宋。對(duì)于數(shù)據(jù)可以按時(shí)間段（5分鐘）生成一個(gè)緩存分片。
具體流程如下：
按時(shí)間分片式緩存流程
此處的timestamp值疆拘，請求第1頁數(shù)據(jù)時(shí)蜕猫，timestamp傳0，服務(wù)端檢查timestamp<=0哎迄，就將當(dāng)前系統(tǒng)時(shí)間賦值給timestamp返回回右，請求第2，3漱挚，...n頁數(shù)據(jù)時(shí)翔烁，將系統(tǒng)返回的timestamp傳入。
緩存的key是根據(jù)timestamp進(jìn)行計(jì)算的旨涝，比如5分鐘一個(gè)分片租漂，key=list_201605231700。
if(timestamp>0){
// 返回timestamp原值
}else{
// timestamp=系統(tǒng)時(shí)間
}
應(yīng)用場景
比如簡書首頁熱門颊糜，只是一些熱門文章哩治，排序有一定的復(fù)雜性，且相對(duì)容易變動(dòng)衬鱼。
目前簡書專題中列表排序是按照點(diǎn)贊數(shù)排序的业筏，分頁請求
http://www.reibang.com/collections/47/notes?order_by=likes_count&page=48
出現(xiàn)了重復(fù)的數(shù)據(jù)，是因?yàn)樵撆判蚴菍?shí)時(shí)數(shù)據(jù)鸟赫，且沒有游標(biāo)蒜胖，無法感知前面加載的數(shù)據(jù)。
c抛蚤、id列表一次性下發(fā)給App
1台谢、請求第一頁數(shù)據(jù)之前先緩存所有id列表
2、請求每頁數(shù)據(jù)時(shí)岁经，只需帶入相關(guān)的id列表參數(shù)
這種方式適用于id列表不會(huì)很大（數(shù)百條數(shù)據(jù)）的業(yè)務(wù)場景朋沮，例如騰訊新聞。
