Понимание того, почему вы хотите обрабатывать очереди сообщений в будущем - PullRequest
0 голосов
/ 22 февраля 2020

Так что я пытаюсь понять, какие практические проблемы решают Очереди. Читая всю информацию от Google, я получаю сообщение высокого уровня.

  • Pu sh в очередь для последующей обработки

Так что я глядя на архитектуру от Компании A, и у них есть различные варианты использования для Очереди Работы как например

  • сообщения чата
  • преобразование файла
  • поиск
  • Тяжелый sql запросов

Зачем обрабатывать его позже?

Вот мое лучшее предположение ...

  1. Допустим, у меня есть приложение, которое может обрабатывать 10 «вещей» одновременно.
  2. Мое приложение затем максимально увеличивает свою вычислительную мощность.
  3. поступил 11-й запрос, поэтому приложение помещает его в очередь для последующей обработки

Предполагая, что это действительный вариант использования, разве не имеет смысла добавлять больше серверов для обработки большего количества «вещей»? Это потому, что дороже добавлять больше серверов, чем использовать Очередь и немного жертвовать временем отклика?

Учитывая мои примеры использования, какие еще проблемы решат для них Очереди?

Ответы [ 2 ]

4 голосов
/ 22 февраля 2020

Вы когда-нибудь были в банке, когда он занят? Вы бы подождали в очереди.

«Но, - можно сказать, - не имеет смысла добавлять больше сотрудников для обработки большего числа клиентов? Это потому, что добавлять персонал дороже, чем нанимать очередь» и немного пожертвовать временем отклика? "

Это было бы правильно. Это может быть довольно затратным для персонала банка, исходя из пикового числа клиентов , которые будут приходить каждый день. Работать с персоналом ниже этого уровня дешевле, и некоторые клиенты ждут в очереди.

Кроме того, число клиентов в день не предсказуемо на 100% . Очередь позволяет избыточному спросу ждать, не нарушая систему.

Очереди включают развязку .

Например, представьте интернет-магазин , где покупатели покупают пункт. Они выбирают товар, предоставляют номер кредитной карты и нажимают кнопку «Купить». Если кредитная карта отклонена, интернет-магазин может сразу же попросить их повторно ввести номер. Это взаимодействие должно происходить немедленно, пока клиент еще находится в сети.

Однако клиенту не нужно ждать, пока генерируется счет-фактура, в систему учета добавляется запись, а инвентаризация списывается. полка. Это может быть отделен от процесса заказа. Хороший способ сделать это состоит в том, чтобы поместить sh порядок в очередь, которая может обрабатываться следующей системой .

Если эта «следующая система» окажется в автономном режиме при на данный момент нет причин отменять всю продажу . Транзакция может быть обработана, когда «следующая система» вернется в онлайн. Это гораздо лучше, чем сбои всего процесса только потому, что один компонент (который не требуется немедленно) имеет сбой.

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

0 голосов
/ 22 февраля 2020

Давайте сделаем сценарий ios

Сценарий 1 без очереди :

  • вы запрашиваете конечную точку / blabla / do-eveything /
  • по этому запросу

    1. загрузить изображение с очень медленного FTP, например 1,5 se c (может ошибка, повторите попытку? Добавить + X se c)

    2. прикрепить изображение к электронному письму

    3. отправить электронное письмо (3 се c), например, 1 се c (может ошибка, повторить попытку? Добавить + X se c)

    4. подтверждение получено> подтверждение магазина для отслеживания третьей компанией, например 1,5 (может быть ошибка, повторите попытку? + X se c)

    5. при подтверждении отслеживания обновите данные другой третьей компании для целей больших данных, например, 2 se c (может произойти ошибка, повторите попытку? + X se c)

    6. ... вы получаете идеад

    7. возвращать ответ, например, 11 с c позже (это медленно) или больше или таймаут, когда все не удалось

Конечный пользователь сказал, что inte rnet был f Астер 20 лет go, может быть, мне нужно изменить свое соединение inte rnet или изменить мои 16 потоков


Сценарий 2 - очередь все, что вы можете :

  • вы запрашиваете конечную точку / blabla / do-eveything /
  • этот запрос делает

    1. Задание очереди "DO_EVERYTHING", например 0,02 se c

    2. Вернуть ответ менее 0,250 se c

Конечный пользователь сказал т. е. веб-сайт / приложение слишком быстрое, я могу сохранить свое 56K inte rnet соединение

в системе очередей / событий; одно неудачное задание можно повторить позже, не давая конечному пользователю возможность приостановить задание, добавьте неограниченное число задач / шагов после исходного сообщения. Лучшая отказоустойчивость


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

Да, может быть, больше работы, больше думать, но Конец не нужно думать о работе, когда праздники

...