對於分頁數據的緩存問題，該如何處理呢？
下面就我在開發Web項目（基於Mvc架構，UI不共用DB的Model）時遇到緩存分頁數據的問題，闡述我的處理過程：
首先，我想到的是以分頁的索引為Key，緩存整個頁面的數據。如此一來，對於已經加載過的頁面，可以根據Key直接從緩存中取出即可（采用相對時間緩存的策略，即數據在之后的某一時間段內未被訪問，則從緩存中清除）。這樣即可以節省流量，又可以提高響應時間，自己覺得很滿意。
接下來遇到的問題是：分頁中的數據並不是保持不變的，可能修改或刪除。在這種情況下，以上策略失效了。經過一個上午的思考，我的做法如下：保持上述緩存策略不變，但添加了對添加，修改和刪除操作的處理。首先我們要保存下最近一次訪問的頁號，當用戶執行Update操作時，根據該頁號刪除對應頁的緩存，對於Delete，要刪除對應頁及對應頁之后的緩存。由於新Add的數據總是出現在首頁，所以Add操作時要移除所有分頁的緩存。經過測試，這種做法能避免臟數據及數據重復的問題。但，自己覺得smell太強烈，你們覺得呢？那么，好的做法又該怎樣呢？
帶着問題咨詢了下經驗豐富的老大，得到的答案很讓我驚奇：不要緩存整頁的數據，要分條存取。每次我們只從數據庫獲取分頁數據對應的Id序列，然后根據再根據這些Id從service中獲取（緩存策略在service中實現）。對於這個答案我很費解，這不是太繞了嗎？但仔細想想，細粒度的緩存能更好的解決臟數據的問題。況且，獲取Id序列的相應速度要遠大於model序列的。對於高密度訪問的情況，對應的緩存可以保存更長的時間，這緩存中就會保存大部分訪問過的數據，只有少數的數據需要從數據庫中獲取，這樣更能體現出緩存的優勢。
總結：對於問題的解決辦法，我們往往會在原有解決方案的基礎上看待新的問題，這樣我們的想法就會受到原有問題的制約。對於上述問題的處理，我的收獲是，對待新的問題，當我們在原有方案的基礎上絞盡腦汁也毫無頭緒時，不妨去掉當前方案的束縛，重新看待它，路就在前方...