Несовместимость между экземплярами приложения: запретить использование rabbitmq сообщений с определенным заголовком

Question

У меня есть два экземпляра одного и того же приложения Java с использованием spring and rabbitmq. Экземпляр отправляет сообщение в очередь, но я не могу предсказать, какой экземпляр его будет потреблять (как и ожидалось).

Я обновил приложение java. По некоторым причинам несовместимость между старой и новой версиями: новая версия не может использовать сообщения из старого и наоборот.

Мы не можем предложить сбой при развертывании новой версии, поэтому мы не можем одновременно останавливать оба экземпляра. Мы должны остановить экземпляр A, перезапустить экземпляр A с обновлениями, а затем остановить B и перезапустить его с помощью обновлений.

Когда у меня есть новый экземпляр и старый экземпляр B, A не может потреблять сообщения, как ожидается, если они были произведены Б.

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

@Override 
protected Message convertMessageIfNecessary(final Object object) { 
    Message message = super.convertMessageIfNecessary(object); 
    MessageProperties messageProperties = new MessageProperties(); 
    messageProperties.setHeader("version", version);   
    return new Message(message.getBody(), messageProperties); 
} 

Это добавляет новый заголовок с версией приложения. Затем я хотел бы проверить этот заголовок, прежде чем отправить сообщение.

Например:

• А посылает сообщение с версии 4
• B получает сообщение -> не потребляет ни извед, поскольку B версия 3.
• А получает сообщение -> потребляющего потому A версия 4.

Возможно ли такое конфигурирование?

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

Спасибо за любую помощь

Answer 1

Вы можете сделать это, но это будет не очень эффективным. Когда экземпляр B (3) отклоняет сообщение, нет никакой гарантии, что повторная поставка будет отправлена ​​в экземпляр B (4); в то время как вполне вероятно, что в конечном итоге это произойдет, в зависимости от обстоятельств, во-первых, это может пойти в B (3).

Возможно, проще или проще просто привязать новую очередь к обмену; есть A (4) s публиковать в новую очередь и B (4) s потребляют от нее, а старые B (3) s потребляют из старой очереди.

Если все экземпляры A (3) не были развернуты и все сообщения, которые были из старой очереди, удалите последний B (3) и удалите очередь.