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

Рет қаралды 27,841

2 жыл бұрын

Приглашаем на конференцию Saint HighLoad++ 2024, которая пройдет 24 и 25 июня в Санкт-Петербурге!
Программа, подробности и билеты по ссылке: vk.cc/cuyIqx
--------
--------
HighLoad++ Весна 2021
Крупнейшая профессиональная конференция для разработчиков высоконагруженных систем
17 и 18 мая 2021. Москва, Крокус-Экспо
Тезисы и презентация:
www.highload.ru/spring/2021/a...
На сегодня большинство распределённых приложений требуют в качестве архитектурного элемента в том или ином виде брокер очередей. Их довольно много, при этом каждый обладает плюсами и минусами. В то же время неправильный выбор компонента очереди может поставить крест на масштабируемости или отказоустойчивости вашего приложения.
...
--------
Нашли ошибку в видео? Пишите нам на support@ontico.ru

Пікірлер: 27

@OstretsovArtem 2 жыл бұрын

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

@tumenit 2 жыл бұрын

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

@devdevelop1891 9 ай бұрын

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

@andrrreano 6 ай бұрын

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

@Valera.k 2 жыл бұрын

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

@dmitrybabik8964 2 жыл бұрын

отличный доклад

@eldardragomir6705 2 жыл бұрын

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

@user-bn2bm2ny1n Жыл бұрын

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

@user-qt8ow7yl8i 2 жыл бұрын

спасибо за обзорный доклад

@goliafffff 2 жыл бұрын

Отличный доклад!

@kl45gp Жыл бұрын

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

@patriskin 2 жыл бұрын

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

@mikhailanazarov 2 жыл бұрын

В Kafka консюмеры входят в группы, несколько групп могут одновременно обрабатывать один топик, но все группы получат все сообщения. Также топик можно разбить на N партиций (например, остаток от деления Id на N) и тогда можно одновременно обрабатывать топик с помощью N консюмеров. При этом сообщения из одной партиции гарантированно попадут только одному консюмеру, но несколько партиций могут обрабатываться одним консюмером

@patriskin 2 жыл бұрын

@@mikhailanazarov спасибо большое за разъяснения!

@radiopapus 9 ай бұрын

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

@user-ko9cr9qh2d 10 ай бұрын

Ор с очереди😂

@PlayGameToday 2 жыл бұрын

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

@-dubok- 7 ай бұрын

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

@krolikrodjer8879 7 ай бұрын

как ты собрался проверять порядковый номер в сети, где несколько консьюмеров?)

@-dubok- 7 ай бұрын

@@krolikrodjer8879 отправитель заводит порядок для каждого консьюмера.

@georgeyarish3439 6 ай бұрын

> А отправитель отправляет до тех пор, пока не получит подтверждение. И как это должно работать? Когда комитить ack с консюмера? Если получатель обработал сообщение но не отправил подтверждение, а затем обработал его повторно и отправил? Или наоборот, получатель отправил подтверждение но ничего не обработал?

@-dubok- 6 ай бұрын

@@georgeyarish3439 консьюмер тоже должен хранить порядковый номер обработанных сообщений. Если ему приходит старое, он автоматически его подтверждает без обработки. Если приходит слишком новое, отклоняет или держит его, пока не придёт сообщение с ожидаемым номером, и затем обрабатывает их в правильном порядке. То есть, отвечая на вопрос, если он обработал, но рухнул, не отправив подтверждение, то он просто заново получит сообщение и автоматически его подтвердит, потому что оно слишком старое по порядковому номеру. А отправлять подтверждение, не обрабатывая - это уже неправильный алгоритм. Соврал - сам виноват 😁 Можно отправлять подтверждения до обработки только в том случае, если сообщение было сохранено в локальной базе обработчика для его последующей обработки.

@yahorsinkevich4451 2 жыл бұрын

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