Я думаю, что ваше предположение об ответственности платформы Spring-Cloud-Stream неверно.Spring-cloud-stream в двух словах - это структура, отвечающая за подключение и адаптацию производителей / потребителей , предоставленных разработчиком, к брокеру (ям) сообщений, предоставляемым связывателем spring-cloud-stream (например, Kafka,Кролик, Кинезис и т. Д.).Таким образом, ответственность за соединение с брокером, получение сообщения от брокера, его десериализацию, вызов кода пользователя, сериализацию сообщения и его отправку обратно брокеру входит в сферу ответственности платформы.Таким образом, вы можете рассматривать это как чисто инфраструктуру.
То, что вы описываете, является скорее проблемой приложения, так как фактический получатель - это то, что пользователь разработает в рамках процесса разработки весеннего облачного потока, следовательноответственность за идемпотентность лежит на таком пользователе.Кроме того, большинство брокеров уже обрабатывают идемпотентность (в некотором роде), гарантируя, что конкретное сообщение было доставлено только один раз.Тем не менее, если кто-то отправит идентичное сообщение такому брокеру, он не будет знать, что оно является дубликатом, поэтому требование идемпотентности и / или дедупликации остается в силе, но, как вы можете видеть, это не так просто, учитывая количество факторовкоторые находятся в игре, где ваше понимание идемпотентности может отличаться от моего, следовательно, наши подходы могут также отличаться.И последнее (частично, чтобы доказать мою последнюю точку зрения): может безопасно получать одно и то же сообщение несколько раз. - Это все, что говорится, но что действительно означает для вас безопасно противя против другого человека?