Monday, April 19, 2010

PubSub with Redis and Akka Actors

Redis (the version on the trunk) offers publish/subscribe based messaging. This is quite a big feature compared to the typical data structure oriented services that it had been offering so far. This also opens up lots of possibilities to use Redis as a messaging engine of a different kind. The sender and the receiver of the messages are absolutely decoupled from each other in the sense that senders do not send messages to specific receivers. Publishers publish messages on specific channels. Subscribers who subscribe to those channels get them and can take specific actions on them. As Salvatore notes in his weekly updates on Redis, this specific feature has evolved from lots of user requests who had been asking for a general notification mechanism to trap changes in the key space. Redis already offers BLPOP (Blocking list pop operation) for similar use cases. But still it's not sufficient to satisfy the needs of a general notification scheme. Salvatore explains it in more details in his blog post.

I have been working on a Scala client, which I forked from Alejandro Crosa's repository. I implemented pubsub very recently and also have integrated it with Akka actors. The full implementation of the pubsub client in Scala is in my github repository. And if you like to play around with the Akka actor based implementation, have a look at the Akka repository.

You define your publishers and subscribers as actors and exchange messages over channels. You can define your own callbacks as to what you would like to do when you receive a particular message. Let's have a look at a sample implementation at the client level .. I will assume that you want to implement your own pub/sub application on top of the Akka actor based pubsub substrate that uses the redis service underneath.

Implementing the publisher interface is easy .. here is how you can bootstrap your own publishing service ..



The publish method just sends a Publish message to the Publisher. Publisher is an actor defined in Akka as follows:



The subscriber implementation is a bit more complex since you need to register your callback as to what you would like to do when you receive a specific type of message. This depends on your use case and it's your responsibility to provide a proper callback function downstream.

Here is a sample implementation for the subscriber. We need two methods to subscribe and unsubscribe from channels. Remember in Redis the subscriber cannot publish - hence our Sub cannot do a Pub.



I have not yet specified the implementation of the callback. How should it look like ?

The callback will be invoked when the subscriber receives a specific type of message. According to Redis specification, the types of messages which a subscriber can receive are:

a. subscribe
b. unsubscribe
c. message

Refer to the Redis documentation for details of these message formats. In our case, we model them as case classes as part of the core Redis client implementation ..



Our callback needs to take appropriate custom action on receipt of any of these types of messages. The following can be one such implementation .. It is customized for a specific application which treats various formats of messages and gives appropriate application dependent semantics ..



Note in the above implementation we specialize some of the messages to give additional semantics. e.g. if I receive a message as "+t", I will interpret it as subscribing to the channel "t". Similarly "exit" will unsubscribe me from all channels.

How to run this application ?

I will assume that you have the Akka master with you. Also you need to have a version of Redis running that implements pubsub. You can start the subscription service using the above implementation and then use any other Redis client to publish messages. Here's a sample recipe for a run ..

Prerequisite: Need Redis Server running (the version that supports pubsub)



For running this sample application :-

Starting the Subscription service



Starting a Publishing service



Another publishing client using redis-cli



Have fun with the message formats



The full implementation of the above is there as a sample project in Akka master. And in case you are not using Akka, I also have a version of the above implemented using Scala actors in the scala-redis distribution.

Have fun!

3 comments:

greenhorn said...

Hello,
i'm interested in this approach as I'm using redis in a context where it could some day make use of this. How does it compare to the existing akka remote actors? I see you did a commit recently:
https://github.com/debasishg/akka-redis-pubsub/blob/master/src/main/scala/RedisPubSub.scala

I don't understand why you need to import akka.persistenc.redis ? (support of akka persistence has been dropped )

BTW, i'd consider to use your scala redis, but I need transactions. any chance?

regards,
Ingvar

Debasish said...

Hello -

Akka remote actors are more powerful and offers a complete implementation of the actor model. Redis pubsub is lightweight and is only focused for that functionality only. If u need only pubsub, then u can give it a try.

Regarding the import, it's not required. I will rectify it whenever I get some time.

Regarding transaction support, r u talking about MULTI/EXEC ? It's supported in scala-redis. Have a look at https://github.com/debasishg/scala-redis/blob/master/src/main/scala/com/redis/RedisClient.scala#L62 and https://github.com/debasishg/scala-redis/blob/master/src/test/scala/com/redis/PipelineSpec.scala ..

Thanks for your interest in scala-redis.

greenhorn said...

Hi!
thanks for the answer. Really nice code. much shorter than jedis.
Understanding the code is a good scala exercise :-)
Is there any documentation I'm missing? some starting point? When I get some time to try it out, I might contrib with some simple tutorial on the github wiki if you like.
Another question: it seems you only have commands that accept strings as input, is that right? No way to directly use byte[] as input?
Btw, relying on String.getBytes and new String(somebytearray) is very slow! have a look at my converter https://github.com/ib84/castriba it would be suitable only for "payload" strings, not internals, but it's 3 times faster!
regards,
Ingvar