welk Schotpatroon wordt door Hystrix gebruikt?

in het algemeen is het doel van het schotpatroon het voorkomen van storingen in een deel van een systeem om het gehele systeem uit te schakelen. De term komt van schepen waar een schip is verdeeld in aparte waterdichte compartimenten om te voorkomen dat een enkelwandige bres het hele schip overstroomt; het zal slechts één schot onder water laten.

implementaties van het schottenpatroon kunnen vele vormen aannemen, afhankelijk van het soort fouten waartegen u het systeem wilt beschermen. In dit antwoord zal ik alleen ingaan op het type fouten dat Hystrix hanteert.

Ik denk dat het schot patroon werd gepopulariseerd door het boek Release It! door Michael T. Nygard.

wat Hystrix oplost

de implementatie van het schot in Hystrix beperkt het aantal gelijktijdige aanroepen van een component. Op deze manier is het aantal bronnen (meestal threads) dat wacht op een antwoord van de component beperkt.

stel dat u een op verzoek gebaseerde toepassing met meerdere threads hebt (bijvoorbeeld een typische webtoepassing) die drie verschillende componenten gebruikt, A, B en C. Als aanvragen voor component C begint te hangen, zullen uiteindelijk alle verzoeken behandelen threads blijven hangen in afwachting van een antwoord van C. Dit zou de toepassing volledig niet-responsief maken. Als verzoeken aan C langzaam wordt behandeld hebben we een soortgelijk probleem als de belasting hoog genoeg is.

Hystrix ‘ implementatie van het schottenpatroon beperkt het aantal gelijktijdige aanroepen naar een component en zou de toepassing in dit geval hebben opgeslagen. Stel dat we 30 verzoeken behandelen threads en er is een limiet van 10 gelijktijdige gesprekken naar C. De andere 20 threads kunnen nog steeds verzoeken behandelen en componenten A en B gebruiken.

hystrix ‘benaderingen

Hystrix’ heeft twee verschillende benaderingen van het schot, thread isolatie en semafoor isolatie.

Thread isolatie

de standaardbenadering is om alle aanvragen aan component C te overhandigen aan een aparte thread pool met een vast aantal threads en geen (of een kleine) aanvraagwachtrij.

Semafoorisolatie

de andere benadering is om alle bellers een vergunning (met 0 time-out) te laten verkrijgen voordat ze een aanvraag indienen bij C. Als een vergunning niet kan worden verkregen van de semafoor, worden oproepen naar C niet doorgegeven.

verschillen

het voordeel van de thread pool benadering is dat verzoeken die aan C worden doorgegeven, kunnen worden getimed, iets dat niet mogelijk is bij het gebruik van semaforen.

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd.