There are a handful of use cases for Redis. Most of these focus on increasing the performance of web applications by holding data in memory instead of a more complex data store like a relational database, or NoSQL store like Mongo. Even thought it's relatively straight forward, Redis has advanced features like transactions and clustering with automatic fail-over. Advanced features aside, I'd like to focus the caching use case with a couple different models, such as Write-Through and Least Recently Used.
Write-Through Caching
Write-Through Caching (WTC) works best when Redis has enough memory to store all of the data you will use. Items in a WTC typically are never evicted, beause a WTC doesn't lazy-load. From this standpoint you could call a WTC an in-memory database that trades performance for reliability. Redis counters this with sentinal capabilities. But automatic-failover doesn't help much if you have a complete power failure in your data center(s), or need to relocate your servers, and don't have a hibernate of option. So, you'll need to write-through to your backing store and have a method to resume from a full stop.What is write-through you ask? Basically, write creates, updates, and deletes to Redis when ever you would update your backing store. This way the two are always synchronized. Redis supports transactions, so it is possible to implement a distributed commit strategy. Think of something like this:
begin_redis_transaction();
update_redis();
if (update_backing_store() is successful)
commit_redis_transaction();
else
roll_back_transaction();
When you read from a WTC, just query Redis, you don't need to do anything with the backing store. Except, if your Redis server stops for some reason, you'll need to pull all of the records from the backing store and update Redis w/o the write-through logic above.
Some of the benefits of a WTC:
- Guaranteed performance - reading is constant you don't pay a price for cache misses, because if it's not there, it doesn't exist.
- Guaranteed accuracy - the cache doesn't rely only on item life expectancy to update with new values.
- Memory - the Redis data store must be big enough to hold all of your cacheable data
- Resumption - after a catastrophic failure, it will take some time to reload the Redis store from the backing store, more for the more items you have.
