Как правильно выбирать очередь / Владимир Перепелица (Mail.Ru Group)

Приглашаем на конференцию HighLoad++ 2024, которая пройдет 2 и 3 декабря в Москве!
--------
HighLoad++ Весна 2021
Крупнейшая профессиональная конференция для разработчиков высоконагруженных систем
17 и 18 мая 2021. Москва, Крокус-Экспо

Тезисы и презентация:

На сегодня большинство распределённых приложений требуют в качестве архитектурного элемента в том или ином виде брокер очередей. Их довольно много, при этом каждый обладает плюсами и минусами. В то же время неправильный выбор компонента очереди может поставить крест на масштабируемости или отказоустойчивости вашего приложения.
...

[OstretsovArtem]

коротко - это ликбез по очередям (о)
- зачем нужны о
- где применяются о
- облачные/субд/"сокеты на стероидах" о
- начать знакомства с очередьми со следующих кандидатов: Kafka, RabbitMQ, SQS, NATS, Tarantool;
- главные различия кандидатов из предыдущего пункта
- алгоритмы о: FIFO, LIFO, Best Effort, QoS; повтор задач в о; DLQ, созависимые задачи, TTL? голодание, пропускная способность о, масштабируемость, сохранине сообщения;
- доставка сообщения строго один раз;
- организация надежности и доступности в о: репликация очереди; кворум (типа raft)
- протоколы очередей
- необходимость мониторинга
- планировать отказ

[tumenit]

Так просто и доходчиво, отличная подача и сам доклад.

[devdevelop]

Доклад супер, побольше бы такой манеры подачи материала!

[andrrreano]

очень хороший доклад! Спасибо Владимиру!!

[Valera.k]

Интересный доклад и отлично прочитано 👍

[eldardragomir]

Думаю где смотрел доклад)))
А это с прошлого)) доклад понравился)

[-dubok-]

27:12 Какие вы странные. Уже не первый раз встречаю мысль, что «exactly once delivery» невозможна. Она возможна и реализуется очень просто — надо использовать специальное поле с порядковым номером. Если получатель получает номер не по порядку, то он перестаёт принимать новые сообщения, пока не придёт потерянное. А отправитель отправляет до тех пор, пока не получит подтверждение. То есть при контроле с обеих сторон ничего сложного нет. Этот алгоритм реализован уже давно в TCP/IP, почему он и является надёжным. Также его реализовали в Kafka аналогичным образом. Кроме того, порядок номеров гарантирует ещё и упорядоченную доставку, что также является проблемой в распределённых системах. Собственно «exactly once» и порядок доставки являются основными проблемами в таких системах и они легко решаются назначением и проверкой порядковых номеров сообщений.

Ну а в остальном доклад супер — всё по полочкам и очень понятно.

[klgp]

Очередь это механизм для согласование скоростей интерфейсов

[DevToLead]

Отличный доклад. Во-первых, выступающий не запинается. Во-вторых, ввел в тематику очередей на основе примеров. Простое введение и визуализация.

[radiopapus]

Kafka не должна переупорядочивать сообщения и вообще совершать какие-либо манипуляции над ними, она их просто хранит, всю логику берет на себя потребитель. Строить очепедь на кафке конечно можно, но по моему мнению ее придумали не для этого.

[patriskin]

Классный доклад) Но у меня всё равно есть сомнения по поводу того, что взять. Выбираю из: Кафка или RabbitMQ. Задача: прилетают заявки, которые надо обрабатывать консьюмерами. При этом заявки терять вообще нельзя, и при этом должна быть возможность добавлять консьюмеры, чтобы увеличивать пропускную способность. То есть RabbitMQ отпадает, т.к. заявки терять нельзя, но отпадает и Кафка, потому что, как я понял, я не могу много консьюмеров подключить к одному топику...

[yahorsinkevich]

Самый главный вывод должен был быть - Лучшая очередь, это лог. И упоминания про различия архитектуры очередей и распределённых логов, и соответствующих продуктов, кафка, кинезис, event hubs, pulsar итп

[PlayGameToday]

29:30 так ИБП надо было ставить, а не надеяться на БП.

[romandemidov]

Такое впечатление, что ibm mq не существует :)