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

[@OstretsovArtem]

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

[@tumenit]

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

[@devdevelop1891]

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

[@andrrreano]

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

[@Valera.k]

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

[@-dubok-]

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

[@krolikrodjer8879]

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

[@-dubok-]

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

[@georgeyarish3439]

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

[@-dubok-]

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

[@eldardragomir6705]

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

[@kl45gp]

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

[@DevToLead]

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

[@dmitrybabik8964]

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

[@radiopapus]

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

[@ТатьянаКузнецова-т1т6м]

Ор с очереди😂

[@NikitaTemnikov-c9n]

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

[@goliafffff]

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

[@patriskin]

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

[@mikhailanazarov]

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

[@patriskin]

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

[@yahorsinkevich4451]

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

[@PlayGameToday]

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

[@romandemidov3644]

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

[@antonkuranov]

Он существует в темных подвалах кровавого энтерпрайза. Отвратительный движок с одним-единственным оправданием -- он все-таки работает.

[@oeaoo]

И это не плохо.