Redis vs Memcache
Solution 1:
There is really one key difference between the two.
- Redis = Key/Value caching
- Memcached = Object caching
Both can be manipulated into caching whatever you want to throw at them. The ultimate goal of either of these systems and many others like them is to provide a distributed in-memory cache to store whatever data you need access to in a faster way. This essentially relegates the database to a simple data repository for persisted and long term storage while the in-memory cache mechanism offloads and moves as much data as possible and feasible to the front-end of the stack thereby reducing the latency and time to retrieve the data.
As you point out, Redis is really intended for just Key and Value caching however I have seen whole objects stored before. It does lend itself well to database performance improvements however.
Memcached is a bit more flexible in that it can pretty much store whatever you want it to. It's also one of the top contendors for any distributed memory cache application. There are other systems that do this too as well.
Either way, software has to be written to load either of these two caches. Some existing software may exists for whatever purpose you have in mind such as loading a table into memory but those would be specific for each case.
Solution 2:
Memcached is an in-memory key/value store. Redis can be used that way, but is much much more.
Ways Memcached and Redis Are Similar
Both are capable of caching database results or anything else you might want to cache.
Both are capable of storing simple string values for a key. A previous answer stated memcached is more flexible, and this is false. Storing "whatever you want" into memcached involves taking objects and serializing/marshaling them into strings. Redis supports this equally well. Redis is generally more flexible even at storing your serialized objects as the default max value size is much bigger (1MB vs 512MB).
Both store values in-memory and are extremely fast and efficient, often bottle-necking on network bandwidth or memory I/O without heavy CPU usage. Both are highly scalable. Great tools for management and monitoring exist for both. Commercial cluster solutions exist for both. As of 3.0, redis includes built-in clustering support, which memcached does not offer.
Virtually every use-case for memcached can be solved equally well, sometimes better, by redis. Memcached is a fantastic piece of software, but both its features and strengths have become a subset of Redis'.
The Redis Superset
Where they differ is in the large number of additional features redis offers, and the additional use-cases those features enable.
Redis is more than a key/value store. It is an in-memory data structure server. Keys can be assigned simple strings, like in memcached, but they can also store Hashes, Lists, Sets, or Sorted Sets. These additional data types are efficient and optimized, with many commands to leverage them, enabling access patterns a simple key/value store doesn't offer.
Redis offers persistence, built-in and on by default. This means redis is a real database by default, and not a simple volatile cache like memcached. Your data will be there when you restart. There are lots of simple administration options you can use to tweak the persistence to best solve your use case, or turn it off if all you want is a volatile cache.
Redis offers pub/sub (Publish/Subscribe). This allows you to create channels and have one or more clients subscribe to them, allowing an efficient high-speed real-time communication mechanism. This can be a great solution for inter-process, inter-application, or inter-server communication.
Redis offers Lua scripting support. This allows you to do all sorts of new things. One important example would be executing several dependent redis commands atomically, and with a single call to redis. Lua scripting is easy to pick up and the scripts run efficiently and atomically.
Conclusion
Unless your project is already using memcached or your organization has significant investments in memcached, you should not use it. Redis rivals memcached at its own game, and enables a whole world of new ones. Even if your problem can be solved equally by both tools, go with the tool that provides more flexibility for problems you can't yet foresee: redis. You will also be choosing the tool that is more actively developed and maintained, and which is being improved more quickly. Memcached isn't going anywhere and shouldn't, but its hard to make the case for it being used in anything new unless you have significant knowledge or infrastructure investments in memcached.
If you are already using memcached, switching to redis may be a lot of work for little to no gain. Evaluate redis closely and decide for your situation whether the costs of switching outweighs the benefits. If it does, stick with memcached. It still is a great, stable, hardened piece of software.