Управление работниками для надежной очереди в Redis

Question

Это хорошо известный шаблон для использования LPUSH и BRPOPLPUSH (http://redis.io/commands/rpoplpush) для реализации прочной очереди в Редисе. Тем не менее, для того, чтобы увеличить масштаб, дизайн должен обслуживать нескольких работников/потребителей, которые BRPOPLPUSH из главной очереди задач.

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

У меня есть два вопроса относительно этого processing_queue:

1. это правильно рассуждать, что будет не более одного элемента/задач в любое время работник processing_queue? Я предполагаю, что рабочий начинает с проверки любой оставшейся задачи в своем processing_queue до BRPOPLPUSH главной очереди задач. Если это так, мы можем использовать любой из RPOP, LPOP, LREM, чтобы удалить задачу после завершения обработки работником (или просто удалить список). Мы даже можем использовать набор вместо списка. Есть ли причина, почему так много людей предпочитают использовать LREM, но больше ничего?

2. Я видел, как многие люди рекомендуют идентифицировать человека processing_queue, используя идентификатор процесса соответствующего работника. Но что происходит, когда старый работник выходит, а новый появляется с (вероятнее всего) новым идентификатором процесса. Как новый рабочий ищет своего предшественника processing_queue, чтобы завершить возможную задачу? Я планирую использовать Supervisor для управления моими рабочими процессами, если это имеет значение.

Answer 1

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

2. Я не знаком с Supervisor, но вы можете сохранить отдельную структуру данных - здесь будет лучше отсортированный набор - с идентификаторами ваших работников в качестве элементов и временной меткой в ​​качестве их оценки. Периодически обновляйте свои рабочие места, а когда вы запускаете нового работника, проверьте, установлен ли для тех, кто слишком долго простаивал. Когда они будут найдены, попробуйте установить, что он фактически мертв, а затем новый рабочий возьмет на себя соответствующие processing_queue (например, с RENAME).