Patronen voor gedistribueerde consensus
Begrijp en implementeer algoritmen en patronen voor gedistribueerde consensus, die cruciaal zijn voor het handhaven van consistentie in gedistribueerde systemen.
Patronen voor gedistribueerde consensus is een gratis Erlang OTP: programmeren van gedistribueerde en fouttolerante systemen-les op CoddyKit. Dit is les 2 van 4. Je kunt 3 lessen uit dit leerpad gratis volledig lezen — daarna ontgrendelt CoddyKit PRO alle lessen, plus praktische oefeningen met een ingebouwde code-editor en een AI-tutor die 24/7 beschikbaar is. Deze les maakt deel uit van het leertraject Erlang OTP: programmeren van gedistribueerde en fouttolerante systemen. Je voortgang wordt gesynchroniseerd op het web en in de CoddyKit-app. De cursus Erlang OTP: programmeren van gedistribueerde en fouttolerante systemen bevat in totaal 4 lessen.
Overeenstemming bereiken in een gedistribueerde wereld
Stel je voor dat meerdere computers (knooppunten) het eens moeten worden over één uitkomst, zelfs als sommige knooppunten uitvallen of berichten verloren gaan. Deze uitdaging heet gedistribueerde consensus.
Dit is essentieel om de consistentie van gegevens te behouden en ervoor te zorgen dat alle onderdelen van een systeem dezelfde "waarheid" zien. Zonder consensus kan je systeem in een verwarde, inconsistente toestand terechtkomen.
Het moeilijke coördinatieprobleem
Consensus bereiken is moeilijk omdat:
- Netwerkvertragingen: Berichten komen niet onmiddellijk of niet in de juiste volgorde aan.
- Storingen van knooppunten: Een computer kan op elk moment crashen.
- Berichtverlies: Berichten kunnen door het netwerk worden verwijderd.
Hoe zorg je ervoor dat iedereen het eens wordt wanneer communicatie onbetrouwbaar is en deelnemers kunnen verdwijnen?
Waar consensus van pas komt
Patronen voor gedistribueerde consensus vormen de basis voor veel kritieke systeemfuncties:
- Leidersverkiezing: Bepalen welk knooppunt de primaire coördinator wordt.
- Atomische commits: Ervoor zorgen dat een transactie op alle knooppunten volledig wordt voltooid of op alle knooppunten volledig mislukt.
- Replicatie van toestandsmachines: Identieke kopieën van gegevens of applicatiestatus behouden op meerdere knooppunten.
CAP en afwegingen bij consensus
De CAP-stelling stelt dat een gedistribueerd systeem slechts twee van drie eigenschappen kan garanderen: consistentie, beschikbaarheid of partitioneringstolerantie.
Consensusalgoritmen geven doorgaans prioriteit aan consistentie en partitioneringstolerantie. Dit betekent dat het systeem tijdens een netwerkpartitionering mogelijk niet beschikbaar is voor schrijfbewerkingen, om inconsistenties te voorkomen.
Een eenvoudig overeenstemmingsprotocol: 2PC
Het Two-Phase Commit (2PC)-protocol is een eenvoudige manier om atomische transacties uit te voeren op gedistribueerde knooppunten. Het wordt vaak gebruikt in databases.
Hoewel het niet volledig fouttolerant is (het kan blokkeren als de coördinator uitvalt), is het een goede conceptuele opstap naar het begrijpen van complexere consensusalgoritmen.
De coördinator: de stemming orkestreren
Bij 2PC treedt één knooppunt op als de coördinator. Zijn taak is:
- Fase 1 (voorbereiden): Een bericht met de tekst "voorbereiden" of "stemverzoek" sturen naar alle deelnemende knooppunten.
- Fase 2 (commit): Op basis van de stemmen een bericht met de tekst "commit" sturen als iedereen "ja" heeft gestemd, of een bericht met de tekst "afbreken" als iemand "nee" heeft gestemd of de time-out is verstreken.
Deelnemers: beslissen en handelen
Elk knooppunt dat deelnemer is in 2PC heeft deze verantwoordelijkheden:
- Fase 1 (stemmen): Voer bij ontvangst van "voorbereiden" de nodige controles uit. Als je klaar bent om te committen, antwoord je met "ja" en vergrendel je de bronnen. Anders antwoord je met "nee".
- Fase 2 (handelen): Rond de transactie af bij ontvangst van "commit". Bij "afbreken" draai je wijzigingen terug en ontgrendel je de bronnen.
Erlang-coördinator: stemproces
We simuleren een eenvoudige 2PC-coördinator in Erlang. Deze start deelnemers, stuurt een bericht en verzamelt hun antwoorden. Dit voorbeeld vereenvoudigt de foutafhandeling voor de duidelijkheid.
Let op: dit is geen 2PC voor productiegebruik, maar alleen een illustratie van de berichtenstroom.
-module(coordinator).
-behaviour(gen_server).
-export([start_link/0, init/1, handle_call/3, handle_cast/2, handle_info/2, terminate/2, code_change/3]).
-export([propose/2]).
start_link() ->
gen_server:start_link({local, ?MODULE}, ?MODULE, [], []).
init([]) ->
{ok, []}.
propose(CoordinatorPid, Value) ->
gen_server:call(CoordinatorPid, {propose, Value}).
handle_call({propose, Value}, _From, _State) ->
% In a real system, participants would be registered or known
Pids = [
spawn(fun participant:start/0),
spawn(fun participant:start/0)
],
io:format("Coordinator: Proposing ~p to participants: ~p~n", [Value, Pids]),
% Phase 1: Prepare
Responses = [rpc:call(Pid, participant, prepare, [Value]) || Pid <- Pids],
FinalDecision =
case lists:all(fun(ok) -> true; (_) -> false end, Responses) of
true -> commit;
false -> abort
end,
io:format("Coordinator: All participants voted, decision: ~p~n", [FinalDecision]),
% Phase 2: Commit/Abort
[rpc:call(Pid, participant, FinalDecision, []) || Pid <- Pids],
{reply, FinalDecision, _State}.
handle_cast(_Msg, State) -> {noreply, State}.
handle_info(_Info, State) -> {noreply, State}.
terminate(_Reason, _State) -> ok.
code_change(_OldVsn, State, _Extra) -> {ok, State}.
% To run this example:
% 1. Compile both coordinator.erl and participant.erl
% 2. Start Erlang shell: erl
% 3. coordinator:start_link().
% 4. coordinator:propose(whereis(coordinator), "My Transaction").
% You should see output from both coordinator and participants.Erlang-deelnemer: stemmen en handelen
Zo kan een deelnemersproces reageren op de coördinator. Het simuleert een "stem" en handelt vervolgens op de instructie "commit" of "afbreken".
Deze deelnemer stemt in deze vereenvoudigde versie altijd 'ok', maar in werkelijkheid zou het proces zijn eigen status controleren.
-module(participant).
-behaviour(gen_server).
-export([start_link/0, start/0, init/1, handle_call/3, handle_cast/2, handle_info/2, terminate/2, code_change/3]).
-export([prepare/1, commit/0, abort/0]).
start_link() ->
gen_server:start_link(?MODULE, [], []).
start() -> % Used by coordinator to spawn
{ok, Pid} = start_link(),
Pid.
init([]) ->
io:format("Participant ~p: Started.~n", [self()]),
{ok, #{} % State could hold transaction details
}.
prepare(_Value) ->
% In a real system, participant would check resources, lock them etc.
% For simplicity, always vote 'ok' here.
io:format("Participant ~p: Received prepare, voting 'ok'.~n", [self()]),
ok.
commit() ->
io:format("Participant ~p: Received commit, finalizing transaction.~n", [self()]),
ok.
abort() ->
io:format("Participant ~p: Received abort, rolling back transaction.~n", [self()]),
ok.
handle_call(_Msg, _From, State) ->
{reply, ok, State}. % Placeholder for any calls
handle_cast(_Msg, State) -> {noreply, State}.
handle_info(_Info, State) -> {noreply, State}.
terminate(_Reason, _State) -> ok.
code_change(_OldVsn, State, _Extra) -> {ok, State}.De valkuilen van 2PC
Hoewel 2PC verhelderend is, heeft het belangrijke nadelen:
- Single point of failure: Als de coördinator tijdens fase 2 crasht, kunnen deelnemers onbeperkt blijven wachten terwijl ze vergrendelde bronnen vasthouden. Dit staat bekend als het "blokkeringsprobleem".
- Prestaties: Er zijn meerdere communicatierondes nodig, wat traag kan zijn in netwerken met hoge latentie.
Deze beperkingen maken robuustere, niet-blokkerende consensusalgoritmen zoals Paxos of Raft noodzakelijk voor echt fouttolerante systemen.
Snelle controle: rollen bij consensus
Wat is in het Two-Phase Commit (2PC)-protocol de belangrijkste verantwoordelijkheid van een knooppunt dat deelnemer is in fase 1 (voorbereiden)?
Samenvatting: overeenstemming is essentieel
We hebben gedistribueerde consensus onderzocht en het belang ervan voor consistentie in gedistribueerde systemen en de bijbehorende uitdagingen begrepen.
We hebben Two-Phase Commit (2PC) bekeken als een eenvoudig protocol, waarbij we de rollen van de coördinator en deelnemers en de belangrijkste beperkingen ervan hebben leren kennen. Het doorgeven van berichten in Erlang vormt een goede basis voor het bouwen van deze patronen, maar voor echt fouttolerante consensus zijn geavanceerdere algoritmen nodig.
Leer Erlang met een AI-tutor — gratis
Schrijf echte code en voer die uit in je browser, krijg direct hulp van een AI-tutor die 24/7 beschikbaar is en ga verder waar je gebleven bent op het web of in de app.
- Cursussen
- 12
- Lessen
- 48
Veelgestelde vragen
Is de les “Patronen voor gedistribueerde consensus” gratis?
Ja — je kunt hier op het web alle 3 lessen van het leerpad Erlang OTP: programmeren van gedistribueerde en fouttolerante systemen, waaronder “Patronen voor gedistribueerde consensus”, gratis volledig lezen. Daarna ontgrendelt CoddyKit PRO alle lessen, plus interactieve oefeningen met een ingebouwde code-editor en een AI-tutor die 24/7 beschikbaar is. De cursus Erlang OTP: programmeren van gedistribueerde en fouttolerante systemen bevat in totaal 4 lessen.
Wat leer ik in “Patronen voor gedistribueerde consensus”?
Begrijp en implementeer algoritmen en patronen voor gedistribueerde consensus, die cruciaal zijn voor het handhaven van consistentie in gedistribueerde systemen. Je oefent met Erlang OTP: programmeren van gedistribueerde en fouttolerante systemen door code rechtstreeks in de browser uit te voeren. Een AI-begeleider die 24/7 beschikbaar is beantwoordt je vragen terwijl je de les doorwerkt.
Heb ik ervaring nodig om met Erlang OTP: programmeren van gedistribueerde en fouttolerante systemen te beginnen?
Ervaring vooraf is niet nodig. Erlang OTP: programmeren van gedistribueerde en fouttolerante systemen op CoddyKit is opgebouwd voor beginners tot gevorderden, zodat je hier of bij het begin kunt starten en in je eigen tempo kunt leren. Dit is les 2 van 4.
Hoe lang duurt de les “Patronen voor gedistribueerde consensus”?
De meeste lessen van CoddyKit duren ongeveer 5–10 minuten. Elke les is kort en interactief, zodat je gestaag vooruitgaat en op het web en in de app precies verdergaat waar je was gebleven.
Kan ik code schrijven en uitvoeren in deze les over Erlang OTP: programmeren van gedistribueerde en fouttolerante systemen?
Ja. Elke les over Erlang OTP: programmeren van gedistribueerde en fouttolerante systemen bevat een ingebouwde code-editor, zodat je rechtstreeks in je browser echte code kunt schrijven en uitvoeren en direct feedback van AI krijgt — lokale installatie is niet nodig.
Alle lessen in deze cursus
- Ontwerpen voor hoge beschikbaarheid
- Patronen voor gedistribueerde consensus
- Praktijkvoorbeelden van Erlang OTP
- Backpressure- en loadregulatiepatronen