Зачем использовать отдельные опросы и рабочие потоки? - PullRequest
0 голосов
/ 14 апреля 2020

Контекст: я разрабатываю приложение, которое будет принимать сообщения из различных очередей Amazon SQS. (Более 25 очередей). Для этого я подумываю о создании библиотеки для приема сообщений из очередей (назовите ее MessageConsumer)

Я хочу динамически распределять потоки для получения / обработки сообщений из разных очередей на основе на трафике c в очереди, чтобы минимизировать растрату ресурсов. Есть 2 способа, которыми я могу go об этом.

1) Может иметь только один тип потока, который опрашивает очереди, принимает сообщения и обрабатывает эти сообщения, и имеет один общий пул потоков для всех очередей. 2) Может иметь отдельные опросы и рабочие потоки.

Во втором случае у меня будет общий пул рабочих потоков и постоянное число опрошенных в очереди.

Редактировать: Для уточнения второго case: я планирую иметь 1 непрерывно работающий поток в каждой очереди, чтобы подсунуть эту очередь для количества сообщений в ней. Затем введите несколько логик c, чтобы определить количество потоков опроса, требуемых для каждой очереди, на основе количества сообщений в каждой очереди и приоритета очереди.

Я не хочу, чтобы потоки опроса работали все время, потому что это может вызывает пустое получение (sqs.receiveMessages ()), поэтому я буду распределять потоки опроса на основе traffi c. В очередях с высоким трафиком c будет больше потоков опроса и, следовательно, будет добавлено больше заданий в пул рабочих потоков.

Пожалуйста, предложите какие-либо улучшения или fl aws в этом проекте?

1 Ответ

1 голос
/ 14 апреля 2020

Рекомендуемый процесс:

  • Рабочие опрашивают очередь, используя Длинный опрос (что означает, что она будет ждать не более 20 секунд, прежде чем вернуть пустой ответ)
  • Они могут запросить до 10 сообщений за вызов ReceiveMessage()
  • Рабочий обрабатывает сообщение (я)
  • worker удаляет сообщение из очереди
  • Repeat

Если вы наберете sh для масштабирования количества работников, вы можете основать это на ApproximateNumberOfMessagesVisible metri c в Amazon CloudWatch. Если число слишком велико, добавьте рабочего . Если оно падает до нуля (или ниже некоторого порога), удаляет работника .

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

Нет нужен для "опросчиков". Рабочие сами проводят опрос. Таким образом, вы можете масштабировать работников независимо, без необходимости какой-либо центральной службы «опросов», пытаясь управлять всем этим. Просто запустите новый экземпляр Amazon EC2, запустите некоторых работников, и они начнут обрабатывать сообщения. При масштабировании просто прекращайте работу работников или даже экземпляра - опять же, нет необходимости регистрировать / отменять регистрацию работников с помощью центральной службы "опросов".

...