Fun with Redis

I’ve been using Redis for projects on and off for some time, and there are some little hacks I’ve been doing and never extracted from bigger projects. Yesterday I had to sit home for some time doing a job that involved some idle time waiting, so it was time to hack.

First, I nailed a small RestMQ using Sinatra and Redis. Here’s the gist for the first version, which already works nice along with RestMQ. You can use it to expose a small part of your broker to the outside world. Later, talking with a colleague at work, I changed it a bit and ended up having the whole queue list and hard/soft get (deletes the message or just reads it). Another gist.

Then it was time of extracting Message Queue and Load Balancing patterns from code to my branch of the Redis Cookbook . Apart from the basic algorithm for RestMQ, there is a pattern which I sometimes use to do load balancing and replica spreading. It uses scored sets and although it seems naive, works pretty well along with consistent hashing.

After that I fixed some issues on RestMQ and txredisapi, the first were related to configuration issues and the later related to publish/subscribe.

About Pub/Sub, I ended up extracting a small PubSub server using Websockets, Redis and Node.js. It was initially embedded in another proxy I tried for RestMQ but it works well alone. Check the code. A little bit of code twisting and it can turn into a very flexible actor-based library for node.js. And of course, the PubSub thingy can also use redis as a presence server.

/me deserves pizza

Websockets and RESTMQ – power to web applications

Sounds cocky but that’s it. Using RestMQ, which builds on twisted, cyclone and a stack of well proven software, you can provide your applications with a robust and flexible queue over http protocol. It already was possible using COMET and GET/POST/DELETE requests, but now with websockets support it got to a new level.

Release gibberish apart there is a cool small app which streams twitter data to a html/css/js based app. Why all that work, would you say, if I can use it directly (well, not that easy because you need to provide username/pass to twitter streaming service) ? Well, for mashing up data and filtering it before delivery. Also, twitter is a convenient source of streaming data for tests, but usually you would roll up your own data source.

An actor based concurrency model or browser-based map/reduce is trivial, just like retrieving data, programming the proper javascript code to do all the work and post i back to a new queue.

Check the repository at http://github.com/gleicon/restmq_websockets and a live demo at http://cowcat.net/restmq_ws/. Note that it needs a websockets capable browser (chrome or a recent webkit build) and it may be down due to my bandwidth constraints 🙂

MongoDB and Redis for an URL shortener

I’ve wanted to prototype an URL shortener some time ago to have a measure on how long it would take to do using a NoSQL DB to store stats and do analytics. The main reason would do it using cyclone and MongoDB, and later build over it to create a tracker, web analytics tool and maybe a NGINX module.

Notes about Redis

I’ve come up with some notes about Redis, RestMQ and mongodb. Uploaded them to slideshare.

NoSQL brief (gentle) intro and some SQL anti patterns

Yesterday I’ve presented this at Locaweb/Brazil as part of our NoSQL cycle. Many other people presented interesting new ideas and I’ve opted for this intro and a piece about Redis which I may publish soon.

NoSql Introduction

View more presentations from gleicon.

Redis and python

One of the byproducts of RestMQ for me is that I got involved in a redis client in more ways than just using it. Along with fiorix, I got to know more of twisted and how to use it along cyclone, which is a tornado-on-twisted port. That helped to change from a pure twisted.web RestMQ to a more flexible setup.

Along the road, there was the need for a different redis client, which could handle connection pools, and there was txredisapi, which benefited from the experience in tx-redis and the original python redis client. It worked so well that we implemented some other features.

The most promising feature is not on RestMQ yet, but it’s on the master repo a git, which is Consistent Hashing. Consistent Hashing, in its various forms, enable setups resembling sharding and data distribution between two or more instances of Redis.

This is importante not only from the data partition point of view, but also from the avaliability one. I strongly believe that the client, or a intermediate layer, can control the data distribution in this way and not the storage server itself. Using txredisapi, the beggining of such architecture can be used, and later on, data as server free space, speed and I/O capacity can be put on the mix to help to decide how to populate a new server.

I invite you to check txredisapi, restmq and cyclone. My repo at http://github.com/gleicon also has clones and (sometimes) branches of these projects, so feel free to send patches and ideas.

RESTMQ – REST/JSON/HTTP based message queue

That’s not a replay from the last post. I’ve pushed into my github repo an initial, cleaned up version of RestMQ. This is special because it not only uses python and twisted, but cyclone, the twisted-based implementation of Tornado. Repo URL:  http://github.com/gleicon/restmq