缓存框架的选择-选择对的做对的事情
本来想发表个博客的,但是没有权限,只有当问题发表了。
项目用到了缓存,一提到缓存,我开始就无脑的选择了redis。为什么呢?跟风。。。。。
网上已经把redis吹到天了。
好吧然后开始弄,很传统的做法:先搞一个连接池,然后再搞一个方法拦截,当key存在的时候去redis拿,没有就访问数据库,然后再存进redis,设置失效期。 更新相关数据的时候先存数据库,然后删redis对应的key.
缓存单个对象的时候,直接映射成redis的hash结构。缓存列表,我的做法是把列表内的单个对象序列成json,然后再一个个的rpush到redis的一个list里面。目前就这2种结构,但是足够了。
结合redis的pipeline不用担心效率的问题,结合transaction不用担心一致性问题,结合setnx不用担心多线程并发问题。就这么一直弄这,越弄觉得越不对劲。。。。。
我完全把redis当成了一个memcached用了,一个超级大的hashtable。然后又在网上阅读了大量的资料,发现针对我这个纯缓存的情景并不适合redis。 (但首先说这么做没问题,也可行。)
redis提供的是丰富的数据结构,是用来弥补传统sql不方便做的事情。回顾一下我的代码,除了hash和list结构的命令几乎没什么了。如果只是简单的缓存数据,去用memcached,ehcache,因为它们专业就是干这个的(做分布式已经很成熟了,redis目前官方还没有给出,只能以来第三方之类的),别的也干不了。
今天开始用ehcache替换原有的redis做缓存,但并不是完全抛弃redis,丰富的数据结构和强大的集合操作可以让我们做更多的事情。总结下:用对的东西做对的事情。
欢迎大家讨论。
6636087
11 years, 5 months ago