Монс в чатике тарантула сформулировал правильное обоснование про механизм очередей



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



если вы готовы потерять, то:

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

если какая нода сдохнет - задачи, лежащие в ней либо птеряются, либо выполнятся позже



если готовы задвоить, но не потерять:

ставите N(>1) очередей под одни и те-же таски.

всё, как с обычными БД. выбираете мастера, работаете только с ним, если отваливается, переключаетесь и т.п.



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



чаще всего применяется первый подход

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



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



(с) fb.com/mons.anderson