В этой статье я постарался сфокусироваться на практиках, которые касаются работы клиентских приложений и того, что находится в области их влияния, поэтому аспекты надёжности, связанные с конфигурацией брокера, его администрированием и мониторингом, остались за скобками. Как мне кажется, они заслуживают отдельной статьи =)
Также я стремился к универсальности и не стал углубляться в специфику разных структур данных. В новых структурах, в том числе в кворумных очередях, некоторые аспекты действительно идут «из коробки» (durability, persistence), однако рекомендации остаются в силе — если не задать эти свойства явно, можно получить не только ошибки несовместимости, но и неожиданные эффекты.
Например, если в виртуальном хосте с default-queue-type: quorum объявить очередь без явного указания типа, то с durable: true получится кворумная очередь, а с durable: false — классическая.
А неперсистентные сообщения, опубликованные в кворумную очередь, могут потеряться при перезапуске брокера после выпадения в DLX, если конечная очередь окажется классической — кролик сохраняет исходный признак персистентности при dead lettering'е.
Ваше решение выглядит продуманным и вполне жизнеспособным.
На всякий случай напишу про тонкий момент, связанный с типами очередей. Если сейчас вы используете классические очереди, а со временем решите мигрировать на кворумные, то стоит иметь в виду, что кворумные очереди, в отличие от классических, по умолчанию делают requeue в конец очереди. Привычного поведения можно будет добиться, задав ограничение на количество доставок (delivery-limit).
Совершенно верно. Гарантии очерёдности при повторе из DLX, конечно же, теряются.
Спасибо за дополнения.
В этой статье я постарался сфокусироваться на практиках, которые касаются работы клиентских приложений и того, что находится в области их влияния, поэтому аспекты надёжности, связанные с конфигурацией брокера, его администрированием и мониторингом, остались за скобками. Как мне кажется, они заслуживают отдельной статьи =)
Также я стремился к универсальности и не стал углубляться в специфику разных структур данных. В новых структурах, в том числе в кворумных очередях, некоторые аспекты действительно идут «из коробки» (durability, persistence), однако рекомендации остаются в силе — если не задать эти свойства явно, можно получить не только ошибки несовместимости, но и неожиданные эффекты.
Например, если в виртуальном хосте с
default-queue-type: quorumобъявить очередь без явного указания типа, то сdurable: trueполучится кворумная очередь, а сdurable: false— классическая.А неперсистентные сообщения, опубликованные в кворумную очередь, могут потеряться при перезапуске брокера после выпадения в DLX, если конечная очередь окажется классической — кролик сохраняет исходный признак персистентности при dead lettering'е.
Ваше решение выглядит продуманным и вполне жизнеспособным.
На всякий случай напишу про тонкий момент, связанный с типами очередей. Если сейчас вы используете классические очереди, а со временем решите мигрировать на кворумные, то стоит иметь в виду, что кворумные очереди, в отличие от классических, по умолчанию делают requeue в конец очереди. Привычного поведения можно будет добиться, задав ограничение на количество доставок (delivery-limit).