С очередями всё просто. У вас есть выбор: либо вы

Question

С очередями всё просто. У вас есть выбор: либо вы

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

если вы готовы потерять, то:
никакой репликации, ставите несколько нод, выдача id'шников внешняя (или uuid). кидаете задачи round-robin'ом, потребляете из всех
если какая нода сдохнет - задачи, лежащие в ней либо птеряются, либо выполнятся позже

если готовы задвоить, но не потерять:
ставите N(>1) очередей под одни и те-же таски.
всё, как с обычными БД. выбираете мастера, работаете только с ним, если отваливается, переключаетесь и т.п.

если нужна strong-consistency: вам точно нужны очереди? ))

чаще всего применяется первый подход
для второго хорошо подходят идемпотентные операции (тогда можно не париться из-за двойной обработки)

Т.о. queue, как базовый элемент конструктора, может использоваться, но для распределённых/отказоустойчивых архитектур требуются дополнительные на[д]стройки. Как впрочем и с любым инструментом