Как бы вы реализовали рабочую очередь в etcd

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

• Рабочим должно быть эффективно (т. е. O(1) круговых обращений по сети) получение элемента из рабочей очереди.
• Если рабочий умирает или иным образом терпит неудачу при обработке предмета, предмет становится доступным для других рабочих.

Итак, идея состоит в том, чтобы иметь две очереди: ожидающую очередь и текущую очередь. Изначально все элементы находятся в очереди ожидания.

Когда рабочий процесс пытается получить элемент, он передает его из очереди ожидания в очередь выполнения с помощью транзакции (доступной в etcd 3). В той же транзакции рабочий также создает блокировку для элемента. Замок охраняется арендой, поэтому он автоматически удаляется, если работник умирает.

Если рабочий процесс успешно завершает обработку элемента, он удаляет элемент из текущей очереди, и все готово. В случае сбоя рабочего процесса блокировка истечет, а элемент останется в очереди выполнения.

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

Или, как упомянул @dannysauer в комментариях, у вас также может быть другой отказоустойчивый процесс, который переносит элементы из текущей очереди обратно в ожидающую очередь.

Я полагаю, что вы уже решили эту проблему, но я бы сделал это, перечислив содержимое каталога рабочей очереди (что вы получаете, когда вы в любом случае извлекаете каталог). Затем просто начните спускаться по списку, пытаясь создать блокировки с одинаковыми именами в каталоге блокировки, пока не получите блокировку. Создание «файла» блокировки является атомарным, если вы используете флаг «prevExist = false», поэтому, если вы успешно создали его, вы тот, у кого есть блокировка для этого элемента.

В идеале у вас должна быть грубая оценка того, сколько времени потребуется для обработки элемента, и вы устанавливаете TTL немного больше, чем это (или вы периодически обновляете TTL после шагов, время которых вы можете оценить). Либо вы удаляете элемент из исходной очереди (и, возможно, воссоздаете его в «завершенном» каталоге), когда закончите, либо срок действия вашей блокировки истекает, и кто-то другой забирает его.

Кроме того, в идеале вы должны поместить свой уникальный «идентификатор узла» (имя хоста, что угодно) в файл блокировки, чтобы ваши обновления TTL выполняли сравнение и установку, что не удастся, если вы потеряете блокировку из-за слишком долгого времени.

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