首页 > 缓存框架的选择-选择对的做对的事情

缓存框架的选择-选择对的做对的事情

本来想发表个博客的,但是没有权限,只有当问题发表了。


项目用到了缓存,一提到缓存,我开始就无脑的选择了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,丰富的数据结构和强大的集合操作可以让我们做更多的事情。总结下:用对的东西做对的事情。

欢迎大家讨论。


最近也开始使用缓存,对于一些简单的查询缓存我一般是使用Guava Cache实现;而redis为则是用来实现一个队列。

Redis的优势在于:

  1. 可以持久化
  2. 丰富数据结构,可以满足用户多种需求,比如实现队列,优先级队列等等
  3. 支持主从复制
【热门文章】
【热门文章】