Komunikacja asynchroniczna

Komunikacja w strumieniu jest asynchroniczna i dwukierunkowa. Twój klient wysyła rekordy bez oczekiwania na potwierdzenie każdego z nich, a serwer wysyła potwierdzenia przez to samo połączenie, gdy rekordy stają się trwałe. To rozdzielenie pozwala pojedynczemu klientowi utrzymać wysoką przepustowość: nadal wysyła sygnały, podczas gdy potwierdzenia pojawiają się w tle.

Przesunięcia i pętla potwierdzeń

Każdemu wpisowi do strumienia, niezależnie od tego, czy jest to pojedynczy rekord, czy partia rekordów, przypisywany jest logiczny offset, który określa jego pozycję w tym strumieniu. Zamiast uznawać każde zgłoszenie osobno, serwer raportuje skumulowany postęp trwałości dzięki najwyższemu zadeklarowanemu offsetowi, jaki do tej pory uczynił trwałym. Ponieważ offsety są uporządkowane, jedno potwierdzenie obejmuje to przesłanie i wszystkie wcześniejsze.

To jest pętla potwierdzania i to ona utrzymuje połączenie szybkie i niezawodne:

1. Klient przesyła rekordy i przechowuje je w lokalnym buforze w trakcie lotu.
2. Serwer trwale zapisuje rekordy i okresowo odsyła najwyższy zatwierdzony offset.
3. Po otrzymaniu tego offsetu klient może bezpiecznie usunąć z bufora wszystkie rekordy do tego offsetu, ponieważ zostały one już trwale zapisane.

Gdy używasz Zerobus Ingest SDK, SDK uruchamia tę pętlę za ciebie. Śledzi offsety, utrzymuje bufor w trakcie i przetwarza potwierdzenia w tle, podczas gdy producent nadal wysyła sygnały. Sam nie implementujesz pętli. To, co opcjonalnie kontrolujesz, to sposób, w jaki obserwujesz trwałość:

• Wysyłaj dalej; SDK przetwarza potwierdzenia w miarę ich nadejścia.
• Blokuj na offsetzie tylko wtedy, gdy Twoja aplikacja musi poczekać, aż konkretny rekord będzie trwały. Zobacz poniżej.
• Zarejestruj wywołanie zwrotne potwierdzenia, aby asynchronicznie reagować na potwierdzenia i błędy, bez blokowania. Zobacz potwierdzenia zwrotne.

Samodzielnie zaimplementujesz pętlę śledzenia offsetu i buforowania tylko wtedy, gdy zbudujesz niestandardowego klienta, który nie korzysta z SDK.

Bufor w locie jest ograniczony konfigurowalnym limitem rekordów w locie. Przyjmowanie danych odbywa się asynchronicznie do momentu zapełnienia bufora; wówczas wywołania przyjmowania danych blokują się, dopóki nie nadejdą potwierdzenia, które zwolnią miejsce. Dostosuj limit do swojego obciążenia roboczego i pamiętaj, że buforowane rekordy zużywają pamięć po stronie klienta, gdy są w trakcie przesyłania. Dla opcji i jej domyślnych informacji zobacz repozytorium Zerobus SDK.

Jeśli połączenie zostanie przerwane, rekordy pozostające jeszcze w buforze in-flight (czyli te wykraczające poza ostatni zatwierdzony offset) nie zostały potwierdzone jako trwale zapisane, więc mogą zostać odtworzone. Zobacz wzorce odzyskiwania i ponawiania prób.

Potwierdzenie potwierdza trwałość, a nie możliwość zapytań. Zatwierdzony offset oznacza, że te rekordy są trwale zapisane i nie zostaną utracone. Zerobus Ingest materializuje trwałe rekordy do tabeli Delta jako osobny krok niedługo potem, po czym dane stają się zapytanialne w około 5 sekund. Więcej o opóźnieniach można znaleźć w artykule o opóźnieniach.

Oczekiwanie na rekord kontra maksymalizacja przepustowości

Czekasz na offset rekordu, gdy aplikacja musi wstrzymać dalsze wykonywanie, dopóki nie będzie wiadomo, że ten konkretny rekord został trwale zapisany, na przykład zanim potwierdzi wykonanie operacji systemowi nadrzędnemu. Oczekiwanie dotyczy synchronizacji na poziomie aplikacji, a nie wymogu trwałości. Rekord staje się trwały dzięki pętli potwierdzania, niezależnie od tego, czy go zablokujesz, czy nie.

Blokowanie wiąże się z kosztem przepustowości:

• Czekanie po przetworzeniu każdego rekordu sprawia, że przetwarzanie napływających danych staje się de facto synchronicznym przepływem pracy. Blokowanie każdej wiadomości przed wysłaniem kolejnej uniemożliwia klientowi osiągnięcie pełnej przepustowości Zerobus Ingest.
• Przyjmowanie danych o wysokiej przepustowości jest ciągłe i asynchroniczne. Klient nadal wysyła rekordy, podczas gdy potwierdzenia przychodzą dla grup wcześniej wysłanych rekordów, zamiast wstrzymywać się po każdym rekordzie. Czekaj na określony offset tylko w tych punktach kontrolnych, w których aplikacja rzeczywiście wymaga takiej gwarancji, albo użyj funkcji zwrotnej potwierdzenia, aby śledzić postępy bez blokowania.

Aby poznać metody pobierania, kiedy blokować na offsecie oraz jak działają calldowny potwierdzające, zobacz Blokowanie i potwierdzenie wiadomości.

Porządkowanie w strumieniu

Potwierdzenia i offsety są przypisane do poszczególnych strumieni: kolejność jest gwarantowana w obrębie jednego strumienia, a nie globalnie między strumieniami. Aby dowiedzieć się, jak działa porządkowanie w obrębie strumienia i jak projektować rozwiązania z uwzględnieniem tego mechanizmu, zobacz Gwarancje kolejności.