podwójna wysyłka przez różne systemy

Podwójna wysyłka przez różne systemy to skutek braku koordynacji między narzędziami korzystającymi z tej samej bazy.

Na czym polega podwójna wysyłka przez różne systemy

Podwójna wysyłka przez różne systemy oznacza sytuację, w której dwa niezależne programy, moduły albo procesy przekazują tę samą wiadomość, dokument, formularz lub rekord do wspólnego odbiorcy. Każdy system może działać poprawnie z własnej perspektywy, ale brak wspólnego mechanizmu koordynacji powoduje, że oba uznają operację za wymagającą wykonania. W efekcie ten sam e-mail, plik, zlecenie, zgłoszenie albo komunikat trafia do odbiorcy więcej niż jeden raz.

Typowym źródłem problemu jest wspólna baza danych używana przez narzędzia, które nie przekazują sobie informacji o stanie operacji. Jeden program zapisuje rekord jako gotowy do wysyłki, a drugi odczytuje go bez wiedzy o tym, że pierwsze narzędzie już rozpoczęło albo zakończyło transmisję. Podobny skutek może wystąpić wtedy, gdy aplikacja zapisuje informację o wysłaniu dopiero po odpowiedzi z serwera, a w tym czasie drugi proces pobierze ten sam rekord. Nie jest to zatem wyłącznie błąd urządzenia sieciowego. Często jest to niespójność w przepływie danych i zarządzaniu stanem zadania.

Jak powstaje duplikat w przepływie danych

Proces wysyłki zwykle składa się z kilku etapów: odczytania danych z bazy, oznaczenia zadania jako przeznaczonego do realizacji, przygotowania treści, przekazania jej do systemu docelowego oraz zapisania wyniku. Jeżeli dwa programy wykonują te czynności niezależnie, mogą pobrać ten sam rekord przed jego zablokowaniem lub przed zmianą pola opisującego stan. W bazie pozostaje wtedy jeden logiczny obiekt, lecz występują dwa wykonania tej samej operacji.

Duplikaty mogą również wynikać z ponowienia żądania po przerwaniu połączenia. Nadawca może nie otrzymać odpowiedzi potwierdzającej, mimo że system odbiorczy przyjął dane. Jeżeli aplikacja potraktuje brak odpowiedzi jako całkowitą porażkę i wyśle komunikat ponownie, odbiorca może zarejestrować dwie identyczne operacje. Jeszcze inny wariant pojawia się po ponownym uruchomieniu programu: proces odczytuje zadania pozostawione w stanie „w toku” i wysyła je ponownie, chociaż pierwsza próba mogła już zakończyć się po stronie odbiorcy.

Znaczenie ma także sposób identyfikowania wiadomości. Sam adres odbiorcy, nazwa pliku lub treść komunikatu nie zawsze wystarczają do rozpoznania, że operacja jest kopią wcześniejszej. System powinien posługiwać się jednoznacznym identyfikatorem zdarzenia albo kluczem idempotencji, czyli wartością pozwalającą wykonać tę samą próbę ponownie bez utworzenia kolejnego skutku. Bez takiego identyfikatora odbiorca może traktować każdą transmisję jako nowe zadanie.

Rozpoznawanie przyczyny na komputerze

Analizę należy rozpocząć od ustalenia, czy duplikat powstał przed wysłaniem, podczas przekazania danych, czy dopiero po odebraniu komunikatu. Pomocne są znaczniki czasu, identyfikatory rekordów, nazwy procesów, adresy endpointów oraz numery prób transmisji zapisane w logach. Jeżeli dwa wpisy mają różne identyfikatory żądań, ale identyczne dane wejściowe i niemal taki sam czas wykonania, prawdopodobna jest równoległa obsługa jednego rekordu przez dwa procesy. Jeżeli identyfikator zdarzenia jest taki sam, lecz odbiorca utworzył dwa skutki, trzeba sprawdzić, czy po jego stronie działa deduplikacja.

Warto porównać konfigurację harmonogramów, usług uruchamianych wraz z systemem, zadań cyklicznych oraz katalogów obserwowanych przez aplikacje. Dwa programy mogą monitorować ten sam folder i reagować na pojawienie się tego samego pliku. Również jedna aplikacja uruchomiona w dwóch instancjach może pobierać wspólne dane bez blokady rekordu. W systemie Windows informacje o uruchomionych procesach i usługach można sprawdzać narzędziami systemowymi, natomiast logi aplikacji powinny zostać zestawione chronologicznie, a nie analizowane jako pojedyncze komunikaty.

Nie należy usuwać powielonych wpisów przed ustaleniem ich źródła. Kasowanie rekordów może zatrzeć zależność między próbą wysyłki a odpowiedzią odbiorcy. Bezpieczniejsza diagnostyka polega na porównaniu pełnego przebiegu: kto odczytał dane, kiedy zmienił ich status, jaki identyfikator nadał operacji, czy otrzymał potwierdzenie i czy drugi system wykonał tę samą czynność. Dopiero na tej podstawie można rozstrzygnąć, czy problem dotyczy blokady w bazie, synchronizacji procesów, ponawiania żądań, czy błędnej konfiguracji.

Ograniczanie ryzyka kolejnych powtórzeń

Podstawowym zabezpieczeniem jest jednoznaczny model stanów zadania oraz atomowa zmiana stanu podczas jego pobierania. Operacja pobrania i oznaczenia rekordu jako zajętego powinna odbywać się tak, aby drugi proces nie mógł przejąć tego samego zadania w tej samej chwili. Przydatne są blokady transakcyjne, unikalne klucze oraz warunki aktualizacji sprawdzające aktualny status rekordu. Samo dodanie pola „wysłano” nie rozwiązuje problemu, jeżeli odczyt i zapis tego pola odbywają się w dwóch niezsynchronizowanych krokach.

System wysyłający powinien zapisywać wynik operacji wraz z czasem, identyfikatorem próby i odpowiedzią odbiorcy. Ponowienie powinno być kontrolowane i ograniczone do sytuacji, w których można bezpiecznie stwierdzić, że poprzednia operacja nie wywołała skutku. Po stronie odbiorczej można stosować deduplikację na podstawie identyfikatora zdarzenia, a po stronie aplikacji warto rozdzielić kolejkę zadań od historii wykonanych operacji. Takie rozwiązanie ułatwia odtworzenie przebiegu i odróżnienie nowej wiadomości od ponowionej próby.

Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów i komputerów PC, a podczas diagnostyki może analizować działanie oprogramowania, procesów systemowych oraz podzespołów związanych z nieprawidłowym funkcjonowaniem komputera. W przypadku podwójnej wysyłki istotne jest przygotowanie przykładów powtórzonych komunikatów, przybliżonych godzin zdarzeń i dostępnych logów, ponieważ takie materiały pozwalają odtworzyć przepływ danych bez opierania diagnozy wyłącznie na pojedynczym objawie.