Dane w strumieniu są niezmienne. Nowe dane można dołączyć tylko na końcu strumienia. Strumienie Redis mogą przechowywać wpisy, które nie są tylko strunami. Każdy wpis może zawierać jedną lub wiele par wartości pola, jak w skrótach Redis. Te wpisy mają unikalny identyfikator, aby zidentyfikować je w strumieniu, podobne do numerów linii lub przesunięć bajtów używanych w pliku dziennika. Poniższa ilustracja zapewni lepsze zrozumienie, jak wygląda strumień Redis:
Polecenie XADD służy do dodawania wpisów do danego strumienia, który jest prosty. Mechanizm dostępu do danych różni się od typów strumieni w porównaniu z innymi typami. Główną zaletą strumieni jest to, że mogą one przekazywać nowo dołączone wiadomości do wielu klientów lub konsumentów. To tylko jeden sposób patrzenia na strumienie Redis. Ponadto możemy to postrzegać jako sklep z szeregami czasowymi, w którym można je iterować przez cały strumień, aby pobrać wszystkie wpisy dla danego ramy czasowej.
Redis Stream Consumer Group
Jak wspomniano, strumienie Redis pozwalają wielu konsumentom odczytać z nich dane. Ponadto rozszerza tę funkcjonalność na poziom dostępu do podzbioru wiadomości strumieniowych przez różnych konsumentów. Każdy konsument złapie różne dane do przetwarzania, podczas gdy Kafka wdraża to samo zachowanie w grupach konsumenckich. Technika grup konsumentów jest dostępna w strumieniach Redis, które umożliwiają dystrybucję danych strumienia wśród wielu konsumentów.
Możemy użyć polecenia XReadGroup do odczytu danych za pośrednictwem grupy konsumenckiej. Każda grupa konsumentów może zawierać wielu konsumentów zidentyfikowanych według unikalnej nazwy.
Polecenie Xack
Jak wspomniano wcześniej, konsumenci w grupie konsumenckiej otrzymują wiadomości ze strumienia, w których identyfikatory wiadomości są większe niż ostatni dostarczony identyfikator. Po dostarczeniu wiadomości do konsumenta, jego status zostanie ustawiony na oczekującą i przechowywaną na liście zgłoszeń grupy konsumenckiej (PEL). Jest to efekt uboczny wywoływania poleceń XReadGroup lub XClaim. To nadal spowodowałoby, że serwer zwróci oczekujące wiadomości za każdym razem, gdy wykonywał połączenie za pomocą polecenia XReadGroup, aby pobrać historię wiadomości na konsumenta. Dlatego grupy konsumenckie Redis wprowadziły proces potwierdzenia wiadomości. Polecenie XACK może powiadomić serwer, że pobierany komunikat został pomyślnie przetworzony. Usunąłby wpis dla takiej wiadomości w PEL.
Składnia
XackPolecenie Xack zwraca liczbę potwierdzonych wpisów jako odpowiedź.
Przykład: Balancer obciążenia obsługuje różnych klientów z wielu węzłów serwera
Spójrzmy na rzeczywisty scenariusz, w którym równowaga obciążenia odczytuje ze strumienia adresów IP klienta i obsługuje każdego klienta z różnych węzłów serwera. Możemy myśleć o tym jako o czytaniu grupy konsumenckiej ze strumienia Redis, w którym grupa zawiera wiele węzłów konsumenckich.
Po pierwsze, powinniśmy stworzyć grupę konsumentów, do której należy każdy węzeł serwerowy. Możemy użyć następującego polecenia XGroup, aby utworzyć grupę konsumentów dla danego strumienia:
Xgroup Utwórz ipaddressStream UkserverGroup $ mkstreamPolecenie jest oczywiste, gdzie ipaddressStream ma nową grupę konsumencką o nazwie Ukservergroup To zapewnia tylko najnowsze wiadomości dostępne w strumieniu, gdy konsument jest podłączony. Tworzy również ipaddressStream Stream, ponieważ Mkstream Parametr został określony.
Następnie powinniśmy dodać kilka adresów IP do ipaddressStream Utworzone wcześniej za pomocą następujące polecenie Redis XADD:
Xadd iPadDressStream * ip 123.456.12.1Wyjście po każdym poleceniu:
To dodałoby 5 wpisów do ipaddressStream strumień. Każdy wpis jest przypisany do unikalnego identyfikatora generowanego przez serwer, który powrócił po wywołaniu polecenia XADD.
Teraz przeczytajmy ipaddressStream za pośrednictwem Ukservergroup's Konsument zadzwonił serwer0.
XReadGroup Group UkserverGroup Server0 Count 2 Streams iPadDressStream>Wyjście
Zgodnie z oczekiwaniami, serwer0 Konsument otrzymuje dwie nowe wiadomości z ipaddressStream strumień. Te dwa adresy IP zostały dodane do listy oczekujących wpisów. Jeśli wywołamy polecenie XReadGroup z identyfikatorem 0, zwróci to oczekujące wiadomości dla serwer0 konsument.
XREADGroup Group UkserverGroup Server0 Streams iPadDressStream 0Wyjście
Oznacza to, że serwer wciąż czeka na serwer0 konsument, aby potwierdzić te dwie wiadomości. Przyjmijmy wiadomości dla serwer0 Konsument za pomocą następujące polecenie XACK.
Xack iPadDressStream UkserverGroup 1656192378464-0 1656192389344-0Tutaj potwierdzamy oba wpisy zidentyfikowane przez odpowiednie identyfikatory. Polecenie zwraca również liczbę pomyślnie przetworzonych wiadomości. W tym przypadku jest dwa.
Wyjście
Po poprzednim procesie te dwie wiadomości powinny zostać usunięte z listy oczekujących wpisów (PEL). Stąd serwer0 Konsument nie zwróci żadnych oczekujących wiadomości po wywołaniu polecenia XReadGroup za pośrednictwem grupy konsumenckiej Ukservergroup.
XREADGroup Group UkserverGroup Server0 Streams iPadDressStream 0Wyjście
Zwraca pustą tablicę, co oznacza brak oczekujących wiadomości dla tego konsumenta. Funkcja uznania wiadomości jest bardzo przydatna w tego typu scenariuszach.
Wniosek
Redis jest wyposażony w typ danych strumienia, którego podstawowa implementacja opiera się na strukturze danych dziennika. Stąd nowe wpisy są dołączane na końcu strumienia. Największą zaletą jest to, że wielu konsumentów może zapytać najnowsze wiadomości dodane do strumienia. Ponadto technika grupy konsumenckiej Redis pozwala na strumień odczytu przez grupę konsumentów, w której każdy konsument widzi tylko podzbiór komunikatów strumieniowych. Po przeczytaniu wpisu konsumenta ze strumienia taki wpis jest dodawany do listy oczekujących wpisów. Stąd konsument musi potwierdzić każdy z oczekujących wiadomości. Powiadomi serwer o usunięciu wpisu z PEL i zwolnienia pamięci. Polecenie XACK można użyć do potwierdzenia komunikatów strumieniowych Redis. Obsługuje uznanie wielu wiadomości jednocześnie.