Концептуальный подход к пулу очередей задач

Предположим, у меня есть распределенная очередь задач для обработки электронных писем. Каждое электронное письмо нужно было получить и проанализировать, создавая новое задание в очереди.

Теперь скорость провайдера электронной почты ограничена числом n одновременных подключений на учетную запись электронной почты, поэтому, когда мой работник запускал задачу, он получал «соединение» (под соединением я просто подразумеваю что-то для учета того факта, что теперь есть n- 1 доступных подключений для других работников для доступа к этой учетной записи). Если свободных соединений не было, рабочий возвращал задание брокеру и переходил к следующему заданию.

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

Есть ли более элегантный подход к такой ситуации?


person NFicano    schedule 20.05.2014    source источник


Ответы (1)


В основном есть два способа решить эту проблему:

  1. У вас есть 1 служба, которая будет обрабатывать количество блокировок. Таким образом, вы можете заблокировать доступ к самой атомарной блокировке в программном коде и убедиться, что максимальное количество блокировок никогда не будет превышено.
  2. Если вам нужен распределенный способ раздачи соединений без избранного лидера, единственным известным мне способом сделать это будет алгоритм Paxos.
person peter    schedule 20.05.2014