Fejltolerance og høj tilgængelighed er store emner, så vi vil afsætte separate artikler til RabbitMQ og Kafka. Denne artikel handler om RabbitMQ, og den næste handler om Kafka i sammenligning med RabbitMQ. Dette er en lang artikel, så gør dig godt tilpas.

Lad os se på fejltolerance, konsistens og høj tilgængelighed (HA) strategier og de afvejninger, som hver strategi gør. RabbitMQ kan køre på en klynge af noder - og klassificeres derefter som et distribueret system. Når det kommer til distribuerede systemer, taler vi ofte om konsistens og tilgængelighed.

Disse begreber beskriver, hvordan et system opfører sig, når det svigter. Netværksforbindelsesfejl, serverfejl, harddiskfejl, server midlertidig utilgængelighed på grund af affaldsindsamling, pakketab eller afmatning af netværksforbindelsen. Alt dette kan føre til datatab eller konflikter. Det viser sig, at det er praktisk talt umuligt at opstille et system, der både er fuldstændig konsistent (intet datatab, ingen datadivergens) og tilgængeligt (vil acceptere læsning og skrivning) for alle fejlscenarier.

Vi vil se, at konsistens og tilgængelighed er i hver sin ende af spektret, og du skal vælge, hvilken måde du vil optimere. Den gode nyhed er, at med RabbitMQ er dette valg muligt. Du har den slags "nørdede" håndtag til at flytte balancen mod større konsistens eller større tilgængelighed.

Vi vil være særligt opmærksomme på, hvilke konfigurationer der fører til datatab på grund af bekræftede registreringer. Der er en ansvarskæde mellem forlag, mæglere og forbrugere. Når først beskeden er overført til mægleren, er det hans opgave ikke at miste beskeden. Når mægleren kvitterer for udgiverens modtagelse af beskeden, forventer vi ikke, at den er tabt. Men vi vil se, at dette faktisk kan ske afhængigt af din mægler- og udgiverkonfiguration.

Single Node Resilience Primitives

Elastisk kø/routing

Der er to typer køer i RabbitMQ: holdbare og ikke-holdbare. Alle køer gemmes i Mnesia-databasen. Holdbare køer reklameres igen ved nodestart og overlever således genstarter, systemnedbrud eller servernedbrud (så længe dataene bevares). Det betyder, at så længe du erklærer routing (udveksling) og kø for at være modstandsdygtig, vil kø/routing-infrastrukturen komme online igen.

Flygtige køer og routing fjernes, når noden genstartes.

Vedvarende beskeder

Bare fordi en kø er holdbar, betyder det ikke, at alle dens meddelelser vil overleve en genstart af noden. Kun meddelelser angivet af udgiveren som vedvarende (vedholdende). Vedvarende beskeder skaber yderligere belastning på mægleren, men hvis beskedtab er uacceptabelt, er der ingen anden mulighed.

Ris. 1. Bæredygtighedsmatrix

Klynger med køspejling

For at overleve tabet af en mægler har vi brug for redundans. Vi kan kombinere flere RabbitMQ-noder til en klynge og derefter tilføje yderligere redundans ved at replikere køer mellem flere knudepunkter. På denne måde, hvis en node fejler, mister vi ikke data og forbliver tilgængelige.

Køspejling:

• én hovedkø (master), som modtager alle skrive- og læsekommandoer
• et eller flere spejle, der modtager alle beskeder og metadata fra hovedkøen. Disse spejle er ikke til for skalering, men udelukkende for redundans.

Ris. 2. Køspejling

Spejling er fastsat af den relevante politik. I den kan du vælge replikeringskoefficienten og endda de noder, hvorpå køen skal være placeret. Eksempler:

• ha-mode: all
• ha-mode: exactly, ha-params: 2 (en mester og et spejl)
• ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2

Udgiver bekræftelse

For at opnå ensartet optagelse kræves udgiverbekræftelser. Uden dem er der risiko for, at beskeder går tabt. En bekræftelse sendes til udgiveren, efter at meddelelsen er skrevet til disken. RabbitMQ skriver beskeder til disken ikke ved modtagelse, men på en periodisk basis i området af flere hundrede millisekunder. Når en kø spejles, sendes der først en bekræftelse, efter at alle spejle også har skrevet deres kopi af meddelelsen til disken. Det betyder, at brug af bekræftelser tilføjer latency, men hvis datasikkerhed er vigtig, så er de nødvendige.

Failover-kø

Når en mægler afslutter eller går ned, styrter alle køledere (mastere) på den node sammen med den. Klyngen vælger derefter det ældste spejl af hver master og promoverer det som den nye master.

Ris. 3. Flere spejlede køer og deres politikker

Broker 3 går ned. Bemærk, at Queue C-spejlet på Broker 2 bliver forfremmet til master. Bemærk også, at der er oprettet et nyt spejl for Kø C på Broker 1. RabbitMQ forsøger altid at opretholde den replikeringsfaktor, der er angivet i dine politikker.

Ris. 4. Broker 3 fejler, hvilket får kø C til at mislykkes

Den næste Broker 1 falder! Vi har kun én mægler tilbage. Kø B-spejlet er forfremmet til at mestre.

Fig. 5

Vi har returneret Broker 1. Uanset hvor godt dataene overlever tabet og gendannelsen af ​​brokeren, kasseres alle spejlede kømeddelelser ved genstart. Dette er vigtigt at bemærke, fordi der vil være konsekvenser. Vi vil se på disse implikationer snart. Så Broker 1 er nu medlem af klyngen igen, og klyngen forsøger at overholde politikkerne og skaber derfor spejle på Broker 1.

I dette tilfælde var tabet af Broker 1 fuldstændig, ligesom dataene var, så den uspejlede kø B gik fuldstændig tabt.

Ris. 6. Mægler 1 vender tilbage til tjeneste

Broker 3 er tilbage online, så køerne A og B får de spejle, der er oprettet på den, tilbage for at opfylde deres HA-politikker. Men nu er alle hovedkøerne på én knude! Dette er ikke ideelt, en jævn fordeling mellem noder er bedre. Desværre er der ikke mange muligheder her for rebalancering af mastere. Vi vender tilbage til dette problem senere, fordi vi først skal se på køsynkronisering.

Ris. 7. Broker 3 vender tilbage til tjeneste. Alle hovedkøer på én knude!

Så nu skulle du have en idé om, hvordan spejle giver redundans og fejltolerance. Dette sikrer tilgængelighed i tilfælde af en enkelt knudefejl og beskytter mod tab af data. Men vi er ikke færdige endnu, for i virkeligheden er det meget mere kompliceret.

synkronisering

Når du opretter et nyt spejl, vil alle nye beskeder altid blive replikeret til dette spejl og eventuelle andre. Hvad angår de eksisterende data i masterkøen, kan vi replikere dem til et nyt spejl, som bliver en komplet kopi af masteren. Vi kan også vælge ikke at replikere eksisterende beskeder og lade hovedkøen og det nye spejl konvergere i tide, hvor nye beskeder ankommer til halen og eksisterende beskeder, der forlader hovedkøen.

Denne synkronisering udføres automatisk eller manuelt og administreres ved hjælp af en køpolitik. Lad os se på et eksempel.

Vi har to spejlede køer. Kø A synkroniseres automatisk, og Kø B synkroniseres manuelt. Begge køer indeholder ti beskeder.

Ris. 8. To køer med forskellige synkroniseringstilstande

Nu mister vi Broker 3.

Ris. 9. Mægler 3 faldt

Broker 3 vender tilbage til tjeneste. Klyngen opretter et spejl for hver kø på den nye node og synkroniserer automatisk den nye kø A med masteren. Men spejlet i den nye kø B forbliver tomt. På denne måde har vi fuld redundans på Kø A og kun ét spejl for eksisterende Kø B-meddelelser.

Ris. 10. Det nye spejl af Kø A modtager alle eksisterende meddelelser, men det nye spejl i Kø B gør det ikke.

Der kommer ti beskeder mere i begge køer. Broker 2 går derefter ned, og kø A ruller tilbage til det ældste spejl, som er på Broker 1. Der er intet datatab, når det fejler. I kø B er der tyve beskeder i masteren og kun ti i spejlet, fordi denne kø aldrig replikerede de originale ti beskeder.

Ris. 11. Kø A ruller tilbage til Broker 1 uden at miste beskeder

Der kommer ti beskeder mere i begge køer. Nu går Broker 1 ned. Kø A skifter nemt til spejlet uden at miste beskeder. Kø B har dog problemer. På dette tidspunkt kan vi optimere enten tilgængelighed eller konsistens.

Hvis vi vil optimere tilgængeligheden, så politikken ha-fremme-ved-fejl skal monteres i altid. Dette er standardværdien, så du kan simpelthen ikke angive politikken overhovedet. I dette tilfælde tillader vi i det væsentlige fejl i usynkroniserede spejle. Dette vil medføre, at meddelelser går tabt, men køen forbliver læsbar og skrivbar.

Ris. 12. Kø A rulles tilbage til Broker 3 uden at miste beskeder. Kø B ruller tilbage til Broker 3 med ti meddelelser tabt

Vi kan også installere ha-promote-on-failure i betydning when-synced. I dette tilfælde, i stedet for at rulle tilbage til spejlet, vil køen vente, indtil Broker 1 med sine data vender tilbage til online-tilstand. Når den vender tilbage, er hovedkøen tilbage på Broker 1 uden tab af data. Tilgængelighed er ofret for datasikkerhed. Men dette er en risikabel tilstand, der endda kan føre til fuldstændigt datatab, som vi vil se på om kort tid.

Ris. 13. Kø B forbliver utilgængelig efter at have mistet Broker 1

Du kan spørge: "Er det bedre aldrig at bruge automatisk synkronisering?" Svaret er, at synkronisering er en blokerende operation. Under synkronisering kan hovedkøen ikke udføre nogen læse- eller skrivehandlinger!

Lad os se på et eksempel. Nu har vi meget lange køer. Hvordan kan de vokse til sådan en størrelse? Af flere grunde:

• Køer bruges ikke aktivt
• Det er højhastighedskøer, og lige nu er forbrugerne langsomme
• Det er højhastighedskøer, der har været en fejl, og forbrugerne er ved at indhente det

Ris. 14. To store køer med forskellige synkroniseringstilstande

Nu falder Broker 3.

Ris. 15. Broker 3 falder og efterlader én master og spejl i hver kø

Broker 3 kommer online igen, og nye spejle oprettes. Hovedkø A begynder at replikere eksisterende meddelelser til det nye spejl, og i dette tidsrum er køen utilgængelig. Det tager to timer at replikere dataene, hvilket resulterer i to timers nedetid for denne kø!

Kø B forbliver dog tilgængelig i hele perioden. Hun ofrede noget redundans for tilgængelighed.

Ris. 16. Køen forbliver utilgængelig under synkronisering

Efter to timer bliver kø A også tilgængelig og kan begynde at acceptere læsninger og skrivninger igen.

Opdateringer

Denne blokeringsadfærd under synkronisering gør det vanskeligt at opdatere klynger med meget store køer. På et tidspunkt skal masternoden genstartes, hvilket betyder enten at skifte til et spejl eller at deaktivere køen, mens serveren opgraderes. Hvis vi vælger at skifte, mister vi beskeder, hvis spejlene ikke er synkroniserede. Som standard udføres der ikke en failover til et usynkroniseret spejl under et mæglerudfald. Det betyder, at så snart mægleren vender tilbage, mister vi ingen beskeder, den eneste skade var en simpel kø. Regler for adfærd, når en mægler er afbrudt, er fastsat af politik ha-promote-on-shutdown. Du kan indstille en af ​​to værdier:

• always= overgang til usynkroniserede spejle er aktiveret
• when-synced= kun overgang til et synkroniseret spejl, ellers bliver køen ulæselig og uskrivelig. Køen vender tilbage til service, så snart mægleren vender tilbage

På den ene eller anden måde skal du med store køer vælge mellem tab af data og utilgængelighed.

Når tilgængelighed forbedrer datasikkerheden

Der er endnu en komplikation at overveje, før du træffer en beslutning. Selvom automatisk synkronisering er bedre til redundans, hvordan påvirker det datasikkerheden? Selvfølgelig, med bedre redundans, er RabbitMQ mindre tilbøjelige til at miste eksisterende beskeder, men hvad med nye beskeder fra udgivere?

Her skal du overveje følgende:

• Kunne udgiveren blot returnere en fejl og få upstream-tjenesten eller brugeren til at prøve igen senere?
• Kan udgiveren gemme meddelelsen lokalt eller i en database for at prøve igen senere?

Hvis udgiveren kun kan kassere beskeden, så forbedrer en forbedring af tilgængeligheden faktisk også datasikkerheden.

Der skal således søges en balance, og løsningen afhænger af den konkrete situation.

Problemer med ha-promote-on-failure=when-synced

Idea ha-fremme-ved-fejl= når den er synkroniseret er, at vi forhindrer skift til et usynkroniseret spejl og derved undgår datatab. Køen forbliver ulæselig eller skrivbar. I stedet forsøger vi at gendanne den nedbrudte mægler med dens data intakt, så den kan genoptage at fungere som en master uden tab af data.

Men (og det er et stort men) hvis mægleren har mistet sine data, så har vi et stort problem: køen er tabt! Alle data er væk! Selvom du har spejle, der for det meste indhenter hovedkøen, kasseres disse spejle også.

For at tilføje en node med samme navn igen, fortæller vi klyngen at glemme den tabte node (med kommandoen rabbitmqctl forget_cluster_node) og start en ny mægler med det samme værtsnavn. Mens klyngen husker den tabte node, husker den den gamle kø og usynkroniserede spejle. Når en klynge får besked på at glemme en forældreløs knude, bliver den kø også glemt. Nu skal vi genanmelde det. Vi mistede alle data, selvom vi havde spejle med et delvist sæt data. Det ville være bedre at skifte til et ikke-synkroniseret spejl!

Derfor manuel synkronisering (og manglende synkronisering) i kombination med ha-promote-on-failure=when-syncedefter min mening ret risikabelt. Dokumenterne siger, at denne mulighed eksisterer for datasikkerhed, men det er en tveægget kniv.

Mestre rebalancering

Som lovet vender vi tilbage til problemet med akkumulering af alle mastere på en eller flere noder. Dette kan endda ske som et resultat af en rullende klyngeopdatering. I en klynge med tre noder vil alle masterkøer akkumuleres på en eller to noder.

Rebalancering af mastere kan være problematisk af to årsager:

• Der er ingen gode værktøjer til at udføre rebalancering
• Køsynkronisering

Der er en tredjepart til rebalancering plugin, som ikke er officielt understøttet. Angående tredjeparts plugins i RabbitMQ manualen sagde: “Pluginnet giver nogle ekstra konfigurations- og rapporteringsværktøjer, men understøttes eller verificeres ikke af RabbitMQ-teamet. Brug på eget ansvar."

Der er et andet trick til at flytte hovedkøen gennem HA-politikker. Manualen nævner manuskript for det. Det fungerer sådan her:

• Fjerner alle spejle ved hjælp af en midlertidig politik, der har en højere prioritet end den eksisterende HA-politik.
• Ændrer den midlertidige HA-politik til at bruge nodetilstand, og specificerer den node, som masterkøen skal overføres til.
• Synkroniserer køen til push-migrering.
• Når migreringen er fuldført, sletter den midlertidige politik. Den oprindelige HA-politik træder i kraft, og det nødvendige antal spejle oprettes.

Ulempen er, at denne tilgang muligvis ikke virker, hvis du har store køer eller strenge krav til redundans.

Lad os nu se, hvordan RabbitMQ-klynger fungerer med netværkspartitioner.

Tab af forbindelse

Noderne i et distribueret system er forbundet med netværkslinks, og netværkslinks kan og vil blive afbrudt. Hyppigheden af ​​udfald afhænger af den lokale infrastruktur eller pålideligheden af ​​den valgte sky. Under alle omstændigheder skal distribuerede systemer kunne klare dem. Endnu en gang har vi et valg mellem tilgængelighed og konsistens, og igen er den gode nyhed, at RabbitMQ tilbyder begge muligheder (bare ikke på samme tid).

Med RabbitMQ har vi to hovedmuligheder:

• Tillad logisk division (split-brain). Dette sikrer tilgængelighed, men kan forårsage tab af data.
• Deaktiver logisk adskillelse. Kan resultere i kortsigtet tab af tilgængelighed afhængigt af, hvordan klienter opretter forbindelse til klyngen. Kan også føre til fuldstændig utilgængelighed i en to-node klynge.

Men hvad er logisk adskillelse? Dette er, når en klynge opdeles i to på grund af tab af netværksforbindelser. På hver side forfremmes spejlene til en master, så der efterhånden er flere mastere per kø.

Ris. 17. Hovedkø og to spejle på hver sin node. Så opstår der en netværksfejl, og det ene spejl bliver løsrevet. Den adskilte node ser, at de to andre er faldet af og fremmer sine spejle til mesteren. Vi har nu to hovedkøer, både skrivbare og læsbare.

Hvis udgivere sender data til begge mastere, ender vi med to divergerende kopier af køen.

RabbitMQs forskellige tilstande giver enten tilgængelighed eller konsistens.

Ignorer tilstand (standard)

Denne tilstand sikrer tilgængelighed. Efter tab af forbindelse sker der en logisk adskillelse. Efter at forbindelsen er gendannet, skal administratoren beslutte, hvilken partition der skal prioriteres. Den tabende side vil blive genstartet, og alle akkumulerede data på den side vil gå tabt.

Ris. 18. Tre forlag er tilknyttet tre mæglere. Internt dirigerer klyngen alle anmodninger til hovedkøen på Broker 2.

Nu mister vi Broker 3. Han ser, at andre mæglere er faldet fra og promoverer sit spejl til mesteren. Sådan opstår en logisk adskillelse.

Ris. 19. Logisk opdeling (split-brain). Optegnelser går i to hovedkøer, og de to kopier adskiller sig.

Forbindelsen genoprettes, men logisk adskillelse forbliver. Administratoren skal manuelt vælge den tabende side. I nedenstående tilfælde genstarter administratoren Broker 3. Alle meddelelser, som han ikke formåede at sende, går tabt.

Ris. 20. Administratoren deaktiverer Broker 3.

Ris. 21. Administratoren starter Broker 3, og den slutter sig til klyngen og mister alle beskeder, der blev efterladt der.

Under tabet af forbindelse og efter dens genoprettelse var klyngen og denne kø tilgængelige for læsning og skrivning.

Autoheal-tilstand

Fungerer på samme måde som Ignorer-tilstand, bortset fra at klyngen selv automatisk vælger den tabende side efter opdeling og genoprettelse af forbindelse. Den tabende side vender tilbage til klyngen tom, og køen mister alle meddelelser, der kun blev sendt til den side.

Sæt minoritetstilstand på pause

Hvis vi ikke ønsker at tillade logisk partitionering, så er vores eneste mulighed at kassere læsninger og skrivninger på den mindre side efter klyngepartitionen. Når mægleren ser, at den er på den mindre side, suspenderer den arbejdet, det vil sige, at den lukker alle eksisterende forbindelser og nægter nye. En gang i sekundet tjekker den for genoprettelse af forbindelse. Når forbindelsen er genoprettet, genoptager den driften og slutter sig til klyngen.

Ris. 22. Tre forlag er tilknyttet tre mæglere. Internt dirigerer klyngen alle anmodninger til hovedkøen på Broker 2.

Mægler 1 og 2 splittes derefter fra Broker 3. I stedet for at promovere deres spejl til master, suspenderes Broker 3 og bliver utilgængelig.

Ris. 23. Broker 3 pauser, afbryder forbindelsen til alle klienter og afviser forbindelsesanmodninger.

Når forbindelsen er genoprettet, vender den tilbage til klyngen.

Lad os se på et andet eksempel, hvor hovedkøen er på Broker 3.

Ris. 24. Hovedkø på Broker 3.

Så opstår det samme tab af forbindelse. Broker 3 holder pause, fordi den er på den mindre side. På den anden side ser noderne, at Broker 3 er faldet af, så det ældre spejl fra Brokers 1 og 2 er forfremmet til master.

Ris. 25. Overgang til Broker 2, hvis Broker 3 ikke er tilgængelig.

Når forbindelsen er genoprettet, slutter Broker 3 sig til klyngen.

Ris. 26. Klyngen er vendt tilbage til normal drift.

Det vigtige at forstå her er, at vi får konsistens, men vi kan også få tilgængelighed, hvis Vi vil med succes overføre kunder til det meste af sektionen. I de fleste situationer ville jeg personligt vælge Pause Minority-tilstanden, men det afhænger virkelig af den enkelte sag.

For at sikre tilgængelighed er det vigtigt at sikre, at klienter opretter forbindelse til værten. Lad os se på vores muligheder.

Sikring af kundeforbindelse

Vi har flere muligheder for, hvordan man dirigerer klienter til hoveddelen af ​​klyngen eller til arbejdende knudepunkter (efter at en knude svigter) efter tab af forbindelse. Lad os først huske, at en specifik kø er hostet på en bestemt node, men routing og politikker replikeres på tværs af alle noder. Klienter kan oprette forbindelse til enhver node, og intern routing vil dirigere dem, hvor de skal hen. Men når en node er suspenderet, afviser den forbindelser, så klienter skal oprette forbindelse til en anden node. Hvis knudepunktet falder af, er der ikke meget, han overhovedet kan gøre.

Vores muligheder:

• Der tilgås klyngen ved hjælp af en belastningsbalancer, der blot går gennem noderne, og klienter forsøger at oprette forbindelse igen, indtil det lykkes. Hvis en node er nede eller suspenderet, vil forsøg på at oprette forbindelse til den node mislykkes, men efterfølgende forsøg vil gå til andre servere (på en round-robin måde). Dette er velegnet til et kortvarigt tab af forbindelse eller en nedbrudt server, der hurtigt vil blive bragt op igen.
• Få adgang til klyngen gennem en belastningsbalancer, og fjern suspenderede/mislykkede noder fra listen, så snart de er opdaget. Hvis vi gør dette hurtigt, og hvis klienter er i stand til at prøve forbindelsen igen, vil vi opnå konstant tilgængelighed.
• Giv hver klient en liste over alle noder, og klienten vælger tilfældigt en af ​​dem, når den opretter forbindelse. Hvis den modtager en fejl, når den forsøger at oprette forbindelse, flytter den til den næste node på listen, indtil den opretter forbindelse.
• Fjern trafik fra en mislykket/suspenderet node ved hjælp af DNS. Dette gøres ved hjælp af en lille TTL.

Fund

RabbitMQ clustering har sine fordele og ulemper. De mest alvorlige ulemper er, at:

• når de tilslutter sig en klynge, kasserer noder deres data;
• blokering af synkronisering får køen til at blive utilgængelig.

Alle vanskelige beslutninger stammer fra disse to arkitektoniske træk. Hvis RabbitMQ kunne gemme data, når klyngen genforenes, ville synkroniseringen være hurtigere. Hvis det var i stand til ikke-blokerende synkronisering, ville det bedre understøtte store køer. Løsning af disse to problemer ville i høj grad forbedre RabbitMQs ydeevne som en fejltolerant og yderst tilgængelig beskedteknologi. Jeg vil være tøvende med at anbefale RabbitMQ med clustering i følgende situationer:

• Upålideligt netværk.
• Upålidelig opbevaring.
• Meget lange køer.

Når det kommer til indstillinger for høj tilgængelighed, skal du overveje følgende:

• ha-promote-on-failure=always
• ha-sync-mode=manual
• cluster_partition_handling=ignore (eller autoheal)
• vedvarende beskeder
• sikre, at klienter opretter forbindelse til den aktive knude, når en knude svigter

For konsistens (datasikkerhed) skal du overveje følgende indstillinger:

• Udgiver bekræfter og manuelle anerkendelser på forbrugersiden
• ha-promote-on-failure=when-synced, hvis udgiverne kan prøve igen senere, og hvis du har meget pålidelig lagerplads! Ellers sat =always.
• ha-sync-mode=automatic (men for store inaktive køer kan manuel tilstand være påkrævet; overvej også, om utilgængelighed vil medføre, at meddelelser går tabt)
• Sæt minoritetstilstand på pause
• vedvarende beskeder

Vi har ikke dækket alle spørgsmålene om fejltolerance og høj tilgængelighed endnu; for eksempel hvordan man sikkert udfører administrative procedurer (såsom rullende opdateringer). Vi skal også tale om føderation og Shovel-plugin.

Hvis jeg har overset noget andet, så lad mig det vide.

Se også min indlæg, hvor jeg udfører en kaos på en RabbitMQ-klynge ved hjælp af Docker og Blockade for at teste nogle af de meddelelsestabsscenarier, der er beskrevet i denne artikel.

Tidligere artikler i serien:
nr. 1 - habr.com/ru/company/itsumma/blog/416629
nr. 2 - habr.com/ru/company/itsumma/blog/418389
nr. 3 - habr.com/ru/company/itsumma/blog/437446

Kilde: www.habr.com