Sr-8-wyk-1.0-Slajd23

Z Studia Informatyczne
Wersja z dnia 13:04, 28 sie 2006 autorstwa Bgrabiec (dyskusja | edycje)
(różn.) ← poprzednia wersja | przejdź do aktualnej wersji (różn.) | następna wersja → (różn.)
Przejdź do nawigacjiPrzejdź do wyszukiwania

Protokół koherencji

Protokół koherencji


Protokół koherencji (ang. consistency protocol ) jest algorytmem rozproszonym realizującym określony model spójności, a więc dostarczającym użytkownikom gwarancji odnośnie uporządkowania operacji modyfikujących, które są zgłaszane w systemie. Operacje odczytu nie powodują powstawania problemu spójności danych. Operacje zapisu modyfikują pojedynczą kopię i muszą być przesłane do pozostałych węzłów. Generalnie istnieją dwa podstawowe podejścia do zapewniania spójności: unieważnianie i aktualizacja.

Unieważnianie (ang. invalidation ) polega na zmianie statusu zdalnych kopii danych tak, aby nie mogły już być wykorzystywane, co efektywnie może być traktowane jako usunięcie repliki. Komunikaty unieważniające są małe ponieważ muszą zawierać jedynie identyfikator strony, która ma ulec unieważnieniu. Zaletą unieważniania jest brak konieczności dalszej komunikacji z serwerem w przypadku wprowadzania następnych modyfikacji – kopia przestała bowiem już istnieć. Unika się w ten sposób również przesyłania aktualizacji, które być może nigdy nie zostałyby wykorzystane (odczytane) przez innych użytkowników, co powodowałoby jedynie zwiększenie obciążenia komunikacyjnego w systemie. Wadą natomiast jest konieczność wysłania następnego komunikatu z aktualną kopią danych, jeżeli dane te faktycznie są jednak potrzebne.

Drugim podejściem stosowanym w protokołach koherencji jest aktualizacja (ang. update protocol ). Polega ona na każdorazowym przesyłaniu komunikatu aktualizującego stan repliki. Komunikat taki może zawierać całość zaktualizowanego stanu obiektu lub jedynie zmianę względem poprzedniej wersji. W podejściu tym przesyłane komunikaty są większe, bo muszą zawierać również aktualizowane dane. Komunikaty muszą również być wysyłane praktycznie po każdej aktualizacji, chyba, że z własności modelu wynika, że dane te nie będą wykorzystywane, co pozwala na zgrupowanie kilku aktualizacji w jednym komunikacie (grupowanie takie może też dotyczyć kilku aktualizacji różnych obiektów). Zaletą tego rozwiązania jest natychmiastowa dostępność zaktualizowanych replik w poszczególnych węzłach. Może się jednak zdarzyć, że aktualizacje te nie będą w ogóle odczytywane.


<< Poprzedni slajd | Spis treści | Następny slajd >>