Паттерн идемпотентности (idempotency pattern) кратко

Привет, Вы узнаете о том , что такое паттерн идемпотентности, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое паттерн идемпотентности, idempotency pattern, идемпотентный приемник , настоятельно рекомендую прочитать все из категории Разработка программного обеспечения и информационных систем.

Идемпотентная функция - это функция, которая возвращает себя при применении к самой себе. При обмене сообщениями идемпотентный получатель сможет обработать повторяющееся сообщение, чтобы привести к тому же конечному состоянию системы, как если бы сообщение было обработано один раз.

Во-первых, является ли сообщение идемпотентным по своей сути? То есть, содержит ли он операцию, которая содержит фиксированное значение в определенный момент времени, например котировку акций, а не инструкцию преобразования, такую ​​как «добавить 5 долларов к балансу». Если сообщение естественно идемпотентно, то большую часть следующего обсуждения можно проигнорировать, потому что повторная обработка сообщения несколько раз приводит к одному и тому же значению, например, f (x) = f (f (x)).

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

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

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

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

Когда мы реактивно фильтруем сообщение, мы знаем, что вычислительные издержки обработки очень низкие и / или вероятность дублирования сообщения относительно низка. Об этом говорит сайт https://intellect.icu . В этом случае мы просто обрабатываем как обычно. Затем, когда мы пытаемся сохранить любые сообщения, подлежащие отправке, полученные в результате обработки, в наше хранилище данных, мы перехватываем уникальные ключевые нарушения (или аналогичные исключения), создаваемые нашим хранилищем данных. Если мы перехватываем исключение, мы прекращаем нашу текущую единицу работы и повторно отправляем сообщения, сохраненные в хранилище данных.

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

Основная тема, связанная с этим последним «шаблоном», заключается в том, что мы не можем по-настоящему обернуть всю работу в единицу и отправить ее как пакет, потому что мы работаем с нетранзакционным ресурсом. Одним из возможных решений было бы просто запросить нетранзакционный ресурс для определения состояния данного сообщения. Одна из проблем - это задержка при запросе удаленных ресурсов, таких как веб-службы, через HTTP. Другие соображения могут включать в себя то, что за некоторые HTTP-вызовы взимается плата за каждый вызов, что делает выполнение запроса проверки статуса для каждого отдельного сообщения чрезмерно дорогим. Наконец, некоторые ресурсы могут даже не поддерживать операцию запроса.

На этом этапе нам, вероятно, следует немного больше уточнить значение нетранзакционного ресурса. Хотя ресурс может быть транзакционным в том смысле, что он выполнил или не выполнил операцию, фактически это все или ничего только для одного вызова, например веб-службы. Более того, наше приложение может даже не знать, что удаленный вызов был успешным или неудачным, потому что ответ так и не вернулся в наше приложение. Или наш процесс мог быть завершен после того, как пакет «запрос» был отправлен по сети, но до того, как был получен какой-либо пакет «ответа».

Кроме того, то, что мы работаем с нетранзакционным ресурсом, не означает, что мы не можем эффективно моделировать транзакционное поведение, записывая статус приложения в наш собственный долговечный ресурс.

В случаях, когда ресурс поддерживает запросы, мы можем реализовать несколько методов, чтобы избежать чрезмерных, а иногда и дорогостоящих вызовов. Первый способ - записывать статус вызова на каждом шаге в надежный ресурс. Например, когда мы собираемся вызвать веб-службу, мы фиксируем этот факт. Когда мы получаем результаты вызова веб-службы, мы также регистрируем этот факт. Наконец, когда мы собираемся отправить сообщение, содержащее результаты вызова веб-службы, мы регистрируем это сообщение в нашем хранилище сообщений. Когда мы получаем сообщение из нашей собственной очереди и обрабатываем его, мы должны проверить журнал, чтобы определить, какая работа, если таковая была, была проделана для этого конкретного сообщения. Если мы ранее регистрировали, что вызывали веб-службу, но не было записано соответствующей записи в журнале для результатов вызова веб-службы,

Давайте посмотрим на вышеизложенное, например, на вызов веб-службы доставки из Meest express или, возможно, на обработку транзакции по кредитной карте. Если наше приложение зарегистрировало, что мы вызвали веб-службу, но в журнале нет записи, содержащей результаты, мы можем запросить веб-службу и спросить, что было сделано для кредитной карты ABC или заказа 1010. В зависимости от результатов мы можем предпринять соответствующие действия например, авторизация кредитной карты, если транзакция не была получена, или получение с места, где предыдущая попытка не удалась.

Последний «шаблон», заслуживающий нашего рассмотрения, - это когда ресурс не поддерживает операции запроса. Здесь все становится немного запутанным, потому что у нас нет возможности узнать, действительно ли работа была выполнена. Канонический пример - отправка электронного письма при подключении к SMTP-серверу. Как и в предыдущем сценарии вызова Meest express, мы можем выполнить практически все те же действия. Ключевое отличие состоит в том, что мы не можем выполнить запрос, чтобы определить состояние задействованного ресурса. В этом случае нам, возможно, придется принять небольшой уровень несогласованности для очень специфического условия отказа.

Упомянутое несоответствие - это возможность отправки электронного письма дважды (продолжение примера с SMTP). Если наш процесс завершается после того, как мы регистрируем, что мы собираемся вызвать SMTP-сервер (и, возможно, после того, как был вызван SMTP-сервер), но до того, как мы сможем зарегистрировать, что SMTP-сервер был вызван, у нас нет абсолютно никакого способа узнать, что работает было сделано. В этом случае у нас нет другого выбора, кроме как выполнить операцию снова. В то же время, действительно ли так плохо, если конечный пользователь получает письмо дважды?

Идемпотентный паттерн в REST API

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

Идемпотентные методы

Идемпотентный HTTP-метод - это HTTP-метод, который можно вызывать много раз без разных результатов. Не имеет значения, вызывается ли метод только один раз или десять раз. Результат должен быть таким же.

Примеры

GET

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

PUT

Метод идемпотентный , как вызов методы PUT несколько раз обновят тот же ресурс и не изменить результат.

POST

Это не идемпотентная , и вызов POST метод несколько раз может иметь разные результаты и приведет к созданию новых ресурсов.

DELETE

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

Заключение

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

Конечно, это лишь краткое изложение некоторых из различных «шаблонов» для создания идемпотентных сообщений. Примеры немного произвольны и надуманы, и мы можем легко проделать в них дыры, но принципы все же остаются в силе.

Идемпотентный получатель полезен для предотвращения нарушения порядка или дублирования обработки сообщений. В CPI идемпотентность зависит от самого сообщения и получателя.

Исследование, описанное в статье про паттерн идемпотентности, подчеркивает ее значимость в современном мире. Надеюсь, что теперь ты понял что такое паттерн идемпотентности, idempotency pattern, идемпотентный приемник и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Разработка программного обеспечения и информационных систем