Конечная точка REST с RabbitMQ Producer

Question

допустим, у меня есть конечная точка REST, которая делает это:

1. Получает тело json, выполняет некоторое сопоставление и затем отправляет сообщение через производителя сообщений.(RabbitMQ)

2. Производитель является асинхронным.

3. У меня есть потребитель для производителя в 2, который выполнит некоторую бизнес-логику и отправит ответ.

Теперь мне нужно получить ответ после некоторых взаимодействий в моей конечной точке отдыха.

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

Думаю ли я правильный путь, или я должен просто иметь блокирующего производителя и использовать RPC как этотздесь указано: https://www.rabbitmq.com/tutorials/tutorial-six-java.html

Я хочу найти наиболее оптимальное решение.

Примечание. Я не использую Spring, поскольку изучаю все эти концепции, чтобы иметь четкое понимание.

Answer 1

Выполнение в очереди из HTTP-вызова на сервере - это нормально.

Ожидание очереди и ответ на HTTP-вызов по ее ответу не является предпочтительным способом.

1. В очереди ответов может быть много сообщений.Что произойдет, если вы получите сообщение, предназначенное для другого вызова клиента?Вы передаете сообщение соответствующему потребителю?Как вы узнаете подходящего потребителя?Вы можете повторно поставить в очередь сообщение, которое является потерей циклов.Сообщение может остаться в очереди навсегда.

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

Это лишь поверхностное представление о проблемах, которые могут возникнуть.Если ваш клиент действительно HTTP-клиент, вы можете использовать его выше для охвата важных баз вашего приложения.

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

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