Как правильно выбирать очередь / Владимир Перепелица (Mail.Ru Group)
ฝัง
- เผยแพร่เมื่อ 3 ต.ค. 2021
- Приглашаем на конференцию Saint HighLoad++ 2024, которая пройдет 24 и 25 июня в Санкт-Петербурге!
Программа, подробности и билеты по ссылке: vk.cc/cuyIqx
--------
--------
HighLoad++ Весна 2021
Крупнейшая профессиональная конференция для разработчиков высоконагруженных систем
17 и 18 мая 2021. Москва, Крокус-Экспо
Тезисы и презентация:
www.highload.ru/spring/2021/a...
На сегодня большинство распределённых приложений требуют в качестве архитектурного элемента в том или ином виде брокер очередей. Их довольно много, при этом каждый обладает плюсами и минусами. В то же время неправильный выбор компонента очереди может поставить крест на масштабируемости или отказоустойчивости вашего приложения.
...
--------
Нашли ошибку в видео? Пишите нам на support@ontico.ru
коротко - это ликбез по очередям (о)
- зачем нужны о
- где применяются о
- облачные/субд/"сокеты на стероидах" о
- начать знакомства с очередьми со следующих кандидатов: Kafka, RabbitMQ, SQS, NATS, Tarantool;
- главные различия кандидатов из предыдущего пункта
- алгоритмы о: FIFO, LIFO, Best Effort, QoS; повтор задач в о; DLQ, созависимые задачи, TTL? голодание, пропускная способность о, масштабируемость, сохранине сообщения;
- доставка сообщения строго один раз;
- организация надежности и доступности в о: репликация очереди; кворум (типа raft)
- протоколы очередей
- необходимость мониторинга
- планировать отказ
Так просто и доходчиво, отличная подача и сам доклад.
Доклад супер, побольше бы такой манеры подачи материала!
очень хороший доклад! Спасибо Владимиру!!
Интересный доклад и отлично прочитано 👍
отличный доклад
Думаю где смотрел доклад)))
А это с прошлого)) доклад понравился)
спасибо за обзорный доклад
Очередь это механизм для согласование скоростей интерфейсов
Отличный доклад!
Отличный доклад. Во-первых, выступающий не запинается. Во-вторых, ввел в тематику очередей на основе примеров. Простое введение и визуализация.
Kafka не должна переупорядочивать сообщения и вообще совершать какие-либо манипуляции над ними, она их просто хранит, всю логику берет на себя потребитель. Строить очепедь на кафке конечно можно, но по моему мнению ее придумали не для этого.
Ор с очереди😂
Классный доклад) Но у меня всё равно есть сомнения по поводу того, что взять. Выбираю из: Кафка или RabbitMQ. Задача: прилетают заявки, которые надо обрабатывать консьюмерами. При этом заявки терять вообще нельзя, и при этом должна быть возможность добавлять консьюмеры, чтобы увеличивать пропускную способность. То есть RabbitMQ отпадает, т.к. заявки терять нельзя, но отпадает и Кафка, потому что, как я понял, я не могу много консьюмеров подключить к одному топику...
В Kafka консюмеры входят в группы, несколько групп могут одновременно обрабатывать один топик, но все группы получат все сообщения. Также топик можно разбить на N партиций (например, остаток от деления Id на N) и тогда можно одновременно обрабатывать топик с помощью N консюмеров. При этом сообщения из одной партиции гарантированно попадут только одному консюмеру, но несколько партиций могут обрабатываться одним консюмером
@@mikhailanazarov спасибо большое за разъяснения!
29:30 так ИБП надо было ставить, а не надеяться на БП.
Самый главный вывод должен был быть - Лучшая очередь, это лог. И упоминания про различия архитектуры очередей и распределённых логов, и соответствующих продуктов, кафка, кинезис, event hubs, pulsar итп
27:12 Какие вы странные. Уже не первый раз встречаю мысль, что «exactly once delivery» невозможна. Она возможна и реализуется очень просто - надо использовать специальное поле с порядковым номером. Если получатель получает номер не по порядку, то он перестаёт принимать новые сообщения, пока не придёт потерянное. А отправитель отправляет до тех пор, пока не получит подтверждение. То есть при контроле с обеих сторон ничего сложного нет. Этот алгоритм реализован уже давно в TCP/IP, почему он и является надёжным. Также его реализовали в Kafka аналогичным образом. Кроме того, порядок номеров гарантирует ещё и упорядоченную доставку, что также является проблемой в распределённых системах. Собственно «exactly once» и порядок доставки являются основными проблемами в таких системах и они легко решаются назначением и проверкой порядковых номеров сообщений.
Ну а в остальном доклад супер - всё по полочкам и очень понятно.
как ты собрался проверять порядковый номер в сети, где несколько консьюмеров?)
@@krolikrodjer8879 отправитель заводит порядок для каждого консьюмера.
> А отправитель отправляет до тех пор, пока не получит подтверждение.
И как это должно работать? Когда комитить ack с консюмера? Если получатель обработал сообщение но не отправил подтверждение, а затем обработал его повторно и отправил? Или наоборот, получатель отправил подтверждение но ничего не обработал?
@@georgeyarish3439 консьюмер тоже должен хранить порядковый номер обработанных сообщений. Если ему приходит старое, он автоматически его подтверждает без обработки. Если приходит слишком новое, отклоняет или держит его, пока не придёт сообщение с ожидаемым номером, и затем обрабатывает их в правильном порядке. То есть, отвечая на вопрос, если он обработал, но рухнул, не отправив подтверждение, то он просто заново получит сообщение и автоматически его подтвердит, потому что оно слишком старое по порядковому номеру. А отправлять подтверждение, не обрабатывая - это уже неправильный алгоритм. Соврал - сам виноват 😁 Можно отправлять подтверждения до обработки только в том случае, если сообщение было сохранено в локальной базе обработчика для его последующей обработки.
Такое впечатление, что ibm mq не существует :)
Он существует в темных подвалах кровавого энтерпрайза. Отвратительный движок с одним-единственным оправданием -- он все-таки работает.
И это не плохо.