Co to jest operacja idempotentna?

W obliczeniach operacja idempotentna to taka, która nie ma dodatkowego efektu, jeśli zostanie wywołana więcej niż raz z tymi samymi parametrami wejściowymi. Na przykład usunięcie elementu ze zbioru można uznać za idempotentną operację na zbiorze.

W matematyce operacja idempotentna to taka, gdzie f(f(x)) = f(x). Na przykład funkcja abs() jest idempotentna, ponieważ abs(abs(x)) = abs(x) dla wszystkich x.

Te nieco odmienne definicje można pogodzić, biorąc pod uwagę, że x w definicji matematycznej reprezentuje stan obiektu, a f to operacja, która może zmienić ten obiekt. Rozważmy na przykład Python set i jego metodę discard. Metoda discard usuwa element ze zbioru i nie robi nic, jeśli element nie istnieje. Więc:

my_set.discard(x)

ma dokładnie taki sam efekt, jak dwukrotne wykonanie tej samej operacji:

my_set.discard(x)
my_set.discard(x)

Operacje idempotentne są często używane przy projektowaniu protokołów sieciowych, gdzie gwarantuje się, że żądanie wykonania operacji wystąpi co najmniej raz, ale może również wystąpić więcej niż jeden raz. Jeśli operacja jest idempotentna, nie ma nic złego w wykonaniu operacji dwa lub więcej razy.

Więcej informacji znajdziesz w artykule w Wikipedii na temat idempotence.

^{Powyższa odpowiedź zawierała wcześniej pewne nieprawidłowe i wprowadzające w błąd przykłady. Poniższe komentarze napisane przed kwietniem 2014 r. odnoszą się do starszej wersji.}

Operację idempotentną można powtórzyć dowolną liczbę razy, a wynik będzie taki sam, jak gdyby został wykonany tylko raz. W arytmetyce dodanie zera do liczby jest idempotentne.

O idempotencji mówi się dużo w kontekście usług internetowych „RESTful”. REST stara się maksymalnie wykorzystać protokół HTTP, aby zapewnić programom dostęp do treści internetowych, i zwykle różni się od usług sieciowych opartych na protokole SOAP, które po prostu tunelują usługi w stylu zdalnego wywoływania procedur wewnątrz żądań i odpowiedzi HTTP.

REST organizuje aplikację internetową w „zasoby” (takie jak użytkownik Twittera lub obraz w serwisie Flickr), a następnie używa czasowników HTTP POST, PUT, GET i DELETE do tworzenia, aktualizowania, odczytywania i usuwania tych zasobów.

Idempotencja odgrywa ważną rolę w REST. Jeśli otrzymasz reprezentację zasobu REST (np. POBIERZ obraz JPEG z Flickr) i operacja się nie powiedzie, możesz po prostu powtarzać GET raz po raz, aż operacja się powiedzie. Dla usługi internetowej nie ma znaczenia, ile razy obraz został uzyskany. Podobnie, jeśli używasz usługi internetowej RESTful do aktualizacji informacji o swoim koncie na Twitterze, możesz PUT nowe informacje tyle razy, ile potrzeba, aby uzyskać potwierdzenie z usługi internetowej. Wykonanie PUT tysiąc razy jest tym samym, co wykonanie PUT raz. Podobnie USUŃ zasobu REST tysiąc razy jest równoznaczne z jego jednorazowym usunięciem. Idempotencja znacznie ułatwia zatem konstruowanie usługi internetowej odpornej na błędy komunikacji.

Dalsza lektura: RESTful Web Services, autorzy: Richardson i Ruby (idempotencja została omówiona na stronach 103-104) oraz praca doktorska Roya Fieldinga w trybie REST. Fielding był jednym z autorów protokołu HTTP 1.1, RFC-2616, który mówi o idempotencji w sekcja 9.1.2.

Bez względu na to, ile razy wywołasz tę operację, wynik będzie taki sam.

Idempotencja oznacza, że ​​wykonanie operacji jednorazowo lub wielokrotne ma ten sam efekt.

Przykłady:

• Mnożenie przez zero. Nieważne, ile razy to zrobisz, wynik nadal będzie zerowy.
• Ustawianie flagi logicznej. Nieważne, ile razy to zrobisz, flaga pozostanie ustawiona.
• Usuwanie wiersza z bazy o podanym ID. Jeśli spróbujesz ponownie, wiersz nadal zniknie.

W przypadku czystych funkcji (funkcji bez skutków ubocznych) idempotencja oznacza, że ​​f(x) = f(f(x)) = f(f(f(x))) = f(f(f (f(x)))) = ...... dla wszystkich wartości x

W przypadku funkcji wywołujących skutki uboczne idempotencja oznacza ponadto, że po pierwszym zastosowaniu nie wystąpią żadne dodatkowe skutki uboczne. Jeśli chcesz, możesz uznać stan świata za dodatkowy „ukryty” parametr funkcji.

Zauważ, że w świecie, w którym wykonywane są współbieżne działania, może się okazać, że operacje, które uważałeś za idempotentne, przestają takie być (na przykład inny wątek może anulować ustawienie wartości flagi logicznej w powyższym przykładzie). Zasadniczo, ilekroć masz współbieżność i zmienny stan, musisz znacznie dokładniej pomyśleć o idempotencji.

Idempotencja jest często przydatną właściwością przy budowaniu solidnych systemów. Na przykład, jeśli istnieje ryzyko, że możesz otrzymać zduplikowaną wiadomość od osoby trzeciej, pomocne jest, aby procedura obsługi wiadomości działała jako operacja idempotentna, dzięki czemu efekt wiadomości wystąpi tylko raz.

Operacja idempotentna daje wynik w tym samym stanie, nawet jeśli wywołasz ją więcej niż raz, pod warunkiem, że przekażesz te same parametry.

Chciałem tylko wyrzucić prawdziwy przypadek użycia, który demonstruje idempotencję. Załóżmy, że w JavaScript definiujesz kilka klas modeli (jak w modelu MVC). Sposób, w jaki jest to często wdrażane, jest funkcjonalnie odpowiednikiem czegoś takiego (przykład podstawowy):

function model(name) {
  function Model() {
    this.name = name;
  }

  return Model;
}

Następnie możesz zdefiniować nowe klasy w następujący sposób:

var User = model('user');
var Article = model('article');

Ale jeśli spróbujesz uzyskać klasę User przez model('user') z innego miejsca w kodzie, zakończy się to niepowodzeniem:

var User = model('user');
// ... then somewhere else in the code (in a different scope)
var User = model('user');

Te dwa konstruktory User byłyby inne. To jest,

model('user') !== model('user');

Aby uczynić go idempotentnym, wystarczy dodać jakiś mechanizm buforowania, taki jak ten:

var collection = {};

function model(name) {
  if (collection[name])
    return collection[name];

  function Model() {
    this.name = name;
  }

  collection[name] = Model;
  return Model;
}

Dodając buforowanie, za każdym razem, gdy to zrobisz model('user'), będzie to ten sam obiekt, a zatem będzie idempotentny. Więc:

model('user') === model('user');

Dobrym przykładem zrozumienia operacji idempotentnej może być zamykanie samochodu za pomocą pilota.

log(Car.state) // unlocked

Remote.lock();
log(Car.state) // locked

Remote.lock();
Remote.lock();
Remote.lock();
log(Car.state) // locked

lock jest operacją idempotentną. Nawet jeśli za każdym razem, gdy uruchomisz lock, wystąpią pewne skutki uboczne, takie jak mruganie, samochód jest nadal w tym samym stanie zablokowanym, niezależnie od tego, ile razy uruchomisz operację blokowania.

Operacja idempotentna to operacja, akcja lub żądanie, które można zastosować wielokrotnie bez zmiany wyniku, tj. stanu systemu, wykraczającego poza początkowe zastosowanie.

PRZYKŁADY (KONTEKST APLIKACJI INTERNETOWEJ):

IDEMPOTENT: Wykonywanie wielu identycznych żądań ma taki sam efekt, jak wysyłanie pojedynczego żądania. Wiadomość w systemie przesyłania wiadomości e-mail jest otwierana i oznaczana w bazie danych jako „otwarta”. Wiadomość można otwierać wiele razy, ale ta powtarzająca się czynność zawsze spowoduje, że wiadomość będzie w stanie „otwartym”. Jest to operacja idempotentna. Gdy po raz pierwszy PUT dokona aktualizacji zasobu przy użyciu informacji, które nie pasują do zasobu (stanu systemu), stan systemu zmieni się wraz z aktualizacją zasobu. Jeśli wielokrotnie przeprowadzi się tę samą aktualizację zasobu, wówczas informacje zawarte w aktualizacji będą zgodne z informacjami już znajdującymi się w systemie przy każdym PUT i nie nastąpi żadna zmiana stanu systemu. Powtarzające się PUT z tymi samymi informacjami są idempotentne: pierwszy PUT może zmienić stan systemu, kolejne PUT nie powinny.

NIEIDEMPOTENTNY: Jeśli operacja zawsze powoduje zmianę stanu, np. wielokrotne wysyłanie tej samej wiadomości do użytkownika, co skutkuje za każdym razem wysyłaniem i zapisywaniem nowej wiadomości w bazie danych, mówimy, że operacja jest NIEIDEMPOTENTNA.

NIEWAŻNA: Jeśli operacja nie ma skutków ubocznych, takich jak zwykłe wyświetlenie informacji na stronie internetowej bez żadnych zmian w bazie danych (innymi słowy, tylko czytasz bazę danych), mówimy, że operacja jest NIEWOLNA. Wszystkie GET powinny być nullipotentne.

Mówiąc o stanie systemu, oczywiście ignorujemy, miejmy nadzieję, nieszkodliwe i nieuniknione efekty, takie jak rejestrowanie i diagnostyka.

Dość szczegółowe i techniczne odpowiedzi. Wystarczy dodać prostą definicję.

Idempotentny = Możliwość ponownego uruchomienia

Na przykład nie ma gwarancji, że operacja Create sama w sobie zostanie wykonana bez błędów, jeśli zostanie wykonana więcej niż raz. Ale jeśli istnieje operacja CreateOrUpdate, wówczas stwierdza ona możliwość ponownego uruchomienia (Idempotencja).

Operacje idempotentne: operacje, które nie mają skutków ubocznych, jeśli zostaną wykonane wielokrotnie.
Przykład: Operacja, która pobiera wartości z zasobu danych i, powiedzmy, drukuje je

Operacje inne niż idempotentne: Operacje, które spowodować pewne szkody, jeśli zostanie wykonany wiele razy. (Gdy zmieniają się niektóre wartości lub stany)
Przykład: Operacja polegająca na wypłacie z konta bankowego

Operacja idempotentna na zbiorze pozostawia jej elementy niezmienione, jeśli zostanie zastosowana jeden lub więcej razy.

Może to być operacja jednoargumentowa, np. absolute(x), gdzie x należy do zbioru dodatnich liczb całkowitych. Tutaj absolutny (absolutny (x)) = x.

Może to być operacja binarna, np. ułączenie zbioru zawsze zwróci ten sam zbiór.

dzięki

W skrócie operacje idempotentne oznaczają, że operacja nie przyniesie różnych wyników niezależnie od tego, ile razy wykonasz operacje idempotentne.

Na przykład, zgodnie z definicją protokołu HTTP, GET, HEAD, PUT, and DELETE są operacjami idempotentnymi; jednak POST and PATCH nie są. Dlatego czasami POST zastępuje się PUT.

moje 5c: W integracji i tworzeniu sieci idempotencja jest bardzo ważna. Kilka przykładów z życia: Wyobraź sobie, że dostarczamy dane do systemu docelowego. Dane dostarczane przez sekwencję komunikatów. 1. Co by się stało, gdyby sekwencja została zmiksowana na kanale? (Jak zawsze pakiety sieciowe :)). Jeśli system docelowy jest idempotentny, wynik nie będzie inny. Jeśli w docelowym systemie zależy od właściwej kolejności w sekwencji, musimy w docelowym miejscu zaimplementować resekwenser, który przywróci właściwą kolejność. 2. Co by się stało, gdyby wiadomości się zduplikowały? Jeśli kanał systemu docelowego nie potwierdzi w odpowiednim czasie, system źródłowy (lub sam kanał) zwykle wysyła kolejną kopię komunikatu. W rezultacie możemy mieć zduplikowaną wiadomość po stronie systemu docelowego. Jeśli system docelowy jest idempotentny, zajmie się tym i wynik nie będzie inny. Jeśli system docelowy nie jest idempotentny, musimy zaimplementować deduplikator po stronie kanału systemu docelowego.

można bezpiecznie spróbować ponownie.

Jest to zazwyczaj najłatwiejszy sposób zrozumienia jego znaczenia w informatyce.