Redis as Memcached Replacement?
- Pretty much set/get operations on key/value, just like memcached, but with rich data structures, like Lists, Sets, Sorted Sets, Hashes, Blocking Queues. And rich commands to use all of them. That avoids serializing a bunch of data into Memcached values.
- Durability options: Redis can be used just in memory, like memcached, or can be tuned to be durable (flushing data every so often is an option, or appending data to a log file that can be replayed if the node restarts, among others).
- Master-slave: it can be configured as master slave, being the slaves your "read replicas".
- Cluster: just like Memcached, it can be sharded using consistent hashing, but that's taking care of on the client side - which can a problem if used against cloud instances that are more likely to fail (so one needs to be prepared for updating the instance list on the client in case of failures).
- Security: pretty much non-existent, or at least not built in, like Memcached. You need to resort to other security mechanisms (to be honest, Memcached had some SASL support, but I don't know the current state of that).
- Not to mention the API, which "[..] is not simply easy to use, but a joy."
- LUA support on the server side
- Good client library support, as well. One good example is the library for a Bloom Filter on top of Redis.
- Publish/Subscribe support: very cool publish/subscribe support on specific channels, pattern matching for both channel and message subscription, etc.
- LRU: one of the questions I've seen is related to the lack of LRU support, but this has been added to Redis
- Performance: I did not find more recent numbers, but some numbers from 2010 show Redis being outperformed by Memcached. That could be a good reason not to use it.
I wonder if Redis performance has improved lately and if any other reason not to use Redis comes up - please comment if you know other reasons to avoid Redis.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)