Я использую RabbitMQ в качестве очереди сообщений в сервис-ориентированной архитектуре, где многие отдельные веб-службы публикуют сообщения, связанные с очередями RabbitMQ. Эти очереди, в свою очередь, подписаны различными потребителями, которые выполняют фоновую работу; довольно ванильный вариант использования для RabbitMQ.

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

Каков наилучший способ перехода в эти новые очереди без потери сообщений в производственной системе?

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

Вот некоторые из проблем, с которыми я сталкиваюсь:

Поскольку очереди RabbitMQ являются идемпотентными, разрозненные веб-службы объявляли очереди перед публикацией в них (если они еще не существуют). Как только вы измените параметры очереди (но сохраните тот же ключ маршрутизации), объявить очередь не удастся, и RabbitMQ закроет канал.

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

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