Håndtere nettverkspartisjoner
Utforsk strategier for kontrollert håndtering av nettverkssplittelser og -sammenslåinger i en distribuert Erlang-klynge, slik at systemintegriteten opprettholdes.
Håndtere nettverkspartisjoner er en gratis leksjon i Erlang OTP: programmering av distribuerte og feiltolerante systemer på CoddyKit. Dette er leksjon 1 av 4. Du kan lese valgfritt 3 leksjoner fra denne læringsstien gratis i sin helhet – deretter låser CoddyKit PRO opp alle leksjoner, samt praktisk øving med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Den er en del av læringsløpet i Erlang OTP: programmering av distribuerte og feiltolerante systemer, og fremdriften din synkroniseres mellom nettet og CoddyKit-appen. Kurset i Erlang OTP: programmering av distribuerte og feiltolerante systemer inneholder totalt 4 leksjoner.
Forstå nettverkspartisjoner
I distribuerte systemer oppstår en nettverkspartisjon når deler av systemet ikke lenger kan kommunisere med hverandre på grunn av nettverksfeil. Tenk på det som en bro som kollapser og deler en by i isolerte bydeler.
Dette kan føre til en «split-brain»-situasjon, der ulike deler av Erlang-klyngen tror at de er de eneste aktive delene. Dette resulterer ofte i inkonsistente data og tjenesteavbrudd.
Tilkobling mellom Erlang-noder
Erlang-noder kommuniserer ved å danne et distribuert system. De kobler seg til hverandre ved hjelp av en prosess kalt net_kernel. Når en node starter, prøver den å finne og koble seg til andre kjente noder.
- Bruk
-snamefor korte navn (lokalt nettverk). - Bruk
-namefor fullstendige navn (på tvers av nettverk). - Alle noder må dele den samme magiske informasjonskapselen av sikkerhetshensyn.
Her er en enkel modul. Kompiler den, og kjør MyNode.get_name(). i Erlang-skallet etter at De har startet med erl -sname mynode:
-module(my_node).
-export([get_name/0]).
get_name() ->
node().Overvåking av nodestatus
Erlang har innebygde mekanismer for å oppdage når en node kobler fra. Funksjonen monitor_node/2 gjør det mulig for en prosess å motta meldinger når statusen til en annen node endres (for eksempel opp eller ned).
Dette er avgjørende for å kunne reagere på uventede nodefeil eller nettverksproblemer. La oss se hvordan en prosess kan overvåke en annen node:
-module(node_monitor).
-export([start/1]).
start(OtherNode) ->
Pid = spawn(fun() -> init(OtherNode) end),
{ok, Pid}.
init(OtherNode) ->
io:format("~p monitoring ~p~n", [self(), OtherNode]),
erlang:monitor_node(OtherNode, true),
receive
{nodeup, Node} ->
io:format("Node ~p is UP~n", [Node]);
{nodedown, Node} ->
io:format("Node ~p is DOWN!~n", [Node])
end,
io:format("Monitor process ~p exiting.~n", [self()]).Mer enn enkel frakobling
Selv om monitor_node er kraftig, forteller den først og fremst om en TCP-tilkobling til en node har blitt brutt. Dette betyr ikke nødvendigvis en fullstendig «partisjon».
Korte nettverksforstyrrelser eller et tregt nettverk kan føre til midlertidige frakoblinger og dermed falske positiver. En faktisk partisjon innebærer en vedvarende manglende evne til å kommunisere mellom grupper av noder.
- Nettverksforsinkelse kan forsinke oppdagelsen.
- Korte avbrudd trenger ikke å utløse en full systemreaksjon.
- Helsesjekker på applikasjonsnivå er ofte nødvendige.
Kvorum og flertallet vinner
For å unngå «split-brain» ved en nettverkspartisjon bruker distribuerte systemer ofte kvorum. Et kvorum er det minste antallet noder som må bli enige om en operasjon (eller ganske enkelt være tilgjengelige) for at den skal regnes som gyldig.
Strategien «flertallet vinner» er en vanlig kvorumtilnærming:
- Bare partisjonen som inneholder mer enn halvparten av alle nodene, får fortsette driften.
- Andre partisjoner (mindretallet) bør stanse eller bli skrivebeskyttet.
Dette forhindrer motstridende oppdateringer og sikrer datakonsistens.
Sporing av aktive medlemmer
For å implementere «flertallet vinner» må hver node kjenne den totale klyngestørrelsen og hvilke noder som er tilgjengelige for øyeblikket. Dette danner en «medlemskapskilde».
Selv om en full implementering er kompleks, kan De simulere en enkel tilgjengelighetssjekk ved å la hver node jevnlig «pinge» de kjente motpartene sine. Hvis en node får kontakt med et flertall av motpartene, regner den seg selv som «aktiv».
Her er en konseptuell modul for en node som skal pinge andre:
-module(ping_checker).
-export([start/2, ping_peers/1]).
start(KnownPeers, Interval) ->
Pid = spawn(fun() -> init(KnownPeers, Interval) end),
{ok, Pid}.
init(KnownPeers, Interval) ->
ping_peers(KnownPeers),
timer:sleep(Interval),
init(KnownPeers, Interval).
ping_peers(Peers) ->
io:format("~p: Pinging peers: ~p~n", [node(), Peers]),
ActivePeers = lists:filter(fun(Peer) ->
case net_adm:ping(Peer) of
pong -> true;
pang -> false
end
end, Peers),
io:format("~p: Reachable peers: ~p~n", [node(), ActivePeers]),
TotalNodes = length(Peers) + 1, % Include self
ReachableCount = length(ActivePeers) + 1,
if
ReachableCount > TotalNodes / 2 ->
io:format("~p: I am in the MAJORITY partition!~n", [node()]);
true ->
io:format("~p: I am in the MINORITY partition or isolated.~n", [node()])
end.Sikring for trygghet
Når det oppstår en nettverkspartisjon og en mindretallspartisjon blir identifisert, er det avgjørende å hindre at den forårsaker skade (for eksempel ved å skrive motstridende data). Denne prosessen kalles fencing.
Fencing sikrer at bare den «vinnende» partisjonen (flertallet) kan fortsette å kjøre og endre delt tilstand. Vanlige fencing-tiltak omfatter:
- Å slå av tjenester i mindretallspartisjonen.
- Å deaktivere skriveoperasjoner.
- Å isolere ressurser (for eksempel databasetilgang).
Målet er å hindre at «split-brain» ødelegger data.
Sammenføring av avvikende tilstander
Etter at en nettverkspartisjon er løst og nodene kobler seg til hverandre igjen, kan tilstandene deres ha utviklet seg ulikt. Dette skyldes at den aktive partisjonen fortsatte driften, mens de isolerte nodene var inaktive eller utførte andre handlinger.
Datasammenføring er prosessen med å løse disse konfliktene og bringe alle nodene tilbake til en konsistent tilstand. Vanlige strategier omfatter:
- Last Write Wins (LWW): Den nyeste oppdateringen (basert på tidsstempel) velges.
- Konfliktløsningsfunksjoner: Applikasjonsspesifikk logikk for å slå sammen data.
Det er avgjørende å utforme systemet med tanke på eventual consistency.
Kontroll av partisjonsstrategi
Se for Dem en Erlang-klynge med fem noder. Det oppstår en nettverkspartisjon som deler den i to grupper: Node A, B (gruppe 1) og Node C, D, E (gruppe 2). Hvilke av følgende påstander om håndtering av denne partisjonen er generelt SANNE for å opprettholde dataintegritet og tilgjengelighet?
Oppsummering: robuste partisjoner
Vi har utforsket hvordan nettverkspartisjoner kan håndteres, noe som er et avgjørende aspekt ved bygging av robuste distribuerte Erlang-applikasjoner. Viktige punkter er:
- Oppdagelse: Bruk av helsesjekker på applikasjonsnivå, utover enkel frakobling.
- Kvorum: Bruk av strategier som «flertallet vinner» for å sikre at bare én partisjon er aktiv.
- Fencing: Hindring av at mindretallspartisjoner forårsaker datainkonsistens.
- Sammenføring: Strategier for å slå sammen avvikende tilstander når partisjoner er løst.
Disse prinsippene hjelper Erlang-systemene Deres med å forbli tilgjengelige og konsistente selv ved ustabile nettverksforhold.
Lær deg Erlang 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
Ofte stilte spørsmål
Er leksjonen «Håndtere nettverkspartisjoner» gratis?
Ja – du kan lese valgfritt 3 av leksjonene i læringsstien Erlang OTP: programmering av distribuerte og feiltolerante systemer, inkludert «Håndtere nettverkspartisjoner», gratis i sin helhet her på nettet. Deretter låser CoddyKit PRO opp alle leksjoner, samt interaktiv øving med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Kurset i Erlang OTP: programmering av distribuerte og feiltolerante systemer inneholder totalt 4 leksjoner.
Hva lærer jeg i «Håndtere nettverkspartisjoner»?
Utforsk strategier for kontrollert håndtering av nettverkssplittelser og -sammenslåinger i en distribuert Erlang-klynge, slik at systemintegriteten opprettholdes. Du øver på Erlang OTP: programmering av distribuerte og feiltolerante systemer 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 Erlang OTP: programmering av distribuerte og feiltolerante systemer?
Ingen tidligere erfaring er nødvendig. Erlang OTP: programmering av distribuerte og feiltolerante systemer 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 1 av 4.
Hvor lang tid tar leksjonen «Håndtere nettverkspartisjoner»?
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 Erlang OTP: programmering av distribuerte og feiltolerante systemer-leksjonen?
Ja. Alle Erlang OTP: programmering av distribuerte og feiltolerante systemer-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
- Håndtere nettverkspartisjoner
- Distribuerte data med ETS og Mnesia
- Utforming for skalerbarhet og robusthet
- Lastbalansering og failover på tvers av noder