У меня есть базовая архитектура вопрос. Если вы хотите реализовать пользовательский интерфейс, в котором вы принимаете запрос от пользователя, сохраняете его в базе данных, помещаете в очередь сообщений (производитель очереди) и возвращаете подтверждение пользователю. Потребитель очереди запускает длительный процесс и обновляет состояние запроса как выполненное или не выполненное. Что является лучшей реализацией? Можем ли мыВариант 1: сначала сохранить в базе данных, а затем поместить в очередь сообщений? Вариант 2: поместить в очередь сообщений и затем сохранить в базе данных? Вариант 2: поместить в очередь сообщений и затем сохранить в базе данных &поставить во вторую очередь сообщений и статус обновлений второго потребителя снова в db?
Какая опция делает систему устойчивой к сбоям?
Это связано с распределенной транзакцией, которую никто больше не хочет делать. Также относится к повторным попыткам на получение ошибок, что и обеспечивает очередь сообщений выше базы данных и ручной опрос из базы данных. Что произойдет, если очередь сообщений недоступна? Что произойдет, если база данных недоступна? Нужно ли нам когда-либо реализовывать опрос из базы данных? Что делать, если мы никогда не хотим вручную опрашивать из базы данных?
Если что-то находится в БД, но не в очереди сообщений, нам нужно вручную выполнить опрос из базы данных и снова поместить в очередь сообщений. Мы хотели бы избежать опроса, потому что у нас есть очередь сообщений? Если что-то находится в очереди сообщений, но отсутствует в БД, мы не сможем ничего обновить. Таким образом, потребитель бежит, но не может найти что-нибудь для работы?
Я чувствую, что обработка ошибки производителя или подтверждение производителя из очереди является одним из важных аспектов, чтобы узнать, не работает ли очередь сообщений или нет. С точки зрения разработчика: любой подход может быть реализован при правильной реализации. скажи мне что делать. С точки зрения архитектора: что лучше?