Кирилл О. спрашивает: А расскажите на пальцах зачем нужны всем эти системы очередей, то есть прям на примере что вот есть сервис и нам нужно что-то такое там делать, и для этого мы используем систему очередей? В моей представлении это что-то вроде отложенных операций, то есть мы кладем таску куда-то и она фоном потом исполняется, но я не понимаю какое может быть практическое применение. Простите за нубский вопрос, просто интересно, а в интернете прочитать про практику не получается, может быть плохо искал...
Очереди придумали, чтобы решить огромную архитектурную проблему синхронных взаимодействий.
Есть понятие синхронной и асихронной работы. Когда в браузере кто-то жмакает кнопочку и запрос уходит на бекенд: заблокирован браузер и воркер бекенда (если упрощённо) до момента ответа бекенда браузеру. Блокировка воркера бекенда опасна тем, что в этот момент он занят и другие браузеры не могут к нему обратится. Решается это созданием пула воркеров бекенда, которого предположительно должно хватить на всех желающих. Такое взаимодействие называется синхронным.
Теперь предположим бекенд получил тяжёлую задачу от браузера, связанную со взаимодействием с другими серверами (наиболее распространённая задача в интернет-магазинах: отправка e-mail, платёж по кредитке, оформление заказа в службе доставка, обновление данных по курсам валют и тд и тп). В блокировку при синхронном взаимодействии вступают уже эти сторонние сервера, которые тоже кого-то внутри себя блокируют.
Такое взаимодействие очень часто выстраивают начинающие разработчики. Браузеры не всегда готовы держать долго коннект и, например, перепосылают запрос. В результате у нас уже блокируется не одна цепочка, а две, три и тд
В случае работы с платёжными системами регулярно при таких вот архитектурных проблемах возникают ошибки повторных платежей, когда вы списываете с пользователя не 100 рублей, а например 5 раз по 100 рублей. И тактическим костылём эту архитектурную проблему не исправить.
Чтобы избежать таких блокировок придумали асинхронное взаимодействие. Браузер посылает запрос на воркер бекенда, который регистрирует в очереди задачу и тут же возвращает браузеру идентификатор этой задачи, освобождая таким образом блокировку. Сам браузер периодически дёргает воркер бекенда и спрашивает, - а не решилась ли задача с таким вот идентификатором? Не решилась? Тогда я через 15 секунд ещё раз попробую. О! Решилась! Дайте результат! Пользователь, смотри, - Твой платёж прошёл!!!
Задача в очереди выполняется независимо от взаимодействия браузера и воркера бекенда, организуя таким образом асинхронное взаимодействие.
В современных языках есть более тонкое управление асинхронными взаимодействиями - на уровне процессов. Оно позволяет бекенд делать отзывчивым и готовым принять практически любое количество запросов.
Важно всегда держать в голове простое правило - любое взаимодействие с браузером должно быть мгновенным. Всё, что тяжелее 1-2х запрос в бд и простых операций с переменными, следует выносить в асинхронные процессы. В противном случае выполненная фича будет возвращаться целым букетом багов, что влияет на удлинение сроков и затрат на разработку системы в целом.
Несмотря на то, что очереди используются десятилетиями, многие аутсорсные команды разработки только слышали про очереди и реально их не используют в работе.
Очереди придумали, чтобы решить огромную архитектурную проблему синхронных взаимодействий.
Есть понятие синхронной и асихронной работы. Когда в браузере кто-то жмакает кнопочку и запрос уходит на бекенд: заблокирован браузер и воркер бекенда (если упрощённо) до момента ответа бекенда браузеру. Блокировка воркера бекенда опасна тем, что в этот момент он занят и другие браузеры не могут к нему обратится. Решается это созданием пула воркеров бекенда, которого предположительно должно хватить на всех желающих. Такое взаимодействие называется синхронным.
Теперь предположим бекенд получил тяжёлую задачу от браузера, связанную со взаимодействием с другими серверами (наиболее распространённая задача в интернет-магазинах: отправка e-mail, платёж по кредитке, оформление заказа в службе доставка, обновление данных по курсам валют и тд и тп). В блокировку при синхронном взаимодействии вступают уже эти сторонние сервера, которые тоже кого-то внутри себя блокируют.
Такое взаимодействие очень часто выстраивают начинающие разработчики. Браузеры не всегда готовы держать долго коннект и, например, перепосылают запрос. В результате у нас уже блокируется не одна цепочка, а две, три и тд
В случае работы с платёжными системами регулярно при таких вот архитектурных проблемах возникают ошибки повторных платежей, когда вы списываете с пользователя не 100 рублей, а например 5 раз по 100 рублей. И тактическим костылём эту архитектурную проблему не исправить.
Чтобы избежать таких блокировок придумали асинхронное взаимодействие. Браузер посылает запрос на воркер бекенда, который регистрирует в очереди задачу и тут же возвращает браузеру идентификатор этой задачи, освобождая таким образом блокировку. Сам браузер периодически дёргает воркер бекенда и спрашивает, - а не решилась ли задача с таким вот идентификатором? Не решилась? Тогда я через 15 секунд ещё раз попробую. О! Решилась! Дайте результат! Пользователь, смотри, - Твой платёж прошёл!!!
Задача в очереди выполняется независимо от взаимодействия браузера и воркера бекенда, организуя таким образом асинхронное взаимодействие.
В современных языках есть более тонкое управление асинхронными взаимодействиями - на уровне процессов. Оно позволяет бекенд делать отзывчивым и готовым принять практически любое количество запросов.
Важно всегда держать в голове простое правило - любое взаимодействие с браузером должно быть мгновенным. Всё, что тяжелее 1-2х запрос в бд и простых операций с переменными, следует выносить в асинхронные процессы. В противном случае выполненная фича будет возвращаться целым букетом багов, что влияет на удлинение сроков и затрат на разработку системы в целом.
Несмотря на то, что очереди используются десятилетиями, многие аутсорсные команды разработки только слышали про очереди и реально их не используют в работе.