常規(guī)分頁查詢緩存方案
我們都知道，通過緩存查詢的結果，可以極大的提升系統(tǒng)的服務能力，以及降低底層服務或者是數(shù)據(jù)庫的壓力。
對于有分頁條件的緩存，我們也可以按照不同的分頁條件來緩存多個key，比如分頁查詢產品列表,page=1&limit=10和page=1&limit=5這兩次請求可以這樣緩存查詢結果
- productList:page:1:limit:10
- productList:page:1:limit:5
這個是一種常見方案，但是存在著一些問題： - 緩存的value存在冗余，productList:page:1:limit:10緩存的內容其實是包括了productList:page:1:limit:5中的內容（緩存兩個key的時候，數(shù)據(jù)未發(fā)生變化的情況下）
- 僅僅是改變了查詢條件的分頁條件，就會導致緩存未命中，降低了緩存的命中率
- 為了保證數(shù)據(jù)一致性，需要清理緩存的時候，很難處理，redis的keys命令對性能影響很大，會導致redis很大的延遲，生產環(huán)境一般來說禁止該命令。自己手動拼緩存key，你可能根本不知道拼到哪一個page為止。
- 放棄數(shù)據(jù)一致性，通過設置失效時間來自動失效，可能會出現(xiàn)查詢第一頁命中了緩存，查詢第二頁的時候未命中緩存，但此時數(shù)據(jù)已經(jīng)發(fā)生了改變，導致第二頁查詢返回的和第一頁相同的結果。
以上，在分頁條件下這樣使用常規(guī)方案總感覺有諸多困擾，諸多麻煩，那是不是就應該放棄使用緩存？
基于SortedSet的分頁查詢緩存方案
首先想到的解決方法是使用@see ListOperations<K, V>不再根據(jù)分頁條件使用多個key，而是使用一個key，也不分頁將全部的數(shù)據(jù)緩存到redis中，然后按照分頁條件使用range(key,start,limit)獲取分頁的結果，這個會導致一個問題，當緩存失效時，并發(fā)的寫緩存會導致出現(xiàn)重復數(shù)據(jù)
所以想到通過使用set來處理并發(fā)時的重復數(shù)據(jù)，@see ZSetOperations<K, V>
代碼邏輯如下：
- range(key,start,limit)按照分頁條件獲取緩存，命中則直接返回
- 緩存未命中，查詢（沒有分頁條件）數(shù)據(jù)庫或是調用（沒有分頁）底層接口
- add(key,valueScoreMap<value,score>)寫入緩存，expire設置緩存時間
- 當需要清理緩存時，直接刪除key，如果是因為數(shù)據(jù)新增和刪除，可以add(key,value,score)或remove(key,value)
redis中會按照score分值升序排列map中的數(shù)據(jù)，一般的，score分值是sql語句的order by filedA的filedA的值，這樣能保證數(shù)據(jù)一致性
但是這種方式也存在一定問題：
- 這個key緩存的value確實是熱數(shù)據(jù)，但可能只有少數(shù)數(shù)據(jù)被頻繁使用其余的可能根本就未被使用，比如數(shù)據(jù)有100頁，實際可能只會用到前10頁，這也會導致緩存空間的浪費，如果使用了redis虛擬內存，也會有一定影響
- sql查詢由原來的分頁查詢變成了不分頁查詢，緩存失效后，系統(tǒng)的處理能力較之前會有下降，尤其是對于大表
總結
這兩種方式互有利弊，具體使用還是要按照具體場景，合理選擇！有更好的方案也歡迎討論:-)
