Мой общий вопрос: использование Redis для PubSub, что происходит с сообщениями, когда издатели нажимают сообщения на канал быстрее, чем подписчики могут их прочитать?
Например, скажем, у меня есть:
- Простые публикации издателей со скоростью 2 мс/сек.
- Простые сообщения для чтения подписчиков со скоростью 1 msg/sec.
Мое наивное предположение заключалось в том, что абонент увидит только 50% сообщений, опубликованных в Redis. Чтобы проверить эту теорию, я написал два сценария:
pub.py
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)
sub.py
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)
Результаты
- Когда я сначала запустил
sub.py, а затемpub.py, я обнаружил, чтоsub.pyфактически отображал все сообщения (1-10) один за другим с задержкой в 1 секунду. Мое первоначальное предположение было неправильным, Redis представляет очереди сообщений. Требуется больше тестов. - Когда я сначала побежал
pub.py, а затем ждал 5 секунд перед запускомsub.py, я обнаружил, чтоsub.pyотображает только вторую половину сообщений (5-10). Я бы предположил это первоначально, но, учитывая мои предыдущие результаты, я думал, что сообщения были поставлены в очередь, что привело меня к следующему выводу...
Выводы
- Сервер Redis появляется в очереди сообщений для каждого клиента для каждого канала.
- Пока клиент слушает, не имеет значения, насколько быстро он читает сообщения. Пока он подключен, сообщения будут оставаться в очереди для этого клиента для этого канала.
Остальные вопросы
- Являются ли эти выводы действительными?
- Если да, то как долго сообщения клиента/канала остаются в очереди?
- Если да, существует ли команда
redis-cli infoдля просмотра количества сообщений в очереди (для каждого клиента/канала)?
