对redis用法的思考

redis是基于key-value的消息框架也可以作为缓存,数据库来使用。在最近的几个项目中,我都想把redis加进去,作为消息框架使用,但是每次都因为种种原因最后放弃了。在这里简单做个备忘吧。

A项目是一个tomcat+C的架构,前端使用了strut2。现有架构中使用了thrift作为消息框架,每个模块自己定义消息来进行交互。如果引入redis的话,除了可以使用现成的消息框架(包括消息订阅与发布功能,这在thrift中得自己定义)以外,更重要的是各个模块的消息交互可以保持一种统一规则,而且还可以可借助redis的tools方便调试。但是在现有框架下引入redis显得有点冗余,因为前端已经使用了strut2这种重量级的WEB框架,不可避免的,我们需要添加一些业务对象来做redis接口的适配,而这个适配层其实自己就可以作为缓存而存在。

B项目中,我想引入redis保存server的client实例,这样UI显示部分可以直接从redis获取实时信息。但最后,我认为还是server自己管理上下文简单些,一是写个list加个lock很省事;二是,把list上报给UI也用不了几行代码。因此没有必要,再多引入一个节点。那么如果要用redis的话,应该怎么用才合适呢?

首先,我认为UI部分应该承担比以前更多的工作,为了避免引入适配层,在web后台应该使用通用的方法来处理redis的请求与返回,比如使用json格式来传递消息,甚至在UI部分可以直接使用redis的语义,这用后台可以直接透穿给redis。这种方法可以极大的减少web后台原来的工作(想想strut2中,写的那些个action)。而C程序中,也应该直接面对redis来编码,虽然自身的context还得不能避免,但是至少统一了与上层的消息接口。

这里只是想把redis作为消息框架使用,其缓存功能,我暂时还用不到。