En général, l’objectif du modèle de cloison est d’éviter les défauts dans une partie d’un système pour abattre l’ensemble du système. Le terme vient des navires où un navire est divisé en compartiments étanches séparés pour éviter une brèche à coque unique pour inonder tout le navire; il n’inondera qu’une seule cloison.

Les implémentations du modèle de cloison peuvent prendre de nombreuses formes en fonction du type de défauts contre lesquels vous souhaitez protéger le système. Je ne discuterai que du type de fautes que gère Hystrix dans cette réponse.

Je pense que le modèle de cloison a été popularisé par le livre Release It! par Michael T. Nygard.

Ce que résout Hystrix

L’implémentation de cloison dans Hystrix limite le nombre d’appels simultanés à un composant. De cette façon, le nombre de ressources (généralement des threads) en attente d’une réponse du composant est limité.

Supposons que vous disposez d’une application multithread basée sur des requêtes (par exemple une application Web typique) qui utilise trois composants différents, A, B et C. Si les demandes au composant C commencent à se bloquer, tous les threads de gestion des demandes resteront en attente d’une réponse de C. Cela rendrait l’application entièrement non réactive. Si les requêtes vers C sont traitées lentement, nous avons un problème similaire si la charge est suffisamment élevée.

L’implémentation par Hystrix du modèle de cloison limite le nombre d’appels simultanés à un composant et aurait sauvé l’application dans ce cas. Supposons que nous ayons 30 threads de traitement des demandes et qu’il y ait une limite de 10 appels simultanés à C. Ensuite, au plus 10 threads de gestion des requêtes peuvent se bloquer lors de l’appel de C, les 20 autres threads peuvent toujours gérer les requêtes et utiliser les composants A et B.

Approches d’Hystrix

Hystrix’ a deux approches différentes de la cloison, l’isolation des threads et l’isolation des sémaphores.

Isolation des threads

L’approche standard consiste à transférer toutes les requêtes au composant C à un pool de threads séparé avec un nombre fixe de threads et aucune file d’attente de requêtes (ou une petite file d’attente).

Isolement du sémaphore

L’autre approche consiste à ce que tous les appelants acquièrent un permis (avec un délai d’attente de 0) avant les demandes à C. Si un permis ne peut pas être acquis à partir du sémaphore, les appels vers C ne sont pas transmis.

Différences

L’avantage de l’approche du pool de threads est que les requêtes transmises à C peuvent être expirées, ce qui n’est pas possible lors de l’utilisation de sémaphores.