title: Redis Pubsub and Message Queueing
body: <p>My overall question is: <em>Using Redis for PubSub, what happens to messages when publishers push messages into a channel faster than subscribers are able to read them?</em></p>
  
  <p>For example, let's say I have:</p>
  
  <ul>
  <li>A simple publisher publishing messages at the rate of 2 msg/sec. </li>
  <li>A simple subscriber reading messages at the rate of 1 msg/sec.</li>
  </ul>
  
  <p>My naive assumption would be the subscriber would only see 50% of the messages published onto Redis. To test this theory, I wrote two scripts:</p>
  
  <p><strong>pub.py</strong></p>
  
  <pre><code>queue = redis.StrictRedis(host='localhost', port=6379, db=0)
  channel = queue.pubsub()
  
  for i in range(10): 
      queue.publish("test", i)
      time.sleep(0.5)
  </code></pre>
  
  <p><strong>sub.py</strong></p>
  
  <pre><code>r = redis.StrictRedis(host='localhost', port=6379, db=0)
  p = r.pubsub()
  p.subscribe('test')
  
  while True:
      message = p.get_message()
      if message:
          print "Subscriber: %s" % message['data']
      time.sleep(1)
  </code></pre>
  
  <p><strong>Results</strong></p>
  
  <ul>
  <li>When I ran <code>sub.py</code> first, immediately followed by <code>pub.py</code>, I found that <code>sub.py</code> actually displayed all the messages (1-10), one after another with a delay of 1 second in between. My initial assumption was wrong, Redis is queuing messages. More tests needed.</li>
  <li>When I ran <code>pub.py</code> first, then waited 5 seconds before running <code>sub.py</code>, I found that <code>sub.py</code> only displayed the second half of the messages (5-10). I would have assumed this originally, but given my previous results, I would have thought messages were queued, which led me to the following conclusion...</li>
  </ul>
  
  <p><strong>Conclusions</strong></p>
  
  <ul>
  <li>Redis server appears to queue messages for each client, for each channel. </li>
  <li>As long as a client is listening, it doesn't matter how fast it reads messages. As long as it's connected, messages will remain queued for that client, for that channel.</li>
  </ul>
  
  <p><strong>Remaining Questions</strong></p>
  
  <ul>
  <li>Are these conclusions valid?</li>
  <li>If so, how long will client/channel messages remained queued?</li>
  <li>If so, is there a <code>redis-cli info</code> command to see how many messages are queued (for each client/channel)?</li>
  </ul>