Implementowanie zasad ponawiania za pomocą języka JavaScript lub TypeScript
Każda aplikacja, która działa w chmurze lub komunikuje się z usługami zdalnymi i zasobami, musi mieć możliwość obsługi błędów przejściowych. Te aplikacje często występują błędy z powodu chwilowej utraty łączności sieciowej, przekroczenia limitu czasu żądania, gdy usługa lub zasób jest zajęta lub inne czynniki. Deweloperzy powinni tworzyć aplikacje do obsługi błędów przejściowych w sposób niewidoczny, aby poprawić stabilność i odporność.
Z tego artykułu dowiesz się, jak używać biblioteki klienta usługi Azure Storage dla języka JavaScript do konfigurowania zasad ponawiania dla aplikacji łączącej się z usługą Azure Blob Storage. Zasady ponawiania prób definiują sposób obsługi żądań niepowodzeń przez aplikację i powinny być zawsze dostosowane do wymagań biznesowych aplikacji i charakteru awarii.
Konfigurowanie opcji ponawiania prób
Zasady ponawiania prób dla usługi Blob Storage są konfigurowane programowo, co zapewnia kontrolę nad sposobem stosowania opcji ponawiania prób do różnych żądań obsługi i scenariuszy. Na przykład aplikacja internetowa wydająca żądania na podstawie interakcji użytkownika może implementować zasady z mniejszą liczbą ponownych prób i krótszymi opóźnieniami w celu zwiększenia czasu reakcji i powiadamiania użytkownika o wystąpieniu błędu. Alternatywnie aplikacja lub składnik uruchamiając żądania wsadowe w tle może zwiększyć liczbę ponownych prób i użyć strategii wycofywania wykładniczego, aby umożliwić pomyślne zakończenie żądania.
W poniższej tabeli wymieniono parametry dostępne podczas tworzenia wystąpienia StorageRetryOptions wraz z typem, krótkim opisem i wartością domyślną, jeśli nie wprowadzisz żadnych zmian. Należy aktywnie dostrajać wartości tych właściwości, aby spełniały potrzeby aplikacji.
| Właściwość | Type | Opis | Domyślna wartość |
|---|---|---|---|
maxRetryDelayInMs |
number |
Opcjonalny. Określa maksymalne opóźnienie dozwolone przed ponowieniu próby wykonania operacji. | 120 sekund (lub 120 * 1000 ms) |
maxTries |
number |
Opcjonalny. Maksymalna liczba ponownych prób przed rezygnacją. | 100 |
retryDelayInMs |
number |
Opcjonalny. Określa ilość opóźnienia do użycia przed ponowną próbą wykonania operacji. | 4 sekundy (lub 4 * 1000 ms) |
retryPolicyType |
StorageRetryPolicyType | Opcjonalny. StorageRetryPolicyType, wartość domyślna to zasady ponawiania wykładniczego. | StorageRetryPolicyType.Exponential |
secondaryHost |
string |
Opcjonalny. Pomocniczy punkt końcowy konta magazynu w celu ponawiania żądań. Przed ustawieniem tej wartości należy zrozumieć problemy związane z odczytywaniem nieaktualnych i potencjalnie niespójnych danych. Aby dowiedzieć się więcej, zobacz Projektowanie aplikacji o wysokiej dostępności przy użyciu nadmiarowości geograficznej. | Brak |
tryTimeoutInMs |
number |
Opcjonalny. Maksymalny czas dozwolony przed anulowaniem żądania i założeniem, że nie powiodło się. Ten limit czasu dotyczy żądania operacji i powinien być oparty na przepustowości dostępnej dla maszyny hosta i sąsiedztwie usługi Storage. | Wartość 0 lub niezdefiniowana powoduje brak domyślnego limitu czasu na kliencie, a domyślny limit czasu po stronie serwera jest używany. Aby dowiedzieć się więcej, zobacz Limity czasu dla operacji usługi Blob Service. |
W poniższym przykładzie kodu skonfigurujemy opcje ponawiania w wystąpieniu usługi StorageRetryOptions, przekażemy je do nowego wystąpienia storagePipelineOptions i przekażemy pipeline podczas tworzenia wystąpienia BlobServiceClient:
const options = {
retryOptions: {
maxTries: 4,
retryDelayInMs: 3 * 1000,
maxRetryDelayInMs: 120 * 1000,
retryPolicyType: StorageRetryPolicyType.EXPONENTIAL
},
};
const pipeline = newPipeline(credential, options);
const blobServiceClient = new BlobServiceClient(
`https://${accountName}.blob.core.windows.net`,
credential,
pipeline
);
W tym przykładzie BlobServiceClient każde żądanie obsługi wystawione z obiektu używa opcji ponawiania zgodnie z definicją w pliku retryOptions. Te zasady dotyczą żądań klientów. Można skonfigurować różne strategie ponawiania prób dla klientów usług na podstawie potrzeb aplikacji.