Quelles sont les fonctions du composant déclassé de Java, Hystrix ?

1. Intervieweur : Pouvez-vous présenter brièvement les fonctions d'Hystrix ?

Analyse des problèmes : comprenez les fonctions d'Hystrix et inspirez-vous également de la conception architecturale des excellents concepts de conception d'Hystrix.

Réponse : Je l'ai utilisé dans le projet. Sous la protection d'Hystrix, le système peut être dans un état de haute disponibilité pendant une longue période. Les fonctions couramment utilisées sont les suivantes :

1.1, fail-fast (échec rapide). )

Hystrix est en cours de conception. Fournit des mécanismes de défaillance rapide (échec rapide) et de récupération rapide.

Astuce : je ne sais pas si vous avez déjà compris le mécanisme d'échec rapide, ou si lors de votre entretien sur les bases de Java, l'itérateur de HashMap est conçu pour être rapide, **échec rapide (échec—rapide) ** Il s'agit d'un mécanisme dans les collections Java. Lors de l'utilisation d'un itérateur pour parcourir un objet de collection, si le contenu de l'objet de collection est modifié (ajouté, supprimé, modifié) pendant le processus de traversée, une exception de modification simultanée sera levée.

La première fois que j'ai appris HashMap, je ne connaissais pas grand-chose au fail-fast. Je pensais que le fast fail n'était appliqué que dans les classes de collection Java pour empêcher les opérations simultanées des collections Java non thread-safe. il s'est avéré que le mécanisme d'échec rapide peut également être appliqué dans la conception de l'architecture du système, les demandes qui ne peuvent pas être traitées à temps échoueront rapidement (fail-fast) pour réduire la charge du système au lieu de faire la queue.

1.2. Mécanisme de dégradation gracieuse du Fallback

Fallback signifie littéralement repartir en arrière lorsque je rencontre une chute. Après avoir découvert le mécanisme du Fallback, je l'ai immédiatement utilisé dans le projet.

Regardez un exemple réel :

 @Override
    @Degrade(key = "getOrderByParamFromES", fallBackMethod = "getOrderByParamFromMysql")
    public OrderResult getOrderByParamFromES(OrderSearchParam param) {
        //走ES查询
        ......
        return OrderResult;
    }
 		//fallBack后调用getOrderByParamFromMysql方法
 		public OrderResult getOrderByParamFromMysql(OrderSearchParam param) {
        //走mysql查询
        ......
        return OrderResult;
    }

Explication du code :

fallBackMethod = "getOrderByParamFromMysql"

Autrement dit, après l'échec de la requête ES, le système rétrograde automatiquement la méthode getOrderByParamFromMysql et utilise la requête mysql dans des circonstances normales. , getOrderByParamFromMysql ne sera pas appelé sauf en automne.

1.3. Mécanisme d'isolation des threads/sémaphores

Isolation des threads :

La requête obtiendra l'exécution du thread dans le pool de threads correspondant en fonction de sa propre clé et définira dynamiquement les paramètres du pool de threads, de manière à isoler naturellement les différentes requêtes, Prise en charge asynchrone pour améliorer les performances de l'interface. Différentes requêtes n'ont pas d'impact direct.Par exemple, les requêtes service1 sont lentes, mais service2 et service3 peuvent toujours fonctionner normalement.L'inconvénient est que le changement de thread affecte les performances.

Isolement du sémaphore :

Service1, service2 et service3 sont accessibles en une seule requête. Si la requête service1 expire, l'intégralité du sémaphore ne sera pas libéré et les autres requêtes ne seront pas acceptées.

Pour les requêtes avec une faible latence (comme l'accès au cache ou l'accès local à la base de données), la surcharge provoquée par le pool de threads est très élevée. Vous pouvez envisager d'utiliser d'autres méthodes, comme les sémaphores non bloquants (ne prennent pas en charge les délais d'attente). ) pour implémenter les dépendances Isolation des services. Mais dans la plupart des cas, Netflix préfère utiliser des pools de threads pour isoler les services dépendants, car la surcharge supplémentaire que cela entraîne est acceptable et peut prendre en charge toutes les fonctions, y compris les délais d'attente.

2. Intervieweur : Je viens de mentionner l'isolation des threads. En utilisation réelle, le commutateur d'interruption du thread d'expiration est-il activé ?

Analyse du problème : sur la base de l'expérience d'utilisation réelle, selon les caractéristiques du thread lui-même, le thread expire et s'il n'est pas interrompu à temps, les ressources du thread seront gaspillées.

Réponse : dans des circonstances normales, nous activerons le commutateur d'interruption de délai d'attente afin de libérer les ressources du thread à temps.

Défini par hystrix.command.default.execution.isolation.thread.interruptOnTimeout = true.

Mais si vous écrivez des commandes de base de données ou enregistrez des commandes de journal de touches, vous devez désactiver l'interruption de délai d'attente si vous devez terminer l'exécution de la commande.

(L'intervieweur a hoché la tête avec satisfaction, estimant que j'ai une expérience en maintenance Hystrix)

3. Intervieweur : Comment avez-vous estimé la taille du pool de threads ?

Réponse : Pour définir correctement la taille du pool de threads, vous devez analyser le nombre de processeurs, la taille de la mémoire et le type de tâche (à forte intensité de calcul, à forte intensité d'E/S, etc.) du système déployé. Pour les tâches, la taille du pool de threads est similaire au nombre de processeurs. Généralement, l'utilisation optimale peut être obtenue pour les tâches gourmandes en E/S, la formule de calcul de la taille optimale du pool de threads est la suivante : taille du pool de threads = nombre de processeurs * (. 1 + temps d'attente des tâches / temps de traitement des tâches).

Analyse approfondie

Historique d'Hystrix

Hystrix est née d'un projet lancé par l'équipe API Netflix en 2011. En 2012, Hystrix continue d’évoluer et de mûrir, et de nombreuses équipes au sein de Netflix l’adoptent. Aujourd’hui, des dizaines de milliards d’appels isolés par thread et des centaines de milliards d’appels isolés par sémaphore sont effectués chaque jour sur Netflix via Hystrix. Cela améliore considérablement la disponibilité et la résilience.

En cas d'accès simultané élevé, la stabilité des services sur lesquels s'appuie le système a un impact important sur le système. Les dépendances sont causées par de nombreux facteurs incontrôlables, tels que des connexions réseau lentes, des ressources soudainement occupées, une indisponibilité temporaire et un service hors ligne. Si nous voulons construire un système distribué stable et fiable, nous devons disposer d’une telle méthode tolérante aux pannes.

Hystrix的主要功能特性

熔断器机制：熔断器可以理解成保险丝，项目里使用Hystrix Command，当 Hystrix Command请求后，如果服务失败数量超过一定比例(比如默认50%)，断路器自动熔断，该服务将进入熔断状态，后续请求都会进入fallback。

降级机制：通过fallbackMethod注解，当请求后端服务出现异常的时候, 为了避免影响到其他业务逻辑，可以使用fallback方法指定的方法快速返回，或启用“备胎方案”。

环境隔离：包括线程隔离和信号量隔离。

cache：Hystrix支持将一个请求结果缓存起来，下一个具有相同key的请求将直接从缓存中取出结果，减少请求开销。

Hystrix Demo

通过一个demo快速理解Hystrix fallback 的使用

@Service
public class OrderQueryService {
     /**
     * 订单查询接口
     */
    @HystrixCommand(fallbackMethod = "queryOrderBack")
    public List<Order> queryOrderFromRedis(String userId) {
      // todo  reids查询逻辑
      return orderlist;
    }
     /**
     * 订单查询接口失败降级方案
     */
    @SuppressWarnings("unused")
    private String queryOrderBack(String userId) {
      // todo  如，走ES查询逻辑  或者 直接提示用户“请稍后再试”
      // todo 通知维护人员处理故障
      return "";
    }
}

代码解释:

程序正常时，查询订单服务是走queryOrderFromRedis方法的逻辑，当queryOrderFromRedis方法抛出异常，根据设定的异常比例，或者指定哪个异常，达到阈值触法fallback开关，程序切换到queryOrderBack，设置程序走ES查询逻辑 或者 直接提示用户“请稍后再试”，根据业务自行设置。

哪些情况下会触发fallback？

FAILURE：任意RuntimeException异常都可以激活fallback。

THREAD_POOL_REJECTED：并发执行的任务数超过线程池和队列之和时，也就是Hystrix的线程隔离机制。

SEMAPHORE_REJECTED：类似 THREAD_POOL_REJECTED ，当服务的并发数大于信号量阈值时将进入fallback。比如配置程序执行并发数不能大于3，由于信号量隔离下无论调用哪种命令执行方法，Hystrix都不会创建新线程执行run()/construct()，所以调用程序需要自己创建多个线程来模拟并发调用execute()，最后看到一旦并发线程>3，后续请求都进入fallback。

SHORT_CIRCUITED：在一定时间内，用户请求超过一定的比例失败时，如超时，异常，线程并发达到限定最大值等，断路器都会打开；短路器打开后所有请求直接走fallback，可以通过。circuitBreakerErrorThresholdPercentage方法设置百分比，默认是50。

TIMEOUT：即超时请求。

附录：Hystrix策略配置

/* --------------统计相关------------------*/ 
// 统计滚动的时间窗口,默认:5000毫秒（取自circuitBreakerSleepWindowInMilliseconds）   
private final HystrixProperty metricsRollingStatisticalWindowInMilliseconds;   
// 统计窗口的Buckets的数量,默认:10个,每秒一个Buckets统计   
private final HystrixProperty metricsRollingStatisticalWindowBuckets; // number of buckets in the statisticalWindow   
// 是否开启监控统计功能,默认:true   
private final HystrixProperty metricsRollingPercentileEnabled;   
/* --------------熔断器相关------------------*/ 
// 熔断器在整个统计时间内是否开启的阀值，默认20。也就是在metricsRollingStatisticalWindowInMilliseconds（默认10s）内至少请求20次，熔断器才发挥起作用   
private final HystrixProperty circuitBreakerRequestVolumeThreshold;   
// 熔断时间窗口，默认:5秒.熔断器中断请求5秒后会进入半打开状态,放下一个请求进来重试，如果该请求成功就关闭熔断器，否则继续等待一个熔断时间窗口
private final HystrixProperty circuitBreakerSleepWindowInMilliseconds;   
//是否启用熔断器,默认true. 启动   
private final HystrixProperty circuitBreakerEnabled;   
//默认:50%。当出错率超过50%后熔断器启动
private final HystrixProperty circuitBreakerErrorThresholdPercentage;  
//是否强制开启熔断器阻断所有请求,默认:false,不开启。置为true时，所有请求都将被拒绝，直接到fallback 
private final HystrixProperty circuitBreakerForceOpen;   
//是否允许熔断器忽略错误,默认false, 不开启   
private final HystrixProperty circuitBreakerForceClosed; 
/* --------------信号量相关------------------*/ 
//使用信号量隔离时，命令调用最大的并发数,默认:10   
private final HystrixProperty executionIsolationSemaphoreMaxConcurrentRequests;   
//使用信号量隔离时，命令fallback(降级)调用最大的并发数,默认:10   
private final HystrixProperty fallbackIsolationSemaphoreMaxConcurrentRequests; 
/* --------------其他------------------*/ 
//使用命令调用隔离方式,默认:采用线程隔离,ExecutionIsolationStrategy.THREAD   
private final HystrixProperty executionIsolationStrategy;   
//使用线程隔离时，调用超时时间，默认:1秒   
private final HystrixProperty executionIsolationThreadTimeoutInMilliseconds;   
//线程池的key,用于决定命令在哪个线程池执行   
private final HystrixProperty executionIsolationThreadPoolKeyOverride;   
//是否开启fallback降级策略 默认:true   
private final HystrixProperty fallbackEnabled;   
// 使用线程隔离时，是否对命令执行超时的线程调用中断（Thread.interrupt()）操作.默认:true   
private final HystrixProperty executionIsolationThreadInterruptOnTimeout; 
// 是否开启请求日志,默认:true   
private final HystrixProperty requestLogEnabled;   
//是否开启请求缓存,默认:true   
private final HystrixProperty requestCacheEnabled; // Whether request caching is enabled
//请求合并是允许的最大请求数,默认: Integer.MAX_VALUE   
private final HystrixProperty maxRequestsInBatch;   
//批处理过程中每个命令延迟的时间,默认:10毫秒   
private final HystrixProperty timerDelayInMilliseconds;   
//批处理过程中是否开启请求缓存,默认:开启   
private final HystrixProperty requestCacheEnabled; 
/* 配置线程池大小,默认值10个 */ 
private final HystrixProperty corePoolSize; 
/* 配置线程值等待队列长度,默认值:-1 建议值:-1表示不等待直接拒绝,测试表明线程池使用直接决绝策略+ 合适大小的非回缩线程池效率最高.所以不建议修改此值。 当使用非回缩线程池时，queueSizeRejectionThreshold,keepAliveTimeMinutes 参数无效 */
private final HystrixProperty maxQueueSize;

其他常用限流降级组件

Sentinel：阿里巴巴集团内部基础技术模块，覆盖了所有的核心场景。Sentinel 也因此积累了大量的流量归整场景以及生产实践。2018 年，Sentinel 开源，并持续演进。

Resilience4j：也是一个轻量级的容错组件，其灵感来自于 Hystrix，但主要为 Java 8 和函数式编程所设计。轻量级体现在其只用 Vavr库（前身是 Javaslang），没有任何外部依赖。而 Hystrix 依赖了 Archaius ，Archaius 本身又依赖很多第三方包，例如 Guava、Apache Commons Configuration 等。

Sentinel 与 Hystrix resilience4j 对比

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!