现在大多数网站都用到了缓存,但数据结构简单的时候,缓存的设计是简单的,但当数据结构复杂到一定程度后,维护缓存也是非常复杂的事情
而缓存的问题归根来源于数据的更新,插入,删除,如下例:
一篇文章,和一个文章列表,如果是两个缓存,但添加,更新,删除(以上3项以下统称为更改)一篇文章的时候都需要去更新文章列表.就两个的时候很容易做好缓存维护,
现在加一个产品,和一个产品列表,同样是上面的问题,独立的方式的话也很容易处理,但当文章与产品有关,就是说一篇文章下面会列出一个产品的时候,
但一个产品的更改的时候,需要去刷新的就不单单是产品的列表,而且同时也要刷新文章中产品的列表.好的,现在还不算复杂,现在增加一个用户,用户可以收藏产品,
也可以收藏文章,如果他们之间的收藏关系通过关系表来维护的,当然,修改或增加一个产品或文章是没有问题的
但当一个产品或文章被删除的时候,需要清理用户收藏的缓存,但并不是每个用户的收藏列表里都有这个文章或产品,只需要收藏了改产品的用户的缓存列表才需要更新(如何知道呢?遍历缓存,我现在的做法是增加一个TAGS来维护关系)
在增加点关系…现在维护起来已经寸步难行了,每一个单元项(指文章或产品等)更改的时候,同时需要刷新大量的缓存.
细分下数据:
一个数据,存在形式:
- 单个记录存在,
- 与相同类型的列表中的存在,
- 与不同类型的列表(文章与产品同在一个列表)中存在,
- 在一个动态KEY键值下相同类型的列表中存在,
- 在一个动态KEY键值下不同类型的列表(文章与产品同在一个列表)中存在
(或许有漏的,知道的补充下)
(后面不知道该如何来做更好了…)
在看下缓存实现于架构上的问题,也是放置于那层实现,假设架构为MVC
在M层实现,作为一个用户收藏列表的M,如何处理单元项更改的状态,(M相互调用?观察者?)
在V层实现,数据更新存在延时的问题等等
在C层实现,感觉最合理的放置于这层的时候逻辑上感觉最合理了,但使用缓存的时候每个地方都需要判断是否存在缓存(使用数据将变成非常麻烦)
多增加一个辅助类来处理缓存.在C层使用的时候可能方便点,就是在M与C之间建立一层,来判断是否存在缓存,但对于一个框架上开发的项目来说,
很多框架本身就没提供这一层,自己来构建?还有在一个已有的项目上进行改建?更改的量将会很大.