Ответ
В Redis есть несколько механизмов для реализации функциональности брокера сообщений, основной из которых — Pub/Sub (Publish/Subscribe).
1. Механизм Pub/Sub
Это простая модель, где клиенты-издатели (publishers) отправляют сообщения в именованные каналы (channels), а клиенты-подписчики (subscribers) получают эти сообщения в реальном времени.
Ключевые особенности:
- Fire and Forget: Сообщения не сохраняются. Если подписчик не в сети в момент отправки, он никогда не получит это сообщение.
- Высокая скорость: Минимальные задержки, так как все операции происходят в памяти.
- Подписка по шаблону: Можно подписаться на несколько каналов, используя шаблоны (например,
PSUBSCRIBE news.*).
Пример (Python с redis-py):
# publisher.py
import redis
import time
r = redis.Redis()
r.publish('my-channel', 'Hello, World!')
# subscriber.py
import redis
r = redis.Redis()
p = r.pubsub()
p.subscribe('my-channel')
for message in p.listen():
if message['type'] == 'message':
print(f"Received: {message['data'].decode('utf-8')}")2. Альтернативы для надежных очередей
Для сценариев, где важна гарантия доставки, используются другие структуры данных Redis:
- Списки (Lists): Команды
LPUSH(добавить в очередь) иBRPOP(блокирующее извлечение) создают надежную очередь FIFO. Сообщения хранятся до тех пор, пока их не заберет обработчик. - Потоки (Streams): Наиболее мощный механизм. Предоставляет персистентные, append-only структуры данных с поддержкой групп потребителей (consumer groups), подтверждением обработки сообщений и возможностью читать историю.
Ответ 18+ 🔞
А, блядь, вот это тема! Слушай, сейчас я тебе на пальцах разложу, как в этом вашем Redis с сообщениями обходиться, а то все эти мануалы читать — терпения ноль, ебать.
Ну, во-первых, есть у них такая штука — Pub/Sub (Публикация/Подписка). Представь себе: один чувак орет в мегафон (публикует), а куча других стоят и слушают (подписываются). Канал у них общий, типа my-channel.
Но фишка в чём, сука: это чистое «отправил и забыл». Если ты в этот момент в сортире сидел и не слышал — всё, пиши пропало. Сообщение улетело в никуда, как твои надежды на повышение. Никакого хранения, только хардкор, только скорость в памяти.
Вот, смотри, как это выглядит в коде. Тыкаешь в один терминал:
# publisher.py
import redis
import time
r = redis.Redis()
r.publish('my-channel', 'Hello, World!')А в другом терминале сидит подписчик и ловит:
# subscriber.py
import redis
r = redis.Redis()
p = r.pubsub()
p.subscribe('my-channel')
for message in p.listen():
if message['type'] == 'message':
print(f"Received: {message['data'].decode('utf-8')}")Видишь? Один крикнул «Hello, World!» — другой тут же получил. Но если подписчика вырубить свет — всё, привет, сообщение на том свете.
А теперь, блядь, самое важное! Если тебе нужно что-то посерьёзнее, где сообщения не теряются, как носки в стирке, то Pub/Sub — не твой вариант, ёпта.
Тут на сцену выходят другие монстры:
-
Списки (Lists). Старая добрая очередь. Один пихает сообщение в начало командой
LPUSH, а другой с другого конца вытаскивает командойBRPOP(и ждёт, если там пусто, хитрая жопа!). Сообщение лежит, пока его не заберут. Проще пареной репы. -
И король всех вечеринок — Потоки (Streams). Вот это, блядь, мощь! Это как Pub/Sub, но на стероидах и с гарантиями. Сообщения пишутся в лог, который не стирается. Можно создавать группы потребителей, чтобы несколько работяг распределяли нагрузку. Каждое сообщение нужно явно подтвердить, типа «ок, я его обработал, можно архивировать». Можно даже заглядывать в историю, что было час назад. В общем, для серьёзных дел — это твой выбор, чувак.
Так что запомни: хочешь просто поорать на всех — Pub/Sub. Хочешь, чтобы твои поручения точно дошли и были выполнены — бери Списки или, лучше сразу, Потоки. Всё гениальное просто, как дать в ебало.