1: Message is published on a topic before subscriber is subscribed to topic mentioned in #2 the message will be looks like lost ( Expect this is to be natural) PUBLISH TEST_QUEUE message_to_send

2: If client SUBSCRIBE to a queue (actually it is topic look no queue implementation like Active MQ or simillar middleware ) e.g. TEST_QUEUE

But how to achieve durable subscription to a topic ? ie even though subscriber is not available at the moment when message is sent to a topic and as soon as the subscriber for given topic goes up the pending messages will be delieved without loss

Comment From: ptjm

Redis's pub/sub is designed to be "fire and forget". The behaviour you describe is expected. Your best bet for achieving your desired behaviour with pub/sub is to either

  • check the return code on the publish command. If it's 0, wait a bit and try again
  • have the client send a response, and have the publisher keep republishing if it doesn't get a response

Redis has a few other ways to pass messages. You raised another issue about lpush/brpop, but it's not clear what your problem is. Regardless, if you push a bunch of messages onto a list, they will persist until you pop them off. If you perform a blocking pop on an empty list, your process will block until a message is pushed on. This doesn't give pub/sub semantics though. Only one client will get any given message.

bzpopmax and zadd can be used in a similar fashion to implement a kind-of priority queue. The proviso here is the message payload has to be unique, and the messages will always be removed in order of the score, but if multiple messages have the same score, the order of removal is not guaranteed.

Probably the closest thing to what you're hoping for is xadd/xread, or perhaps xadd/xgroup/xreadgroup. With these calls, the messages persist even after you've read them. Part of the challenge is knowing when to get rid of them. With xread, the caller is responsible for keeping track of its current position in the stream, while with xreadgroup redis keeps track. xreadgroup allows multiple clients to split up the messages in a stream, but if you have multiple groups with a single consumer in each, it can be used to fan out much like a pub/sub.

There are also various third-party modules which implement queue semantics on top of redis, so if you want to use redis but don't like the way it works, you might want to look at one of them.

Comment From: ocmvin

@ptjm Got the idea .But Interested to know more about those third-party modules