SpringCloud Hystrix knowledge learning (preventing the avalanche effect)

1. Description of Hystrix
1. Service Avalanche Effect: It is a process in which the unavailability of the service provider leads to the unavailability of the service caller and gradually enlarges the unavailability.

1.A is the service provider, B is the service caller of A, and C and D are the service callers of B. When the unavailability of A causes the unavailability of B, and the unavailability gradually enlarges C and D, the service An avalanche formed.

2. Avalanche reasons:
1) The service provider is unavailable

a. Hardware failure
a1. The server host is down due to hardware damage
a2. The service provider is inaccessible due to network hardware failure

b. Program bug

c. Cache breakdown: cache When the application is restarted, when all caches are cleared, and when a large number of caches are invalid in a short period of time. A large number of cache misses cause requests to hit the backend directly, causing the service provider to run overloaded, causing the service to be unavailable

d. A large number of user requests: in seconds Before the start of the promotion, if the preparation is not sufficient, the user initiates a large number of requests, causing the service provider to become unavailable.

2) Retry to increase traffic

a. User retry: The user keeps refreshing the page because he can't stand the long wait on the interface Even submit the form
b. Code logic retry: There will be a lot of retry logic on the service caller side after service exceptions

3) The service caller is unavailable

a. Resource exhaustion caused by synchronous waiting: When using synchronous calling, a lot of waiting will occur Threads occupy system resources. Once thread resources are exhausted, the services provided by service callers will also be unavailable, resulting in service avalanche effects.

3. Avalanche response strategies:

1) Flow control
a. Gateway current limiting
Because of the high performance of Nginx, the first-tier Internet companies currently use Nginx+Lua gateways for traffic control, and the resulting OpenResty is becoming more and more popular.

b. User interaction current limiting

Specific measures:
a21. The tolerance waiting time. a22 . The
submit button adds a forced waiting time mechanism.

c. Close the retry 2 )

Improve the cache mode
a. Cache preload
b. Service caller downgrades services a. Resource isolation: mainly isolates the thread pool that calls services. b. Classifies dependent services Dependent services are divided into: strongly dependent and if dependent. Unavailability of strongly dependent services will cause the current business to stop, The unavailability of weakly dependent services will not lead to the suspension of the current business. c. The invocation of the unavailable service fails quickly. Generally , the timeout mechanism, the circuit breaker and the downgrade method after the circuit breaker are used to achieve 4. Solutions: 1) Use Hystrix to prevent services Avalanche 2) Netflix's Hystrix is ​​a class library that helps solve timeout processing and fault tolerance when interacting with distributed systems. It also has the ability to protect the system. 3) The design principles of Hystrix include: resource isolation, circuit breakers, and command patterns 2. Examples

@HystrixCommand(fallbackMethod = "findOrderFallback", commandProperties = {
        	//timeoutInMilliseconds When using thread isolation, call timeout time
        	@HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "1000")
	})
	public String findOrder(Long userId,String orderNo) throws InterruptedException {
    		Random random = new Random();
    		sleepRandom = random.nextInt(2000);
    		System.out.println("sleepRandom="+sleepRandom);
    		Thread.sleep(sleepRandom);
    		ConsumerBeehiveUser user = findById(userId);
    		if (user != null) {
        		return user.getUsername() + " order" + orderNo + " found! sleepRandom="+sleepRandom;
    		}
    		return "User does not exist! sleepRandom="+sleepRandom;
	}

	public String findOrderFallback(Long userId, String orderNo) {
    		return "Order search failed! sleepRandom="+sleepRandom;
	}

@SpringBootApplication
	@EnableDiscoveryClient //Enable eureka service
	@EnableFeignClients //Enable feigin annotation
	@EnableCircuitBreaker //开启Hystrix  @EnableCircuitBreaker或@EnableHystrix
	@EnableHystrixDashboard //Enable dashboard graphic monitoring
	public class ConsumerBeehiveApplication {
    		@Bean
    		@LoadBalanced
    		public RestTemplate restTemplate() {
        		//method for calling "provider"
        		return new RestTemplate();
    		}

    		public static void main(String[] args) {
        		SpringApplication.run(ConsumerBeehiveApplication.class, args);
    		}
	}

Command has four ways to get the result:
1. Single result execute
2. Asynchronous result queue
3. Multiple results toObservable/observe (returning the observable emission source)
4. The corresponding fallback can also be set as

the main source of asynchronous and synchronous Hystrix The goal is to protect the application thread, and the fallbacks may also be in the caller thread. Hystrix needs to limit the number of concurrency. When the number is reached, no matter how many fallbacks are no longer running, HystrixRuntimeException is returned directly.