多关键字的缓存

一个博客系统，用户更改了自己的个人信息，需要刷新引用了个人信息的页面，
这时候有两种做法：一是清除相关的页面，二是设置一个时间间隔由缓存系统定期重新生成。

常用的缓存系统一般是设置单一关键字，例如ehcache，相关度必须有程序来控制，
所有与个人信息引用相关的页面需要用程序来控制，对于新增了页面，或者更复杂的清除逻辑就不好管理了，
所以一般常见的做法仅仅强制刷新首页，用户信息页等少数信息，其它页面采用第二种策略定期重新生成，
但是定期的时间过长，容易给用户很不好的感觉，会觉得刚才自己的更改没有生效，
定期时间过短，又起不到很好的缓存的作用。

或者干脆不做页面级别的缓存，仅仅做对象级别的缓存，这样就只需要刷新用户信息对象，
只是不缓存页面，一般不方便对页面设置Last-Modified等HTTP协议信息，每一次请求都会重新生成页面。

基于以上两个情况，考虑实现一个多关键字的缓存模式，在读的时候，要求所有关键字与值都完全匹配，
而清理的时候，只需要指定部分关键字。例如：
1.首页缓存，关键字{URL=/,USER_ID=用户名,BLOG_ID_1=列表中第一篇,BLOG_ID_2=列表中第二篇,BLOG_ID_3=列表中第三篇...}
2.博客文章页缓存，关键字{URL=/****.html,USER_ID=用户名,BLOG_ID=博客ID}
3.同时建立首页博客列表对象缓存，{URL=/,USER_ID=用户名}，值是首页博客列表中的全部ID序列

用户访问首页时，根据{URL=/,USER_ID=用户名}读缓存3，得到列表，然后加上{USER_ID=用户名,URL=/}请求缓存1，就能得到一个静态的缓存页面路径。

用户信息变更时，要求清除所有USER_ID=用户名的缓存，这时当前USER_ID下的所有缓存都会被清除。
而当用户修改博客时，需要清除的仅有{BLOG_ID=博客ID}{BLOG_ID_1=博客ID}{BLOG_ID_2=博客ID}{BLOG_ID_3=博客ID}的页面，首页就不一定会被清除
对于大量读少量写，且实时性、用户体验要求高的系统，多关键字缓存，能很好的利用HTTP协议在客户端进行页面内容缓冲，同时，又不会过多增加服务器端的代码耦合

很有启发性