WebSockets og sanntidssystemer med Spring · leksjon

Nye forsøk og reserveløsninger

Utform og implementer strategier for automatisk ny tilkobling og reserveløsninger for å gjøre applikasjonen mer pålitelig.

Leksjon 3 av 411 trinn

Nye forsøk og reserveløsninger er en gratis leksjon i WebSockets og sanntidssystemer med Spring på CoddyKit. Dette er leksjon 3 av 4. Du kan lese hele leksjonen gratis nedenfor – og deretter øve praktisk i nettleseren med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Den er en del av læringsløpet i WebSockets og sanntidssystemer med Spring, og fremdriften din synkroniseres mellom nettet og CoddyKit-appen. Kurset i WebSockets og sanntidssystemer med Spring inneholder totalt 4 leksjoner.

Hvorfor nye forsøk og reserve løsninger?

I sanntidssystemer er pålitelig kommunikasjon avgjørende. Nettverksforstyrrelser, omstarter av serveren eller midlertidig overbelastning kan føre til at WebSocket-forbindelsen brytes.

I denne leksjonen ser vi på hvordan De kan gjøre applikasjonene motstandsdyktige. Vi går gjennom strategier for automatisk tilkobling på nytt (nye forsøk) og alternative kommunikasjonsmetoder (reserveløsninger) for å sikre en god brukeropplevelse selv når noe går galt.

Ny tilkobling på klientsiden

Når en WebSocket-tilkobling lukkes uventet, bør klienten ikke bare gi opp. Det er avgjørende å implementere automatisk tilkobling på nytt på klientsiden for å opprettholde sanntidsinteraksjoner.

Klienten oppdager frakoblingen.
Den venter en kort stund.
Den forsøker å opprette WebSocket-tilkoblingen på nytt.
Prosessen gjentas til den lykkes, eller til maksimalt antall forsøk er nådd.

Grunnleggende forsøk på ny tilkobling

Her er et enkelt Java-eksempel som simulerer tilkoblingsforsøk med en fast forsinkelse. Legg merke til hvordan det venter før hvert nytt forsøk.

Prøv å kjøre det for å se prosessen for nye forsøk:

public class ReconnectDemo {
  public static void main(String[] args) {
    int maxAttempts = 3;
    long delayMs = 1000; // 1 second

    for (int i = 1; i <= maxAttempts; i++) {
      System.out.println("Attempt " + i + ": Trying to connect...");
      try {
        // Simulate connection attempt
        boolean connected = (i == 3); // Succeed on 3rd attempt
        if (connected) {
          System.out.println("Connection successful!");
          break;
        }
        System.out.println("Connection failed. Retrying in " + delayMs + "ms...");
        Thread.sleep(delayMs);
      } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
        System.err.println("Reconnect interrupted.");
        break;
      }
    }
  }
}

Smarte nye forsøk: Eksponentiell tilbakeventing

Gjentatte forsøk på å koble til på nytt med en fast forsinkelse kan overbelaste en server som er i ferd med å komme seg. Eksponentiell tilbakeventing er en smartere strategi:

Start med en kort forsinkelse.
Fordoble forsinkelsen etter hvert mislykkede forsøk.
Begrens forsinkelsen til en maksimumsverdi for å unngå unødvendig lange ventetider.

Dette gir serveren mer tid til å hente seg inn og reduserer nettverkstrafikken under driftsavbrudd.

Eksponentiell tilbakeventing i praksis

La oss forbedre logikken for nye forsøk med eksponentiell tilbakeventing. Se hvordan forsinkelsen øker etter hvert mislykkede forsøk, opp til en maksimumsverdi.

Kjør denne koden for å se hvordan forsinkelsene øker:

public class ExponentialBackoffDemo {
  public static void main(String[] args) {
    int maxAttempts = 5;
    long initialDelayMs = 500; // 0.5 seconds
    long currentDelayMs = initialDelayMs;
    long maxDelayMs = 8000; // 8 seconds

    for (int i = 1; i <= maxAttempts; i++) {
      System.out.println("Attempt " + i + ": Trying to connect after " + currentDelayMs + "ms...");
      try {
        // Simulate connection attempt
        boolean connected = (i == 4); // Succeed on 4th attempt
        if (connected) {
          System.out.println("Connection successful!");
          break;
        }
        Thread.sleep(currentDelayMs);
        currentDelayMs = Math.min(maxDelayMs, currentDelayMs * 2); // Double the delay
      } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
        System.err.println("Reconnect interrupted.");
        break;
      }
    }
  }
}

Legge til jitter i tilbakeventingen

Selv med eksponentiell tilbakeventing kan mange klienter som kobler fra og forsøker å koble til igjen ved nøyaktig de samme doble intervallene, fortsatt skape et «stampede»-problem.

Jitter legger til en liten, tilfeldig tidsmengde i hver forsinkelse. Dette sprer forsøkene på å koble til igjen, hindrer samtidige topper av forespørsler og reduserer belastningen på serveren ytterligere mens den gjenopprettes.

Når WebSockets ikke fungerer: Reserveløsninger

Noen ganger er WebSockets ikke bare midlertidig utilgjengelige; de kan være fullstendig utilgjengelige på grunn av nettverksbegrensninger (for eksempel bedriftsbrannmurer eller gamle proxyservere) eller feilkonfigurering av serveren.

I slike tilfeller gir en reserveløsning en alternativ kommunikasjonskanal. Vanlige reserveløsninger omfatter:

Long Polling: Klienten sender gjentatte HTTP-forespørsler, mens serveren holder tilkoblingen åpen til nye data er tilgjengelige eller tidsavbruddet inntreffer.
Server-Sent Events (SSE): Serveren sender data over én langvarig HTTP-tilkobling.

Implementere reserveløsning på klientsiden

En robust klient forsøker først å opprette en WebSocket-tilkobling. Hvis dette mislykkes gjentatte ganger etter et bestemt antall nye forsøk (og tilbakeventing), kan den bytte til en reserveløsning.

Logikken ser vanligvis slik ut:

Prøv WebSocket-tilkobling.
Hvis WebSocket mislykkes etter N forsøk, prøv Long Polling.
Hvis Long Polling også mislykkes, bør du vurdere å vise en «frakoblet»-melding eller tilby en redusert brukeropplevelse.

Biblioteker som SockJS håndterer disse reserveløsningene automatisk, noe som forenkler klientutviklingen.

Serverstøtte for reserveløsninger

For at reserveløsninger skal fungere, må serveren også støtte de alternative kommunikasjonsprotokollene. En Spring-applikasjon som er konfigurert for WebSockets, tilbyr for eksempel ofte også HTTP-endepunkter for Long Polling eller SSE.

Støtte for Spring STOMP over WebSocket (ved hjelp av WebSocketMessageBrokerConfigurer) kan automatisk tilby HTTP-baserte reserveløsninger (som SockJS) hvis den konfigureres riktig, slik at mye av denne kompleksiteten skjules.

Kontroll av pålitelighetsstrategi

Se for deg et scenario der hundrevis av klienter kobles fra samtidig fra en WebSocket-server på grunn av et kortvarig nettverksavbrudd. Serveren gjenopprettes raskt.

Hvilken av de følgende strategiene vil, når de kombineres, best hjelpe disse klientene med å koble til igjen uten å overbelaste serveren som er i ferd med å gjenopprettes, samtidig som tjenesten opprettholdes?

Besvar den i den interaktive leksjonen

Oppsummering: Robuste WebSockets

Gratulerer! De har lært hvordan De kan bygge mer pålitelige sanntidsapplikasjoner.

Vi har gått gjennom:

Betydningen av automatisk tilkobling på nytt for klienter.
Implementering av eksponentiell tilbakeventing for å håndtere forsinkelser mellom nye forsøk på en kontrollert måte.
Tillegging av jitter for å hindre samtidige stormer av nye tilkoblingsforsøk.
Bruk av reserveløsninger som Long Polling eller SSE når WebSockets ikke er et alternativ.

Disse teknikkene er avgjørende for å skape robuste og brukervennlige sanntidssystemer.

Gratis å komme i gang

Lær deg WebSockets og sanntidssystemer med Spring med en AI-veileder – gratis

Skriv og kjør ekte kode i nettleseren, få umiddelbar hjelp fra en AI-veileder som er tilgjengelig døgnet rundt, og fortsett der du slapp – på nettet eller i appen.

Kurs: 12
Leksjoner: 48

Start læringen gratis Se hele kurset

Ofte stilte spørsmål

Er leksjonen «Nye forsøk og reserveløsninger» gratis?

Ja – hele teksten i «Nye forsøk og reserveløsninger» er gratis å lese her på nettet. For å øve interaktivt med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt, og for å låse opp resten av WebSockets og sanntidssystemer med Spring-kurset, kan du oppgradere til CoddyKit PRO. Kurset i WebSockets og sanntidssystemer med Spring inneholder totalt 4 leksjoner.

Hva lærer jeg i «Nye forsøk og reserveløsninger»?

Utform og implementer strategier for automatisk ny tilkobling og reserveløsninger for å gjøre applikasjonen mer pålitelig. Du øver på WebSockets og sanntidssystemer med Spring med praktisk kode som du kjører direkte i nettleseren, mens en AI-veileder som er tilgjengelig døgnet rundt, svarer på spørsmålene dine mens du jobber deg gjennom leksjonen.

Trenger jeg erfaring for å begynne med WebSockets og sanntidssystemer med Spring?

Ingen tidligere erfaring er nødvendig. WebSockets og sanntidssystemer med Spring på CoddyKit er lagt opp for både nybegynnere og viderekomne, så De kan begynne her eller helt fra start og lære i Deres eget tempo. Dette er leksjon 3 av 4.

Hvor lang tid tar leksjonen «Nye forsøk og reserveløsninger»?

De fleste CoddyKit-leksjoner tar omtrent 5–10 minutter. Hver leksjon er kort og interaktiv, slik at De gjør jevne fremskritt og kan fortsette akkurat der De slapp – både på nettet og i appen.

Kan jeg skrive og kjøre kode i denne WebSockets og sanntidssystemer med Spring-leksjonen?

Ja. Alle WebSockets og sanntidssystemer med Spring-leksjoner har en innebygd kodeeditor, slik at De kan skrive og kjøre ekte kode direkte i nettleseren og få umiddelbar tilbakemelding fra AI – uten lokal konfigurering.

Alle leksjonene i dette kurset

← Tilbake til WebSockets og sanntidssystemer med Spring