Ledelsesvalg med konsul

1. Oversigt

I denne vejledning vi får se, hvordan ledelsesvalg med konsul hjælper med at sikre datastabilitet. Vi giver et praktisk eksempel på, hvordan man administrerer distribueret låsning i samtidige applikationer.

2. Hvad er konsul?

Consul er et open source-værktøj, der leverer service-registreringsdatabase og opdagelse baseret på sundhedskontrol. Derudover inkluderer den en webgrafisk brugergrænseflade (GUI) til at se og let interagere med konsul. Det dækker også ekstra funktioner i session management og Key-Value (KV) butik.

I de næste sektioner vil vi fokusere på, hvordan vi kan Brug Consuls session management og KV-butik til at vælge lederen i applikationer med flere forekomster.

3. Grundlæggende konsulater

Konsulagenten er den vigtigste komponent, der kører på hver node i en konsulklynge. Det har ansvaret for sundhedskontrol; registrering, opdagelse og løsning af tjenester; lagring af konfigurationsdata; og meget mere.

Konsulagenten kan løbe ind to forskellige tilstande - Server og agent.

Det vigtigste ansvaret for konsulserveren skal svare på forespørgsler fra agenterne og vælge lederen. Ledelsen vælges ved hjælp af konsensusprotokollen for at give konsistens (som defineret af CAP) baseret på Raft-algoritmen.

Det er ikke inden for denne artikels rækkevidde at gå i detaljer om, hvordan konsensus fungerer. Ikke desto mindre er det værd at nævne, at knudepunkterne kan være i en af ​​tre stater: leder, kandidat eller tilhænger. Det gemmer også dataene og reagerer på forespørgsler fra agenterne.

Agent er mere let end Consul-serveren. Det er ansvarligt for at køre sundhedstjek af de registrerede tjenester og videresende forespørgsler til serveren. Lad os se et simpelt diagram over en konsulklynge:

Konsul kan også hjælpe på andre måder - for eksempel i samtidige applikationer, hvor en instans skal være førende.

Lad os se i de kommende afsnit, hvordan Consul gennem session management og KV-butik kan give denne vigtige kapacitet.

4. Ledelsesvalg med konsul

I distribuerede implementeringer er den tjeneste, der holder låsen førende. Derfor er det afgørende for styring af låse og ledere for meget tilgængelige systemer.

Consul giver en brugervenlig KV-butik og session management. Disse funktionaliteter tjener til at opbygge ledervalg, så lad os lære principperne bag dem.

4.1. Lederskabskonflikt

Den første ting, alle forekomster, der hører til det distribuerede system, er at konkurrere om lederskabet. Påstanden om at være leder inkluderer en række trin:

  1. Alle forekomster skal være enige om en fælles nøgle for at kæmpe.
  2. Dernæst opretter forekomsten en session ved hjælp af den aftalte nøgle gennem styring af konsulsesession og KV-funktioner.
  3. For det tredje skal de erhverve sessionen. Hvis returværdien er rigtigt, hører låsen til forekomsten, og hvis falsk, forekomsten er en tilhænger.
  4. Forekomsterne skal løbende holde øje med, at sessionen erhverver ledelsen igen i tilfælde af fiasko eller frigivelse.
  5. Endelig kan lederen frigive sessionen, og processen begynder igen.

Når først lederen er valgt, bruger de øvrige tilfælde Konsul KV og session management til at finde lederen ved at:

  • Henter den aftalte nøgle
  • Få sessioninformation til at kende lederen

4.2. Et praktisk eksempel

Vi er nødt til at oprette nøglen og værdien sammen med sessionen i konsul med flere forekomster kørende. For at hjælpe med dette bruger vi Kinguin Digital Limited Leadership Consul open source Java-implementering.

Lad os først inkludere afhængigheden:

 com.github.kinguinltdhk lederskonsul $ {kinguinltdhk.version} com.ecwid.consul konsul-api 

Vi udelukkede konsul-api afhængighed for at undgå kollisioner med de forskellige versioner i Java.

Til den fælles nøgle bruger vi:

tjenester /% s / leder

Lad os teste hele processen med et simpelt uddrag:

ny SimpleConsulClusterFactory () .mode (SimpleConsulClusterFactory.MODE_MULTI) .debug (true) .build () .asObservable (). abonner (i -> System.out.println (i));

Derefter opretter vi en klynge med flere forekomster med somObservable () for at få adgang til begivenheder fra abonnenter. Lederen opretter en session i konsul, og alle forekomster bekræfter sessionen for at bekræfte lederskab.

Endelig tilpasser vi konsulkonfigurationen og sessionstyring, og den aftalte nøgle mellem instanserne til at vælge lederen:

klynge: leder: service Navn: klyngetjeneste Id: node-1 konsul: vært: localhost port: 8500 opdagelse: aktiveret: falsk session: ttl: 15 opdatering: 7 valg: konvolut Skabelon: tjenester /% s / leder

4.3. Sådan testes det

Der er flere muligheder for at installere Consul og køre en agent.

En af mulighederne for at implementere Consul er gennem containere. Vi bruger Consul Docker-billedet, der er tilgængeligt i Docker Hub, verdens største lager for containerbilleder.

Vi distribuerer Consul ved hjælp af Docker ved at køre kommandoen:

docker run -d --name konsul -p 8500: 8500 -e CONSUL_BIND_INTERFACE = eth0 konsul

Konsul kører nu, og den skal være tilgængelig på lokal vært: 8500.

Lad os udføre uddraget og kontrollere de udførte trin:

  1. Lederen opretter en session i konsul.
  2. Derefter vælges det (valgt. første).
  3. Resten af ​​forekomsterne ser, indtil sessionen frigives:
INFO: multi-mode aktiv INFO: Session oprettet e11b6ace-9dc7-4e51-b673-033f8134a7d4 INFO: Opdatering af session planlagt på 7 sekunders frekvens INFO: Stem frekvensopsætning på 10 sekunders frekvens -9dc7-4e51-b673-033f8134a7d4 ', serviceName = "cluster-app", serviceId = "node-1"}, error = null) ElectionMessage (status = valgt. Første, stemme = Afstem {sessionId =' e11b6ace-9dc7- 4e51-b673-033f8134a7d4 ', serviceName = "cluster-app", serviceId = "node-1"}, error = null) ElectionMessage (status = valgt, stemme = Afstem {sessionId =' e11b6ace-9dc7-4e51-b673-033f8134a7d4 ', serviceName = "cluster-app", serviceId = "node-1"}, error = null) 

Consul tilbyder også en web-GUI tilgængelig på // localhost: 8500 / ui.

Lad os åbne en browser og klikke på sektionen nøgleværdi for at bekræfte, at sessionen oprettes:

Derfor oprettede en af ​​de samtidige forekomster en session ved hjælp af den aftalte nøgle til applikationen. Først når sessionen frigives, kan processen starte forfra, og en ny instans kan blive leder.

5. Konklusion

I denne artikel viste vi fundamentet for Leadership Election i applikationer med høj ydeevne med flere forekomster. Vi demonstrerede, hvordan sessionadministration og KV-butikskapaciteter i Consul kan hjælpe med at erhverve låsen og vælge lederen.

Som altid er koden tilgængelig på GitHub.


$config[zx-auto] not found$config[zx-overlay] not found