对于分页数据该如何缓存？

　　对于分页数据的缓存问题，该如何处理呢？

　　下面就我在开发Web项目（基于Mvc架构，UI不共用DB的Model）时遇到缓存分页数据的问题，阐述我的处理过程：

　　首先，我想到的是以分页的索引为Key，缓存整个页面的数据。如此一来，对于已经加载过的页面，可以根据Key直接从缓存中取出即可（采用相对时间缓存的策略，即数据在之后的某一时间段内未被访问，则从缓存中清除）。这样即可以节省流量，又可以提高响应时间，自己觉得很满意。

　　接下来遇到的问题是：分页中的数据并不是保持不变的，可能修改或删除。在这种情况下，以上策略失效了。经过一个上午的思考，我的做法如下：保持上述缓存策略不变，但添加了对添加，修改和删除操作的处理。首先我们要保存下最近一次访问的页号，当用户执行Update操作时，根据该页号删除对应页的缓存，对于Delete，要删除对应页及对应页之后的缓存。由于新Add的数据总是出现在首页，所以Add操作时要移除所有分页的缓存。经过测试，这种做法能避免脏数据及数据重复的问题。但，自己觉得smell太强烈，你们觉得呢？那么，好的做法又该怎样呢？

　　带着问题咨询了下经验丰富的老大，得到的答案很让我惊奇：不要缓存整页的数据，要分条存取。每次我们只从数据库获取分页数据对应的Id序列，然后根据再根据这些Id从service中获取（缓存策略在service中实现）。对于这个答案我很费解，这不是太绕了吗？但仔细想想，细粒度的缓存能更好的解决脏数据的问题。况且，获取Id序列的相应速度要远大于model序列的。对于高密度访问的情况，对应的缓存可以保存更长的时间，这缓存中就会保存大部分访问过的数据，只有少数的数据需要从数据库中获取，这样更能体现出缓存的优势。

　　总结：对于问题的解决办法，我们往往会在原有解决方案的基础上看待新的问题，这样我们的想法就会受到原有问题的制约。对于上述问题的处理，我的收获是，对待新的问题，当我们在原有方案的基础上绞尽脑汁也毫无头绪时，不妨去掉当前方案的束缚，重新看待它，路就在前方...