In generale, l’obiettivo del modello di paratia è quello di evitare guasti in una parte di un sistema per abbattere l’intero sistema. Il termine deriva da navi in cui una nave è divisa in compartimenti stagni separati per evitare una breccia a scafo singolo per inondare l’intera nave; inonderà solo una paratia.

Le implementazioni del modello di paratia possono assumere molte forme a seconda del tipo di difetti da cui si desidera proteggere il sistema. Discuterò solo il tipo di errori che Hystrix gestisce in questa risposta.

Penso che il modello paratia è stato reso popolare dal libro Rilasciarlo! di Michael T. Nygard.

Cosa risolve Hystrix

L’implementazione della paratia in Hystrix limita il numero di chiamate simultanee a un componente. In questo modo, il numero di risorse (in genere thread) che è in attesa di una risposta dal componente è limitato.

Si supponga di avere un’applicazione multi thread basata su richiesta (ad esempio una tipica applicazione Web) che utilizza tre componenti diversi, A, B e C. Se le richieste al componente C iniziano a bloccarsi, alla fine tutti i thread di gestione delle richieste si bloccheranno in attesa di una risposta da C. Ciò renderebbe l’applicazione completamente non reattiva. Se le richieste a C vengono gestite lentamente, abbiamo un problema simile se il carico è abbastanza alto.

L’implementazione di Hystrix del modello paratia limita il numero di chiamate simultanee a un componente e avrebbe salvato l’applicazione in questo caso. Supponiamo di avere 30 thread di gestione delle richieste e c’è un limite di 10 chiamate simultanee a C. Quindi al massimo 10 thread di gestione delle richieste possono bloccarsi quando si chiama C, gli altri 20 thread possono ancora gestire le richieste e utilizzare i componenti A e B.

Hystrix’ approaches

Hystrix’ ha due diversi approcci alla paratia, isolamento del thread e isolamento del semaforo.

Isolamento thread

L’approccio standard consiste nel consegnare tutte le richieste al componente C a un pool di thread separato con un numero fisso di thread e nessuna coda di richieste (o una piccola).

Semaphore Isolation

L’altro approccio è quello di far acquisire a tutti i chiamanti un permesso (con 0 timeout) prima delle richieste a C. Se un permesso non può essere acquisito dal semaforo, le chiamate a C non vengono passate.

Differenze

Il vantaggio dell’approccio del pool di thread è che le richieste passate a C possono essere scadute, cosa che non è possibile quando si usano i semafori.