Patronen voor leader election
Ontdek hoe Redis kan worden gebruikt voor leader election in gedistribueerde services met het oog op hoge beschikbaarheid.
Patronen voor leader election is een gratis Redis-caching en berichtenuitwisseling (Pub/Sub, Streams)-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 Redis-caching en berichtenuitwisseling (Pub/Sub, Streams). Je voortgang wordt gesynchroniseerd op het web en in de CoddyKit-app. De cursus Redis-caching en berichtenuitwisseling (Pub/Sub, Streams) bevat in totaal 4 lessen.
Waarom leiderverkiezingen?
In een gedistribueerd systeem draaien meerdere instanties van je toepassing tegelijk. Soms moet één instantie een specifieke taak uitvoeren, zoals het verwerken van een wachtrij of het coördineren van updates, om conflicten of dubbel werk te voorkomen.
Daar komt leiderverkiezing van pas. Dit is een proces waarbij gedistribueerde knooppunten het eens worden over één knooppunt dat op een bepaald moment de "leider" is.
Redis voor het coördineren van verkiezingen
Redis is een uitstekende keuze voor het implementeren van leiderverkiezingen vanwege de snelheid, atomische bewerkingen en sterke consistentiegaranties voor bewerkingen op één sleutel.
- Atomische bewerkingen: Opdrachten zoals
SETNXofSET ... NX EXworden volledig uitgevoerd of helemaal niet, waardoor racecondities worden voorkomen. - Persistentie: Als Redis hiervoor is geconfigureerd, kan het gegevens persistent opslaan, waardoor de toestand van de leiderverkiezing duurzamer wordt.
- Gecentraliseerde toestand: Redis biedt één overeengekomen bron van waarheid voor de identiteit van de huidige leider.
Basisverkiezing: SETNX
De eenvoudigste manier om met Redis een leiderverkiezing te proberen, is met de opdracht SETNX. SETNX key value ("Set if Not eXists") stelt een sleutel alleen in als deze nog niet bestaat. Als de sleutel wordt ingesteld, retourneert de opdracht 1; anders 0.
Het eerste proces dat de leidersleutel succesvol instelt, wordt de leider.
import redis
import time
# Connect to Redis
r = redis.Redis(decode_responses=True)
LEADER_KEY = "my_app:leader_v1"
MY_ID = "process_A" # Unique ID for this process
print(f"Process {MY_ID} attempting to become leader...")
# Try to acquire leadership
if r.setnx(LEADER_KEY, MY_ID):
print(f"Process {MY_ID} is now the leader!")
# Simulate leader work
time.sleep(3) # Work for 3 seconds
# In a real scenario, the leader would perform tasks
# and eventually release leadership or renew its lease.
r.delete(LEADER_KEY) # Release leadership
print(f"Process {MY_ID} released leadership.")
el:
current_leader = r.get(LEADER_KEY)
print(f"Process {MY_ID}: Another process ({current_leader}) is already the leader.")Het probleem: een leider valt uit
Bekijk de eenvoudige aanpak met SETNX. Wat gebeurt er als de gekozen leider (process_A uit het vorige voorbeeld) direct na het instellen van LEADER_KEY crasht, maar voordat het proces de kans krijgt om deze te verwijderen?
LEADER_KEY zou voor onbepaalde tijd in Redis blijven staan, waardoor geen enkel ander proces leider kan worden. Hierdoor ontstaat een permanente deadlock en wordt de hoge beschikbaarheid van je gedistribueerde systeem tenietgedaan.
TTL voor fouttolerantie
Om deadlocks te voorkomen, moeten we een vervaltijd (Time-To-Live, oftewel TTL) aan de leidersleutel toevoegen. Zo verloopt de leidersleutel uiteindelijk, zelfs als een leider crasht, en kan er een nieuwe verkiezing plaatsvinden.
Je kunt de opdracht EXPIRE key seconds direct na SETNX gebruiken om een TTL in te stellen.
import redis
import time
r = redis.Redis(decode_responses=True)
LEADER_KEY = "my_app:leader_v2"
MY_ID = "process_B"
LOCK_TTL = 10 # seconds
print(f"Process {MY_ID} attempting to become leader...")
if r.setnx(LEADER_KEY, MY_ID):
r.expire(LEADER_KEY, LOCK_TTL) # Set expiration
print(f"Process {MY_ID} is now the leader with TTL {LOCK_TTL}s!")
# Simulate leader work for a short period
time.sleep(LOCK_TTL // 2)
print(f"Process {MY_ID} completed its short task.")
if r.get(LEADER_KEY) == MY_ID: # Check if still leader before deleting
r.delete(LEADER_KEY)
print(f"Process {MY_ID} released leadership.")
else:
print(f"Process {MY_ID}: Leadership lost or expired already.")
el:
current_leader = r.get(LEADER_KEY)
print(f"Process {MY_ID}: Another process ({current_leader}) is already the leader.")De raceconditie tussen SETNX en EXPIRE
Hoewel het toevoegen van EXPIRE beter is, blijft er een kritieke raceconditie bestaan. Stel je de volgende volgorde voor:
- Proces A roept
SETNX LEADER_KEY process_Aaan. Dit lukt (de opdracht retourneert1). - Proces A crasht vervolgens voordat het
EXPIRE LEADER_KEY 10kan aanroepen.
LEADER_KEY is ingesteld, maar heeft geen TTL. Daardoor ontstaat dezelfde deadlocksituatie als eerder. We hebben een atomische manier nodig om de sleutel én de vervaltijd in te stellen.
Atomische SET voor robuustheid
Redis biedt een krachtige, atomische opdracht SET die het instellen van de waarde en de vervaltijd van een sleutel combineert. De indeling is SET key value [EX seconds | PX milliseconds] [NX | XX].
NX: stelt de sleutel alleen in als deze nog niet bestaat (net alsSETNX).EX seconds: stelt een vervaltijd in seconden in.PX milliseconds: stelt een vervaltijd in milliseconden in.
Met SET LEADER_KEY MY_ID NX EX 10 zorg je ervoor dat beide voorwaarden (de sleutel bestaat nog niet én er is een vervaltijd) atomisch worden toegepast.
import redis
import time
r = redis.Redis(decode_responses=True)
LEADER_KEY = "my_app:leader_v3"
MY_ID = "process_C"
LOCK_TTL = 10 # seconds
print(f"Process {MY_ID} attempting to become leader atomically...")
# Try to acquire leadership using atomic SET with NX and EX
# This command returns True if the key was set, False otherwise.
if r.set(LEADER_KEY, MY_ID, nx=True, ex=LOCK_TTL):
print(f"Process {MY_ID} is now the leader with atomic TTL {LOCK_TTL}s!")
# Simulate leader work
time.sleep(LOCK_TTL // 2)
print(f"Process {MY_ID} still working as leader.")
if r.get(LEADER_KEY) == MY_ID: # Important: check value before deleting!
r.delete(LEADER_KEY)
print(f"Process {MY_ID} gracefully released leadership.")
else:
print(f"Process {MY_ID}: Leadership lost or expired already.")
el:
current_leader = r.get(LEADER_KEY)
print(f"Process {MY_ID}: Another process ({current_leader}) is already the leader.")Leiderschap behouden: heartbeats
Nadat een leider met de atomische opdracht SET is gekozen, moet deze regelmatig aangeven dat hij nog actief is en kan blijven leiden. Dit gebeurt met "heartbeats".
Bij een heartbeat vernieuwt de leider de vervaltijd van zijn leidersleutel voordat deze verloopt (bijvoorbeeld met EXPIRE LEADER_KEY NEW_TTL of PEXPIRE). Als de leider geen heartbeats meer verstuurt, verloopt zijn sleutel en start er een nieuwe verkiezing onder de overgebleven processen.
Controleer je begrip
Welke van de volgende voordelen biedt het gebruik van de atomische opdracht SET key value NX EX seconds voor leiderverkiezingen in vergelijking met afzonderlijke opdrachten voor SETNX en EXPIRE?
Samenvatting: leiderverkiezingen
We hebben onderzocht hoe Redis leiderverkiezingen in gedistribueerde systemen kan ondersteunen. We begonnen met eenvoudige SETNX, brachten de problemen daarvan in kaart en leerden hoe we deze met EXPIRE kunnen verbeteren.
We ontdekten vooral de robuuste en atomische opdracht SET key value NX EX seconds, die racecondities voorkomt en ervoor zorgt dat sleutels altijd een vervaltijd hebben. Tot slot bespraken we kort het belang van heartbeats van de leider om actief leiderschap te behouden.
Leer Redis-caching en berichtenuitwisseling (Pub/Sub, Streams) 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 leader election” gratis?
Ja — je kunt hier op het web alle 3 lessen van het leerpad Redis-caching en berichtenuitwisseling (Pub/Sub, Streams), waaronder “Patronen voor leader election”, 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 Redis-caching en berichtenuitwisseling (Pub/Sub, Streams) bevat in totaal 4 lessen.
Wat leer ik in “Patronen voor leader election”?
Ontdek hoe Redis kan worden gebruikt voor leader election in gedistribueerde services met het oog op hoge beschikbaarheid. Je oefent met Redis-caching en berichtenuitwisseling (Pub/Sub, Streams) 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 Redis-caching en berichtenuitwisseling (Pub/Sub, Streams) te beginnen?
Ervaring vooraf is niet nodig. Redis-caching en berichtenuitwisseling (Pub/Sub, Streams) 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 leader election”?
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 Redis-caching en berichtenuitwisseling (Pub/Sub, Streams)?
Ja. Elke les over Redis-caching en berichtenuitwisseling (Pub/Sub, Streams) 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
- Gedistribueerde vergrendelingen met Redis
- Patronen voor leader election
- Redis als coördinatieservice
- Gedistribueerde rate limiting