关于Redis的一些思考

1、从Java语言考虑,已经有ConcurrentHashMap等并发集合类了,与Redis相比,区别于差异在哪?

一直有这么个疑问,今天有搜了很久,很巧,搜到个有同样想法的问答,如下:

When profiling a java application currently under development at work, we have detected a few bottle necks that we can get rid of using caching. The application process requests and it should be as fast as possible doing so. We are considering Redis as cache solution because we already use it in the application. Basically we have to cache java objects. With Redis we have to serialize / deserialize those objects + network overhead. Given that basically Redis is a key value store, I was wondering if it may be more efficient to use a ConcurrentHashMap instead of Redis, as that will save us the serialization and network overhead. However, searching in the internet, I could not find anyone using it for this purpose. Am I missing something? Which is the practical limit of the ConcurrentHashMap for this purposes (in terms of concurrent requests and cached data volume)?

asked Dec 4 '13 at 13:39关于Redis的一些思考joanlofe

回答的很明显,也好理解:Redis不只是用作字典缓存的,它还可以用于线程之间共享数据;一想还真是,高并发访问的系统/服务肯定要搞集群,多节点之间的数据共享就体现除Redis的价值了。

还有一个帖子:

Generally, the Guava or Caffiene caching utilities are applicable whenever:

· You are willing to spend some memory to improve speed.

· You expect that keys will sometimes get queried more than once.

· Your cache will not need to store more data than what would fit in RAM. (Guava caches are local to a single run of your application. They do not store data in files, or on outside servers. If this does not fit your needs, consider some other tool.)

As it says they do not store data in files or outside servers, then a popular and modern outside server option could be redis.

上一篇:CSS躬行记(4)——浮动形状


下一篇:Calling startActivity() from outside of an Activity context requires the FLAG_ACTIVITY_NEW_TASK fla