NoSQL Zone is brought to you in partnership with:

Debasish specializes in leading delivery of enterprise scale solutions for various clients ranging from small ones to Fortune 500 companies. He is the technology evangelist of Anshin Software (http://www.anshinsoft.com) and takes pride in institutionalizing best practices in software design and programming. He loves to program in Java, Ruby, Erlang and Scala and has been trying desperately to get out of the unmanaged world of C++. Debasish is a DZone MVB and is not an employee of DZone and has posted 54 posts at DZone. You can read more from them at their website. View Full User Profile

PubSub with Redis and Akka Actors

04.20.2010
| 8594 views |
  • submit to reddit
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 ..
object Pub {
println("starting publishing service ..")
val p = new Publisher(new RedisClient("localhost", 6379))
p.start

def publish(channel: String, message: String) = {
p ! Publish(channel, message)
}
}
The publish method just sends a Publish message to the Publisher. Publisher is an actor defined in Akka as follows:
class Publisher(client: RedisClient) extends Actor {
def receive = {
case Publish(channel, message) =>
client.publish(channel, message)
reply(true)
}
}
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.
object Sub {
println("starting subscription service ..")
val s = new Subscriber(new RedisClient("localhost", 6379))
s.start
s ! Register(callback)

def sub(channels: String*) = {
s ! Subscribe(channels.toArray)
}

def unsub(channels: String*) = {
s ! Unsubscribe(channels.toArray)
}

def callback(pubsub: PubSubMessage) = pubsub match {
//..
}
}
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 ..
sealed trait PubSubMessage
case class S(channel: String, noSubscribed: Int) extends PubSubMessage
case class U(channel: String, noSubscribed: Int) extends PubSubMessage
case class M(origChannel: String, message: String) extends PubSubMessage
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 ..
def callback(pubsub: PubSubMessage) = pubsub match {
case S(channel, no) => println("subscribed to " + channel + " and count = " + no)
case U(channel, no) => println("unsubscribed from " + channel + " and count = " + no)
case M(channel, msg) =>
msg match {
// exit will unsubscribe from all channels and stop subscription service
case "exit" =>
println("unsubscribe all ..")
r.unsubscribe

// message "+x" will subscribe to channel x
case x if x startsWith "+" =>
val s: Seq[Char] = x
s match {
case Seq('+', rest @ _*) => r.subscribe(rest.toString){ m => }
}

// message "-x" will unsubscribe from channel x
case x if x startsWith "-" =>
val s: Seq[Char] = x
s match {
case Seq('-', rest @ _*) => r.unsubscribe(rest.toString)
}

// other message receive
case x =>
println("received message on channel " + channel + " as : " + x)
}
}
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)
1. Download redis from http://github.com/antirez/redis
2. build using "make"
3. Run server as ./redis-server


For running this sample application :-

Starting the Subscription service

1. Open up another shell similarly as the above and set AKKA_HOME
2. cd $AKKA_HOME
3. sbt console
4. scala> import sample.pubsub._
5. scala> Pub.publish("a", "hello") // the first shell should get the message
6. scala> Pub.publish("c", "hi") // the first shell should NOT get this message


Another publishing client using redis-cli

Open up a redis-client from where you installed redis and issue a publish command
./redis-cli publish a "hi there" ## the first shell should get the message

Have fun with the message formats

1. Go back to the first shell
2. Sub.unsub("a") // should unsubscribe the first shell from channel "a"
3. Study the callback function defined below. It supports many other message formats.
4. In the second shell window do the following:

scala> Pub.publish("b", "+c") // will subscribe the first window to channel "c"
scala> Pub.publish("b", "+d") // will subscribe the first window to channel "d"
scala> Pub.publish("b", "-c") // will unsubscribe the first window from channel "c"
scala> Pub.publish("b", "exit") // will unsubscribe the first window from all channels

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!




References
Published at DZone with permission of Debasish Ghosh, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Endre Varga replied on Wed, 2010/04/21 - 3:32am

Hello!
I am currently in a project that intends to use Akka and a totally message oriented architecture (our problem space is particularily well suited for this), and I was planning to use a message queue for communication between actors. Why is using Redis as a pubsub service better than a traditional messaging solution?

Debasish Ghosh replied on Mon, 2010/04/26 - 7:10am in response to: Endre Varga

Hi - Publish subscribe is also a paradigm of message based communication. It's different from point to point, which possibly, is what u r referring to. You can use either of them depending on your use case. Thanks.

James Walker replied on Sat, 2012/10/06 - 3:04am

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 The Kyle Law Firm

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.