關於Redis的一些思考

一、從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 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.