Udostępnij za pośrednictwem

Tryby łączności zestawu SQL SDK usługi Azure Cosmos DB

  • Artykuł

DOTYCZY: NoSQL

Sposób nawiązywania połączenia klienta z usługą Azure Cosmos DB ma ważne konsekwencje dla wydajności, szczególnie w przypadku zaobserwowanego opóźnienia po stronie klienta. Usługa Azure Cosmos DB oferuje prosty, otwarty model programowania RESTful za pośrednictwem protokołu HTTPS nazywanego trybem bramy. Ponadto oferuje wydajny protokół TCP, który jest również RESTful w modelu komunikacji i używa protokołu TLS do początkowego uwierzytelniania i szyfrowania ruchu, nazywanego trybem bezpośrednim.

Dostępne tryby łączności

Dwa dostępne tryby łączności to:

  • Tryb bramy

    Tryb bramy jest obsługiwany na wszystkich platformach ZESTAWU SDK. Jeśli aplikacja działa w sieci firmowej z rygorystycznymi ograniczeniami zapory, tryb bramy jest najlepszym wyborem, ponieważ używa standardowego portu HTTPS i pojedynczego punktu końcowego DNS. Kompromis wydajności polega jednak na tym, że tryb bramy obejmuje dodatkowy przeskok sieciowy za każdym razem, gdy dane są odczytywane lub zapisywane w usłudze Azure Cosmos DB. Zalecamy również tryb połączenia bramy podczas uruchamiania aplikacji w środowiskach z ograniczoną liczbą połączeń gniazd.

    Jeśli używasz zestawu SDK w usłudze Azure Functions, szczególnie w planie Zużycie, należy pamiętać o bieżących limitach połączeń.

  • Tryb bezpośredni

    Tryb bezpośredni obsługuje łączność za pośrednictwem protokołu TCP, przy użyciu protokołu TLS na potrzeby uwierzytelniania początkowego i szyfrowania ruchu oraz zapewnia lepszą wydajność, ponieważ istnieje mniej przeskoków sieciowych. Aplikacja łączy się bezpośrednio z replikami zaplecza. Tryb bezpośredni jest obecnie obsługiwany tylko na platformach .NET i Java SDK.

Tryby łączności usługi Azure Cosmos DB

Te tryby łączności zasadniczo warunkują trasę żądaną przez płaszczyznę danych — odczyty i zapisy dokumentu — pobierz z maszyny klienckiej do partycji w zapleczu usługi Azure Cosmos DB. Tryb bezpośredni jest preferowaną opcją dla najlepszej wydajności — umożliwia klientowi otwieranie połączeń TCP bezpośrednio z partycjami w zapleczu usługi Azure Cosmos DB i wysyłanie żądań bezpośredniobez pośrednika. Natomiast w trybie bramy żądania wysyłane przez klienta są kierowane do tak zwanego serwera "Brama" w frontonie usługi Azure Cosmos DB, który z kolei wysyła żądania do odpowiednich partycji w zapleczu usługi Azure Cosmos DB.

Zakresy portów usługi

W przypadku korzystania z trybu bezpośredniego należy upewnić się, że klient może uzyskiwać dostęp do portów z zakresu od 10000 do 20000, ponieważ usługa Azure Cosmos DB używa dynamicznych portów TCP. Jest to dodatek do portów bramy. W przypadku korzystania z trybu bezpośredniego w prywatnych punktach końcowych pełny zakres portów TCP — od 0 do 65535 może być używany przez usługę Azure Cosmos DB. Jeśli te porty nie są otwarte na kliencie i spróbujesz użyć protokołu TCP, może zostać wyświetlony błąd 503 Usługa niedostępna.

W poniższej tabeli przedstawiono podsumowanie trybów łączności dostępnych dla różnych interfejsów API i portów usługi używanych dla każdego interfejsu API:

Tryb połączenia Obsługiwany protokół Obsługiwane zestawy SDK Port interfejsu API/usługi
Brama HTTPS Wszystkie zestawy SDK SQL (443), MongoDB (10255), Table (443), Cassandra (10350), Graph (443)
Direct TCP (zaszyfrowane za pośrednictwem protokołu TLS) Zestaw JAVA SDK platformy .NET W przypadku korzystania z publicznych punktów końcowych/punktów końcowych usług: porty z zakresu od 10000 do 20000
W przypadku korzystania z prywatnych punktów końcowych: porty z zakresu od 0 do 65535

Architektura połączenia w trybie bezpośrednim

Zgodnie z opisem we wprowadzeniu klienci trybu bezpośredniego będą łączyć się bezpośrednio z węzłami zaplecza za pośrednictwem protokołu TCP. Każdy węzeł zaplecza reprezentuje replikę w zestawie replik należącym do partycji fizycznej.

Routing

Gdy zestaw SDK usługi Azure Cosmos DB w trybie bezpośrednim wykonuje operację, musi rozpoznać replikę zaplecza, z którą ma nawiązać połączenie. Pierwszym krokiem jest poznanie, do której partycji fizycznej powinna przejść operacja, a w tym celu zestaw SDK uzyskuje informacje o kontenerze zawierające definicję klucza partycji z węzła bramy. Potrzebuje również informacji o routingu, które zawierają adresy TCP replik. Informacje o routingu są dostępne również z węzłów bramy, a oba są uznawane za metadane płaszczyzny sterowania. Po uzyskaniu informacji o routingu zestaw SDK może otworzyć połączenia TCP z replikami należącymi do docelowej partycji fizycznej i wykonać operacje.

Każdy zestaw replik zawiera jedną replikę podstawową i trzy sekundy. Operacje zapisu są zawsze kierowane do węzłów repliki podstawowej, podczas gdy operacje odczytu mogą być obsługiwane z węzłów podstawowych lub pomocniczych.

Diagram przedstawiający sposób pobierania kontenera i informacji o routingu z bramy w trybie S D Ks w trybie bezpośrednim przed otwarciem połączeń T C P z węzłami zaplecza

Ponieważ informacje o kontenerze i routingu nie zmieniają się często, są buforowane lokalnie w zestawach SDK, dzięki czemu kolejne operacje mogą korzystać z tych informacji. Nawiązane już połączenia TCP są również ponownie używane w operacjach. O ile nie skonfigurowano inaczej za pomocą opcji zestawów SDK, połączenia są trwale utrzymywane w okresie istnienia wystąpienia zestawu SDK.

Podobnie jak w przypadku każdej architektury rozproszonej, maszyny przechowujące repliki mogą przechodzić uaktualnienia lub konserwację. Usługa zapewni, że zestaw replik zachowuje spójność, ale każdy ruch repliki spowoduje zmianę istniejących adresów TCP. W takich przypadkach zestawy SDK muszą odświeżyć informacje o routingu i ponownie nawiązać połączenie z nowymi adresami za pośrednictwem nowych żądań bramy. Te zdarzenia nie powinny mieć wpływu na ogólną umowę SLA P99.

Liczba połączeń

Każda partycja fizyczna ma zestaw replik czterech replik, aby zapewnić najlepszą możliwą wydajność, zestawy SDK będą otwierać połączenia ze wszystkimi replikami dla obciążeń, które mieszają operacje zapisu i odczytu. Operacje współbieżne są równoważone w istniejących połączeniach, aby korzystać z przepływności zapewnianej przez każdą replikę.

Istnieją dwa czynniki, które określają liczbę połączeń TCP, które zostaną otwarte przez zestaw SDK:

  • Liczba partycji fizycznych

    W stanie stabilnym zestaw SDK będzie miał jedno połączenie na replikę na partycję fizyczną. Większa liczba partycji fizycznych w kontenerze, tym większa będzie liczba otwartych połączeń. Ponieważ operacje są kierowane między różnymi partycjami, połączenia są ustanawiane na żądanie. Średnia liczba połączeń byłaby wtedy liczbą partycji fizycznych razy cztery.

  • Liczba współbieżnych żądań

    Każde ustanowione połączenie może obsługiwać konfigurowalną liczbę operacji współbieżnych. Jeśli wolumin operacji współbieżnych przekroczy ten próg, nowe połączenia będą otwarte, aby je obsłużyć, i możliwe, że w przypadku partycji fizycznej liczba otwartych połączeń przekracza liczbę stałych stanów. To zachowanie jest oczekiwane w przypadku obciążeń, które mogą mieć skoki w ich woluminie operacyjnym. Dla zestawu .NET SDK ta konfiguracja jest ustawiana przez element CosmosClientOptions.MaxRequestsPerTcpConnection, a dla zestawu SDK języka Java można dostosować przy użyciu polecenia DirectConnectionConfig.setMaxRequestsPerConnection.

Domyślnie połączenia są trwale utrzymywane w celu zwiększenia wydajności przyszłych operacji (otwarcie połączenia ma obciążenie obliczeniowe). Może istnieć kilka scenariuszy, w których można chcieć zamknąć połączenia, które nie są używane przez pewien czas, rozumiejąc, że może to mieć wpływ na przyszłe operacje nieznacznie. Dla zestawu .NET SDK ta konfiguracja jest ustawiana przez element CosmosClientOptions.IdleTcpConnectionTimeout, a dla zestawu SDK języka Java można dostosować przy użyciu polecenia DirectConnectionConfig.setIdleConnectionTimeout. Nie zaleca się ustawiania tych konfiguracji na niskie wartości, ponieważ może to powodować częste zamykanie połączeń i wpływanie na ogólną wydajność.

Szczegóły implementacji specyficzne dla języka

Aby uzyskać więcej szczegółów implementacji dotyczących języka, zobacz:

Następne kroki

W przypadku określonych optymalizacji wydajności platformy SDK: