This document discusses Redis, an in-memory data structure store that can be used for caching, job queues, and pub/sub messaging. Redis is written in C, runs as a single process, and provides data structures like lists, sets, hashes and strings. It supports persistence through snapshots or append-only files. Redis is fast, stable, and can be used as a primary database or to power features like view counts, metrics, locking, and who's online tracking. The document provides code examples for caching, job queues, and pub/sub messaging using Redis with Rails applications.
So, what's it all about, I thought I would just start by quickly going over the basics. But I'm not going to dwell for too long about what redis is, because I want this talk to really be more about what you can do with it.
So, speed-wise, most benchmarks put it at a little bit slower or a little bit faster than memcached. It doesn't really matter which, it's fast.It's an in-memory data store, which backs up to disk.
It's written in C, single threaded, atomic commands and installs easily with zero dependies.
Who uses it? A bunch of companies. Really more than I wanted to put in this slide, so consider this just a small slice.
Alright, now let's get down to what we're here for, is some talk about RUBY! Getting started is pretty darned simple, just throw a line in your gemfile and you're good to go.
Oh, but oups, we forgot something!Never forget to leave home without your C bindings! hiredis does that for us.Whew, narroly missed that one.
So, moving on, it's usually a good idea, if you're going to be dealing with a DB connection in an environment where you might have threading, to give yourself a pool of connections to work with. This way, you aren't waiting for one command to finish before you do something else.
Alright, now that we've set up redis to our liking, what can we do with it.Well, I feel like the quickest and easier win you can get with redis is to use it for some caching. Just configure rails to use Redis in the application.rb file, and then you're good to go. And it just works. This isn't a rails tutorial, so I'm not going to really go in to any more details. It just works.
So, what make redis maybe better caching that something like a file store. Well, other than speed, there is the fact that it can store objects other than just strings. It can handle lists, sets, hashes and strings like a champ. It also has built in support for expirations, so that's nice too.
Apart from simple caching, you can also use it as a great job queue. From what I've been reading, it seems to be a best practice to keep jobs our of your database, despite the widespread use of things like DJ. And, there are a few job queues out there for ruby+rails that do make make use of redis as a job queue.
So, what makes redis maybe better than a DB for jobs? Well, factors include the fact that with Redid'sbuiltin support for lists, you can also treat them like queues. With push and pop commands available on any list, redis makes lists work like queues just like we want.
Yet another really great feature of redis is pub/sub support. Pub sub isn't something every company has a need for, but once you're already using redis for your caching and queueing needs, it just makes sense to give redis yet another responsibility. I guess we're all here because we think the future of technology is in the cloud (or you just love ruby enough to put up with all these rails guys/gals), then you might have used websockets in your application. And if you have, then you might have decided to go with a technology other than ruby on rails. Perhaps something more evented. So, whatever your technology choice, pub/sub comes very much in handy when trying to communicate with services around your infrastructure. And, with clients available in so many languages, choosing redis is never hard.
So, why choose redis for this particular task? Well, do you really need any more reasons other than the fact that it is stable and fast? I think the other reason we've ever had a redis machine go down was because it ran out of membory or disk space.
Alright, what about using redis as your primary database? Well, I can't reallly comment on that since I've never done it. It might be a good idea if that’s your thing. But, the point I want to re-iterate, is that I don’t see it as an either-or decision. I think you should use both, and divide the work according them depending the specifics of your use case.
Alright, there's still more you can use redis for. A lot of people get a lot of value out of using redis for for other tasks around their infrastructure. Use cases you might want to consider using redis with are counting page views, recording metrics. This is really nice if you use redis's built in `increment` function.Also, maintaining a set of users that are presently online. This works really well if you combine redis's built-in union support, so you can find out who's online, and also a friend of Alice.
Another more esoteric use case might be maintaining some sort of resource lock across your network. You can have a machine attempt to set a key if it doesn't already exist. That gives you the ability for one machine to hold a resource. Then, the machine can delete the key when they're done. You can even set the key to expire after a period of time if you want to timeout usage.This is an example where I attempt to set aquire a resource, and give a user of that resource a token. So, I'm combining a few features of redis here, including the `set if not existant`, `multi` for multiple command execution which I spoke of earlier, and then later we can delete those key-value pairs with an atomic multi delete operation.
So yeah, redis gives you a lot in 1 simple package. There are many more features that I didn't speak up, like string maniputation, hashes, set functions, sorted sets, scripting and much more.What I really wanted to get across with this talk, is that redis is much more than a database and can be used in many creative ways. There doesn't exist another package out there that gives you so much, with such simplicity. So, my advice is to use redis everywhere. It gives you a head start in many key, early areas, and can scale with you for years to come. And, once you have it, many of your other technology choices just fall in to place around it. It also plays nice with any other service you might want to set up around your servers.