Udostępnij przez

Użyj wielu przestrzeni nazw do izolowania aplikacji przed awariami i katastrofami usługi Service Bus.

Aplikacje o znaczeniu krytycznym muszą działać w sposób ciągły, nawet w obecności nieplanowanych awarii lub awarii. Odporność na katastrofalne awarie zasobów przetwarzania danych jest wymagana dla wielu przedsiębiorstw, a w niektórych przypadkach nawet wymagana przez przepisy branżowe.

Uwaga

Odzyskiwanie geograficzne usługi Service Bus po awarii i replikacja geograficzna ułatwiają odzyskiwanie po awarii na dużą skalę lub trwałe porzucenie nieudanego regionu świadczenia usługi Azure bez konieczności wprowadzania zmian w konfiguracji aplikacji. Aby uzyskać więcej informacji na temat tych funkcji i sposobu włączania niezawodności i odporności w usłudze Azure Service Bus, zobacz Niezawodność w usłudze Azure Service Bus.

Jeśli nie możesz użyć usługi Geo-Disaster Recovery lub Geo-Replication, aby spełnić wymagania, możesz wdrożyć wiele przestrzeni nazw usługi Service Bus. W tym artykule opisano techniki, których można użyć do ochrony aplikacji przed potencjalną awarią usługi lub awarią przy użyciu wielu przestrzeni nazw.

Typy replikacji

Aby osiągnąć odporność na awarie w warstwie Standard Service Bus, można użyć replikacji aktywnej lub pasywnej. Jeśli kolejka lub temat muszą pozostać dostępne podczas awarii centrum danych, utwórz tę samą jednostkę w obu przestrzeniach nazw. Jednostki mogą mieć taką samą nazwę, ponieważ istnieją w oddzielnych przestrzeniach nazw. Na przykład możesz uzyskać dostęp do kolejki podstawowej w contosoPrimary.servicebus.windows.net/myQueue, a dostęp do jej pomocniczego odpowiednika można uzyskać w contosoSecondary.servicebus.windows.net/myQueue.

Uwaga

Aktywna replikacja i konfiguracja replikacji pasywnej są pojęciami ogólnego przeznaczenia, a nie specyficznymi funkcjami usługi Service Bus. Logika replikacji (wysyłanie do 2 różnych przestrzeni nazw) znajduje się w aplikacjach nadawcy, a odbiorca musi mieć niestandardową logikę wykrywania duplikatów.

Jeśli aplikacja nie wymaga stałej komunikacji nadawcy z odbiornikiem, aplikacja może zaimplementować trwałą kolejkę po stronie klienta, aby zapobiec utracie komunikatów i chronić nadawcę przed przejściowymi błędami usługi Service Bus.

Aktywna replikacja

Aktywna replikacja używa jednostek w obu przestrzeniach nazw dla każdej operacji. Każdy klient, który wysyła komunikat, wysyła dwie kopie tego samego komunikatu. Pierwsza kopia jest wysyłana do jednostki podstawowej (na przykład contosoPrimary.servicebus.windows.net/sales), a druga kopia komunikatu jest wysyłana do jednostki pomocniczej (na przykład contosoSecondary.servicebus.windows.net/sales).

Klient odbiera komunikaty z obu kolejek. Odbiorca przetwarza pierwszą kopię komunikatu, a druga kopia jest pomijana. Aby pominąć zduplikowane komunikaty, nadawca musi oznaczyć każdy komunikat unikatowym identyfikatorem. Obie kopie wiadomości muszą być oznaczone tym samym identyfikatorem. Możesz użyć właściwości ServiceBusMessage.MessageId lub ServiceBusMessage.Subject lub właściwości niestandardowej, aby oznaczyć komunikat. Odbiorca musi utrzymywać listę komunikatów, które już zostały odebrane.

Uwaga

Podejście aktywnej replikacji podwoi liczbę operacji, dlatego takie podejście może prowadzić do wyższych kosztów.

Replikacja pasywna

W przypadku bez błędów replikacja pasywna używa tylko jednej z dwóch jednostek obsługi komunikatów. Klient wysyła komunikat do aktywnej jednostki. Jeśli operacja w aktywnej jednostce zakończy się niepowodzeniem z kodem błędu wskazującym centrum danych hostujące aktywną jednostkę, klient wysyła kopię komunikatu do jednostki kopii zapasowej. W tym momencie aktywne i jednostki kopii zapasowej przełączają role. Klient wysyłający uważa, że stara aktywna jednostka jest nową jednostką kopii zapasowej, a stara jednostka kopii zapasowej jest nową aktywną jednostką. Jeśli obie operacje wysyłania nie powiedzą się, role dwóch jednostek pozostaną niezmienione i zostanie zwrócony błąd.

Klient odbiera komunikaty z obu kolejek. Ponieważ istnieje prawdopodobieństwo, że odbiorca otrzyma dwie kopie tego samego komunikatu, odbiorca musi pominąć zduplikowane komunikaty. Duplikaty można pominąć w taki sam sposób, jak opisano w przypadku aktywnej replikacji.

Ogólnie rzecz biorąc, replikacja pasywna jest bardziej ekonomiczna niż aktywna replikacja, ponieważ w większości przypadków jest wykonywana tylko jedna operacja. Opóźnienie, przepływność i koszt pieniężny są identyczne ze scenariuszem niereplikowanym.

W przypadku korzystania z replikacji pasywnej w następujących scenariuszach komunikaty mogą zostać utracone lub odebrane dwa razy:

  • Opóźnienie lub utrata komunikatów: załóżmy, że nadawca pomyślnie wysłał komunikat m1 do kolejki podstawowej, a następnie kolejka stanie się niedostępna, zanim odbiorca otrzyma m1. Nadawca wysyła kolejny komunikat m2 do kolejki pomocniczej. Jeśli kolejka podstawowa jest tymczasowo niedostępna, odbiorca otrzyma m1 po ponownym udostępnieniu kolejki. W przypadku awarii odbiornik nigdy nie może otrzymać m1.
  • Zduplikowany odbiór: załóżmy, że nadawca wysyła komunikat m do kolejki podstawowej. Usługa Service Bus pomyślnie przetwarza m, ale nie może wysłać odpowiedzi. Po przekroczeniu limitu czasu operacji wysyłania nadawca wysyła identyczną kopię m do kolejki pomocniczej. Jeśli odbiornik może odbierać pierwszą kopię m, zanim kolejka podstawowa stanie się niedostępna, odbiorca otrzymuje obie kopie m w przybliżeniu w tym samym czasie. Jeśli odbiornik nie może odebrać pierwszej kopii m, zanim kolejka podstawowa stanie się niedostępna, odbiorca początkowo odbiera tylko drugą kopię m, ale otrzymuje drugą kopię m, gdy kolejka podstawowa stanie się dostępna.

W przykładzie Zadania replikacji usługi Azure Messaging przy użyciu platformy .NET Core przedstawiono replikację komunikatów między przestrzeniami nazw.

Następne kroki

Aby dowiedzieć się więcej na temat odzyskiwania po awarii, zobacz następujące artykuły:

  • Last updated on