Memcached vs Redis: What are the differences?
Memcached: High-performance, distributed memory object caching system. Memcached is an in-memory key-value store for small chunks of arbitrary data (strings, objects) from results of database calls, API calls, or page rendering; Redis: An in-memory database that persists on disk. Redis is an open source, BSD licensed, advanced key-value store. It is often referred to as a data structure server since keys can contain strings, hashes, lists, sets and sorted sets.
Memcached can be classified as a tool in the "Databases" category, while Redis is grouped under "In-Memory Databases".
"Fast object cache", "High-performance" and "Stable" are the key factors why developers consider Memcached; whereas "Performance", "Super fast" and "Ease of use " are the primary reasons why Redis is favored.
Memcached and Redis are both open source tools. It seems that Redis with 37.4K GitHub stars and 14.4K forks on GitHub has more adoption than Memcached with 9K GitHub stars and 2.6K GitHub forks.
According to the StackShare community, Redis has a broader approval, being mentioned in 3261 company stacks & 1782 developers stacks; compared to Memcached, which is listed in 755 company stacks and 267 developer stacks.
The obvious volatile memory choices were either Memcached or Redis. We eventually sided with Redis as it natively handled replication, and this replication fell under the PCI responsibility scope of AWS. This added duribility meant that if a redis node were to die, our downtime would be in the seconds, rather than 15 minutes which we would incur using Memcached
The requirement was the classic "cache the results of a SQL query for a period of time."
While the Internet is full of "Redis is fuller featured" posts, the key issue for us was the actual performance. We discovered, in various stress scenario testing, that Memcached outperformed Redis for simple key-value retrieval dramatically (over twice as fast.) That's not to say that Redis is bad - we use that in other places where the requirements are more sophisticated than simple key/value retrieval.
This was roughly 4 years ago at this point. We had been using an old iteration of memcache on Windows as the data cache per server for while and had for whatever reason opted to store our session data (to which the application is heavily dependent) in App Fabric. App Fabric had come to EOL and we needed to move away from it. As a quick search showed throughput capacity to be higher and overall features of Redis were better we initially implemented it. The number of changes required were minimal and we were able to migrate away to a more resilient system pretty quickly. We hit a snag in that the implementation of the Redis session handler at that point only took a single IP so we had to do use keepalived and HAProxy to display the application consistently between master and slave failovers. This caused issues on occasion of dropped connections to the backend service. We upgraded our client and could put both members into our config files and it stopped timing out. We were all happy in this and it was (for it's own part) a significant upgrade. Generally performance was better for all pages. We found however, that our application was serializing all requests and locking on the thread via session lock for a great many things and this caused us and our users considerable headaches on occasion. We found that the implementation of the couchbase session handler gave us the option of ignoring session write locks and not be required to rewrite dozens of pages to handle the no session requirement as the application was working fine without the need to be threadsafe. Though the maximum throughput was not as good compared to Redis the application performance was considerably better as a result of the change. The multi-master write was a big benefit and the cross data center replication was a nice thing to have as that would allow our users to remain logged in even across DataCenter fail-over events (praying that never happened). Overall we used that for session handling and chose to use couchbase (in a 2nd cluster) to handle memcache requests as that gave us greater capacity to handle larger objects more efficiently. We are, all these years later, looking to move into the newer features of couchbase to give us more and better use of this product that really has been the answer to a bunch of the growing pains we experienced. Since the decision performance has not been on wild rides and stability has never been better. So I sing the praises of couchbase to anyone that will listen.
Sign up to add or upvote prosMake informed product decisions
Sign up to add or upvote consMake informed product decisions
What is Memcached?
What is Redis?
Need advice about which tool to choose?Ask the StackShare community!
Sign up to get full access to all the companiesMake informed product decisions
Sign up to get full access to all the tool integrationsMake informed product decisions
Redis is a good caching tool for a cluster, but our application had performance issues while using Aws Elasticache Redis since some page had 3000 cache hits per a page load and Redis just couldn't quickly process them all in once + latency and object deseialization time - page load took 8-9 seconds. We create a custom hybrid caching based on Redis and EhCache which worked great for our goals. Check it out on github, it's called HybriCache - https://github.com/batir-akhmerov/hybricache.
Redis is used for storing all ephemeral (that's data you don't necessarily want to store permanently) user data, such as mapping of session IDs (stored in cookies) to current session variables at Cloudcraft.co. The many datastructures supported by Redis also makes it an excellent caching and realtime statistics layer. It doesn't hurt that the author, Antirez, is the nicest guy ever! These days, I would be really hard pressed to find any situation where I would pick something like Memcached over Redis.
Trello uses Redis for ephemeral data that needs to be shared between server processes but not persisted to disk. Things like the activity level of a session or a temporary OpenID key are stored in Redis, and the application is built to recover gracefully if any of these (or all of them) are lost. We run with allkeys-lru enabled and about five times as much space as its actual working set needs, so Redis automatically discards data that hasn’t been accessed lately, and reconstructs it when necessary.
The UI has message inbox that is sent a message when you get a new badge, receive a message, significant event, etc. Done using WebSockets and is powered by redis. Redis has 2 slaves, SQL has 2 replicas, tag engine has 3 nodes, elastic has 3 nodes - any other service has high availability as well (and exists in both data centers).
Redis makes certain operations very easy. When I need a high-availability store, I typically look elsewhere, but for rapid development with the ability to land on your feet in prod, Redis is great. The available data types make it easy to build non-trivial indexes that would require complex queries in postgres.
I use Redis for cacheing, data storage, mining and augmentation, proprietary distributed event system for disparate apps and services to talk to each other, and more. Redis has some very useful native data types for tracking, slicing and dicing information.
As part of the cacheing system within Drupal.
Memcached mainly took care of creating and rebuilding the REST API cache once changes had been made within Drupal.
Distributed cache exposed through Google App Engine APIs; use to stage fresh data (incoming and recently processed) for faster access in data processing pipeline.
Memcache caches database results and articles, reducing overall DB load and allowing seamless DB maintenance during quiet periods.
Used to cache most used files for our clients. Connected with CloudFlare Railgun Optimizer.