[ I wrote this post for Redis ToGo, you can find the original article here and the related discussion on Hacker News. ]

Redis Store aims to be a toolkit for your Ruby applications, it natively supports sharding, master/slave replication, marshalling, timeouts and namespaces. Plus, it’s really easy to use with the most popular frameworks, such as Ruby on Rails.

If you love modularity, you will love Redis Store too: under the hood it just activates, at runtime, the best set of low level features requested by the above software layers. It’s delivered as a set of gems, one for each targeted framework, with a common background that’s the redis-store gem itself. This decision helped me a lot to deal with different versions of Ruby, several frameworks, and versions.

How to use it

Let’s say we want to use Redis Store in our Rails project. First of all we need to add an entry in our Gemfile:

gem 'redis-rails'
gem 'redis-rack-cache' # optional

Then we have many options:

## Cache Store
# config/environments/production.rb
config.cache_store = :redis_store

## Session Store
# config/initializers/session_store.rb
MyApplication::Application.config.session_store :redis_store,
  servers: ['redis://:secret@192.168.6.23:6379/0', 'redis://:secret@192.168.6.99:6379/1']

## HTTP Cache
# config.ru
require 'rack'
require 'rack/cache'
require 'redis-rack-cache'

use Rack::Cache,
  metastore:   'redis://localhost:6379/0/metastore',
  entitystore: 'redis://localhost:6380/0/entitystore'

As you can see, it’s pretty easy to plug in, but let’s investigate how to manage our configuration. The first case is self-explanatory, we’re telling ActiveSupport to load our Redis backed store. Remember that, au contraire of Redis, which only supports strings, we can dump full objects here.

The second example is a little bit more complicated. First of all, we are employing a cluster of servers. As mentioned before, Redis Store supports sharding, that means the HTTP sessions will be transparently split across the two hosts. For each node we are specififying, respectively: protocol, password, ip, port and the Redis database.

The last one, instead describes the setup for the Rails recently added Rack::Cache. This is a Ruby implementation of an HTTP cache proxy (like Squid or Varnish), which helps to drastically improve response times, by storing the full contents for a given url. It has two components: the metastore, used mainly to check the existence of an entry, and the entitystore, that’s the repository itself. You’ve probably noticed another parameter in the configuration: it’s the namespace, all the keys will be prefixed with something like <namespace>:<key>. One last note: since we are storing just plain text, the mashalling module isn’t activated.

This is just a small portion of what Redis Store can do, it also supports Rack, Sinatra and I18n out of the box.

Conclusion

I strongly believe that Redis is must-have in your environment, it’s fast, flexible enough to be used as database, cache, pub/sub. That being said, Redis Store can be a great tool for scale your applications, but everything has a cost: fine tuning. Again, it-just-works, but as Rails itself, to step up, you’ll probably find out to experiment a little bit with the Redis configuration, in order to find the right threshold between performances, scalability and memory consumption.

If you want to give Redis store a try, please check it out on GitHub.