Во, спасибо за конкретный пример!

Спасибо большое за развернутый ответ - это то, что я хотел узнать!

всё ли понятно в моём объяснении? Я готов подробнее детали пояснить, если требуется, чтобы окончательно решить поднятый вопрос.

На том уровне, на котором я нахожусь, мне более чем понятен ваш ответ, спасибо большое за такое развернутое пояснение!

Кирилл О. спрашивает: А расскажите на пальцах зачем нужны всем эти системы очередей, то есть прям на примере что вот есть сервис и нам нужно что-то такое там делать, и для этого мы используем систему очередей? В моей представлении это что-то вроде отложенных операций,  то есть мы кладем таску куда-то и она фоном потом исполняется, но я не понимаю какое может быть практическое применение. Простите за нубский вопрос, просто интересно, а в интернете прочитать про практику не получается, может быть плохо искал...


Очереди придумали, чтобы решить огромную архитектурную проблему синхронных взаимодействий.

Есть понятие синхронной и асихронной работы. Когда в браузере кто-то жмакает кнопочку и запрос уходит на бекенд: заблокирован браузер и воркер бекенда (если упрощённо) до момента ответа бекенда браузеру. Блокировка воркера бекенда опасна тем, что в этот момент он занят и другие браузеры не могут к нему обратится. Решается это созданием пула воркеров бекенда, которого предположительно должно хватить на всех желающих. Такое взаимодействие называется синхронным.

Теперь предположим бекенд получил тяжёлую задачу от браузера, связанную со взаимодействием с другими серверами (наиболее распространённая задача в интернет-магазинах: отправка e-mail, платёж по кредитке, оформление заказа в службе доставка, обновление данных по курсам валют и тд и тп). В блокировку при синхронном взаимодействии вступают уже эти сторонние сервера, которые тоже кого-то внутри себя блокируют.

Такое взаимодействие очень часто выстраивают начинающие разработчики. Браузеры не всегда готовы держать долго коннект и, например, перепосылают запрос. В результате у нас уже блокируется не одна цепочка, а две, три и тд

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

Чтобы избежать таких блокировок придумали асинхронное взаимодействие. Браузер посылает запрос на воркер бекенда, который регистрирует в очереди задачу и тут же возвращает браузеру идентификатор этой задачи, освобождая таким образом блокировку. Сам браузер периодически дёргает воркер бекенда и спрашивает, - а не решилась ли задача с таким вот идентификатором? Не решилась? Тогда я через 15 секунд ещё раз попробую. О! Решилась! Дайте результат! Пользователь, смотри, - Твой платёж прошёл!!!

Задача в очереди выполняется независимо от взаимодействия браузера и воркера бекенда, организуя таким образом асинхронное взаимодействие.

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

Важно всегда держать в голове простое правило - любое взаимодействие с браузером должно быть мгновенным. Всё, что тяжелее 1-2х запрос в бд и простых операций с переменными, следует выносить в асинхронные процессы. В противном случае выполненная фича будет возвращаться целым букетом багов, что влияет на удлинение сроков и затрат на разработку системы в целом.

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

К этому вопросу позволю себе скинуть ссылочку на свой доклад на одной из YAPC::Russia: https://www.youtube.com/watch?v=YPEdbrzlgXo

в принципе верное, но слишком уж примитивное описание

Не вопрос! Давай подробное прямо сюда! :)

позже

Здесь всегда рады мнению эксперта! Приходи в любое время!

https://www.youtube.com/watch?v=FZEmZiMsm-0

Фролков Иван объсняет и ещё дальше расширяет горизонт понимания архитектуры существующих систем, выходя за рамки концепции синхронных/асинхронных интерфейсов по результатам формулировки Монса и моего краткого ликбез про очереди.

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

1. Сообщение можно рассматривать как некоторый токен, передающийся от одоного  обработчика следущим. Обработчики могут как просто передавать токен дальше (совершая при этом какие-то действия), так и создавать несколько других токенов или  ждать прибытий нескольких.

2. Это позволяет делать сложную многоступенчатую асинхронную обработку различных бизнес-задач. Уже приводился пример с отправкой почты, но он достаточно примитивен. Более подробно см. Сети Петри (1)

3. Реализация такого функционала очень удобна для организации  сколько-нибудь сложных бизнес-процессов.

4. Критически важным являеется транзакционность систем передачи сообщений: сообщение не может быть потеряно, а при поддержке всеми сторонами протокола двухфазной фиксации(2) - задублировано. Кроме того, это позволяет производить обработку бизнес-задач длительное время - часами, сутками и т.д.

5. Более подробно можно посмотреть книжку Enterprise Integration Patterns (3) Книжка большая и несколько водянистая (так было принято писать в нулевые, что уж тут поделаешь)

6. Примеры реализации: Apache Camel, Spring Integrsation, Spring JMS, MDB из JEE. Различные реализации BPMN - jBPM, Activiti, Camunda... (интересно, что эти реализации используют СУБД, а не системы передачи сообщений). Отчасти DBMS_SCHEDULER из Oracle, pgpro_scheduler и много чего еще. Есть что-то для C#, но тут я точно не могу сказать.

7. Обычно все это крепко отдает кровавым энтерпрайзом, т.к. по своей сути именно им и является. Тем не менее я сделал себе подобную штуку для php и не вижу причин иметь ее хоть для NodeJS (с другой стороны так как это кровавый энтерпрайз и  интеграционное ПО, оно легко интегрируется хоть с шелловскими скриптами)


[1] https://ru.wikipedia.org/wiki/Сети_Петри
[2] https://en.wikipedia.org/wiki/Two-phase_commit_protocol
[3] http://www.enterpriseintegrationpatterns.com/

(c) fb.com/vpupken

@IvanFrolkov что-то публика не жалует Твой концепт. Я тут сходу вспомнил сразу несколько случаев, где он неосознанно применяется, может имеет смысл рассказать про практику применения?

Например, совершенно чётко в пазы Твой концепт встаёт в заполнение сложных анкет, которые показываются посетителю послайдово и каждый следующий слайд - это узел в сети Петри.

Такая схема позволяет к примеру на сайтах типа Профи.ру собрать данные для самых сложных заказов типа ремонта квартир или заказа пластиковых окон.

С другой стороны вот мы вместе с Тобой работали над RTB сетью, архитектура взаимодействующих асинхроннно компонент опять же совершенно чётко ложится на Твой концепт!

Самый старый вариант, нарисованный ещё Нилом Подольским

Надо отдать должное Нилу, схема пережила даже сам проект)))

это не мой концепт, это стандартный подход

А можешь сходу дать тестовое задание для проверки на вшивость пыхера с graphql?

fb.com/dolphin278 отвечает: я не очень знаю, как на пыхе gql-бэкенды пилят, но по сути:

1. Я бы предложил нарисовать схему, в которой нужна пагинация, и посмотрел бы, как он ее реализовал, знает ли про механизм connection'ов, предложенный в relay.js, и какие у него сильные и слабые стороны.

2. Я бы спросил, как он собирается защищать публичны /graphql эндпойнт в проде, чтобы снаружи ему не напихали чего-то огромного толстого и нецензурно называющегося в него в виде произвольных, избыточно сложных запросов (например, большие числа в механизм пагинации из пункта 1)

3. Я бы дал какое-нибудь приложение несложное, и предложил спроектировать для нее graphql-схему, и посмотреть, где он заложится на возможное расширение ее в будущем.

3.5. В принципе, можно целый сценарий придумать, как эволюционируют требования к интерфейсу, и насколько устойчивая схема оказывается к прикладным изменениям.