Buforowanie po stronie klienta Redis
Buforowanie po stronie klienta umożliwia przechowywanie często dostępnych danych na końcu przeglądarki lub w pamięci serwera aplikacji. Do pewnego stopnia zużywa pamięć po stronie klienta, ale wzrost wydajności jest wysoki. Zwykle, gdy dane są wymagane, klient wysyła żądanie do zaplecza, aby zapytać o dane. Przez większość czasu klienci internetowi odzyskują ten sam zestaw danych w kółko z bazy danych. Po włączeniu buforowania po stronie klienta dane pobierane za pomocą popularnych zapytań są przechowywane po stronie klienta.
Buforowanie po stronie klienta ma dwie główne korzyści:
- Poprawia wydajność o znaczną kwotę.
- Zmniejsza bazę danych i obciążenia sieciowe.
Jednocześnie buforowanie po stronie klienta stoi przed wyzwaniem związanym z utrzymaniem aktualnych danych. Jeśli dane zostaną zmienione w końcu bazy danych, ten element danych w pamięci podręcznej klienta staje się przestarzały, a klient powinien zostać natychmiast powiadomiony o pobraniu zaktualizowanego utworu. Redis wdrożył swój model buforowania, rozwiązując te problemy.
Skonfiguruj buforowanie po stronie klienta z Redis
W Redis nazwano buforowanie po stronie klienta śledzenie. Istnieją dwa tryby śledzenia obsługiwanych przez Redis. Tryb domyślny nazywa się śledzeniem wspomaganego serwera, w którym serwer wysyła powiadomienia o nieprawidłowości, które są powiązane tylko z klawiszami, które są w pamięci podręcznej klienta. Z drugiej strony tryb nadawania daje klientom swobodę subskrypcji preferowanych klucz.
Świadczenie wspomagane serwerami dla klientów Redis
Jak sama nazwa wskazuje, w trybie wspomaganym serwerem serwer śledzi klawisze, do których dostęp do określonego klienta. Ilekroć śledzony klawisz jest zmieniany w bazie danych, klient zostanie natychmiast powiadomiony. Co najważniejsze, powiadomienia o unieważnieniu są generowane tylko dla kluczy, które są w danej pamięci podręcznej klienta. Jedyną minusem tego trybu jest to, że wykorzystuje pamięć serwera do zapamiętania dostępnych kluczy przez każdego klienta.
Dedykowany klient do powiadomień o unieważnieniu
Zwykle buforowanie po stronie klienta wspomagane serwerem jest zaimplementowane przy użyciu dedykowanego klienta, który otrzymuje powiadomienia o nieprawidłowości. Ten klient jest centralnym punktem, który odbiera wszystkie komunikaty o unieważnieniu dla wszystkich klientów podłączonych do danej bazy danych.
Skonfigurujmy dedykowanego klienta do otrzymywania wiadomości o unieważnieniu. Najpierw musimy połączyć się z naszym serwerem Redis jako autoryzowany klient i uzyskać identyfikator klienta w następujący sposób.
Identyfikator klienta
Powyższe polecenie zwraca identyfikator bieżącego połączenia klienta, czyli 3. Ten identyfikator jest potrzebny w następnych krokach, aby zidentyfikować go jako centralny klient, aby otrzymać komunikaty unieważnione. Następnie subskrybujemy kanał powiadomienia o unieważnieniu w następujący sposób. Można użyć polecenia subskrypcji.
Subskrybuj kanał [kanał…]
W tym przykładzie kanał to __REDIS __: unieważnienie.
Subskrybuj __REDIS __: unieważnienie
Teraz skonfigurowaliśmy połączenie klienta, aby otrzymać powiadomienia o unieważnieniu. Zainicjujmy kolejne połączenie klienta i włączmy śledzenie klienta. Ponadto przekierowujemy wszystkie komunikaty o unieważnieniu powiązane z nowym klientem do klienta centralnego utworzonego we wcześniejszym kroku. Możemy użyć polecenia śledzenia klienta, aby to osiągnąć. Poniżej znajduje się składnia polecenia śledzenia klienta.
Śledzenie klientów[Przekierowanie klienta-ID] [prefiks prefiks [prefiks przedrostek…]] [Bcast] [Optin] [Optout] [NOLOOP]
Na | WYŁĄCZONY : Ustal, czy śledzenie klientów powinno być włączone, czy nie.
Przekier: Określ identyfikator klienta, który otrzymuje komunikaty o nieprawidłowaniu.
Włączmy śledzenie klienta dla nowego autoryzowanego klienta i użyj opcji przekierowania, aby określić połączenie, które odbiera unieważnienie, wiadomości o 3.
Śledzenie klienta na przekierowaniu 3
Teraz jesteśmy gotowi przetestować nasze śledzenie klienta Redis. Najpierw ustawiamy parę wartości kluczowej w następujący sposób.
Ustaw nazwę użytkownika „user_01”
Następnie uzyskujemy dostęp do nazwy użytkownika od tego samego klienta, który będzie buforować tę informację po stronie klienta, ponieważ włączyliśmy śledzenie klienta.
Zdobądź nazwę użytkownika
Otwórzmy nowego klienta i zmieńmy wartość przechowywaną w kluczu nazwa użytkownika następująco.
Ustaw nazwę użytkownika „user_2”
Natychmiast klient, który zasubskrybował kanał Invalidate, zostaje powiadomiony, że wartość przechowywana w kluczu nazwa użytkownika został zmodyfikowany i jest już nieprawidłowy.
Ten model opiera się na protokole resp2, który jest domyślnym protokołem korzystającym klientów Redis.
Protokół resp3 do otrzymywania powiadomień do klienta śledzącego
Z wersji 6.0, Redis wprowadza protokół resp3, który umożliwia aktywnemu klientowi otrzymywanie komunikatów unieważnienia. Jest to ogromna zaleta, w której klient Redis może słuchać danego kanału podczas wydawania poleceń.
Najpierw sprawdźmy wersję Redis. To musi być wersja 6.0 lub najnowszy, który użyje protokołu resp3. Można wydać następujące polecenie, aby sprawdzić wersję Redis.
Redis-cli --version
Ponieważ jest to wersja 7.0, wszyscy jesteśmy dobrze używać protokołu resp3. Klienci Redis domyślnie używają RESP2. Musimy więc przejść do protokołu resp3.
Witam 3
To zmieniłoby protokół na resp3 z następującymi wyjściami.
Włączmy śledzenie klienta, jak we wcześniejszym przykładzie, używając polecenia śledzenia klienta. W takim przypadku nie musimy określać opcji przekierowania.
Śledzenie klienta dalej
Teraz klucze, które przynosi ten klient, będą śledzone przez serwer. Ponadto, gdy zmienia się wartość śledzenia klucza, zostanie wysłany komunikat o unieważnieniu do klientów, którzy buforowali ten konkretny klucz.
Przyjmijmy klucz nazwa użytkownika.
Zdobądź nazwę użytkownika
Klient buforuje nazwa użytkownika Klucz i powiązana wartość. Teraz inicjujemy inne połączenie klienta i zmieniamy wartość przechowywaną w kluczu nazwa użytkownika.
Jeśli sprawdzisz poprzednie połączenie klienta, nie otrzymano jeszcze wiadomości o unieważnieniu. Jeśli wydasz inne polecenie, powiadomienie o unieważnieniu zostanie wyświetlone natychmiast w następujący sposób.
2. Tryb nadawania do śledzenia klientów
W trybie domyślnym klienci otrzymują powiadomienia o unieważnieniu tylko dla kluczy, które pobrali we wcześniejszych połączeniach poleceń. Przy włączonym trybie transmisji klienci subskrybują konkretny prefiks klucza, a klient otrzymuje powiadomienia o unieważnieniu dla każdego klucza, który się zmienia, którego klucz zaczyna się od subskrybowanego przedrostka.
Użyjmy nowego połączenia klienta, aby odbierać komunikaty o unieważnieniu, subskrybując kanał Invalidate w następujący sposób.
W tym przykładzie identyfikator połączenia klienta to 10, który będzie używany z opcją przekierowania dla nowego klienta. Podajmy opcję BCD w poleceniu śledzenia klienta w następujący sposób.
Śledzenie klientów na prefiksie BCDUS Użytkownik: przekierowanie 10
Załóżmy, że mamy klucz o nazwie User: Id: 1 w instancji Redis. Zdobądźmy to od tego klienta.
Teraz użytkownik: Id: 1 Klucz jest buforowany po stronie klienta.
Utwórzmy nowe połączenie klienta i ustaw nowy klucz w następujący sposób: Użytkownik: Id: 3.
W tej chwili klient, który włączył śledzenie, otrzymuje komunikat unieważniony, a zostanie przekierowany do klienta, który zostanie zidentyfikowany przez identyfikator 10. Dzieje się tak, ponieważ nowy klucz zawiera prefiks użytkownik: który jest subskrybowanym prefiksem przez klienta włączonego śledzenia. Jak widać, serwer nie śledzi żadnego z kluczy, które każdy klient pobiera, ale transmituje komunikaty o nieprawid.
Opcje Optin and Optout
Opcje optin i optout mogą być używane do odfiltrowania, jakie klawisze serwer powinien dokładnie śledzić lub nie śledzić. Z tymi opcjami włączonymi w poleceniu śledzenia klienta, Redis śledzi tylko klawisze, które są zapytaniami tuż po buforowaniu komendy klienta Tak. To minimalizuje zużycie pamięci po stronie serwera i drastycznie ładuje.
Wniosek
Podsumowując, buforowanie po stronie klienta jest jedną z szeroko stosowanych technik poprawy wydajności aplikacji internetowych, które często żądają danych z baz danych zaplecza. Jak omówiono, przeglądarka lub serwer aplikacji po stronie klienta może przechowywać dane związane z popularnymi zapytaniami wydanymi przez klienta. Jak wspomniano we wstępie, w Redis, buforowanie po stronie klienta nazywa się śledzeniem. Ponadto dwa tryby śledzenia są dostępne w Redis. Zarówno dedykowane tryby klienta, jak i transmisji mają własne przypadki użycia.