preface

20181130, Hystrix is no longer maintained, here is the learning record. It was only completed on December 1st, failing to fulfill the promise made in November. My.oschina.net/floor/tweet…

What are Hystrix

Hystrix is a Java class library that provides service fault tolerance protection

Problems encountered

  • The request response time is too long. As a result, resources cannot be released in time. A large amount of requests for a short time depletes resources and causes the system to fail to respond.
  • The fault of one service affects other systems, causing cascading faults.
  • Requests are unconstrained or not batched, and the system slows down and becomes unresponsive (resources may be threads, network connections, memory, etc.)

Hystrix solutions

  • Cancel connection to external service after timeout; Frees system resources and makes system response threads and network usage limited by thread pools and semaphores.
  • When resources consume their constraints, subsequent requests fail instead of queuing
  • Fallback can be used when appropriate in the event of a failure;
  • Batch requests can be used; More efficient use of local and external service resources

The working process

The official workflow flow chart consists of 9 steps as follows, with simple logic.

  1. Create HystrixCommand and HystrixObservableCommand objects
  2. Command execution
  3. Whether there are results in the cache
  4. Whether the circuit breaker is on
  5. Whether the semaphore/thread pool rejects
  6. HystrixObservableCommand. The construct () or HystrixCommand. The run ()
  7. Calculate the health of the circuit breaker
  8. Fallback to deal with
  9. Returns a successful response

Principle of circuit breaker

Its principle is described as follows:

  1. Assume that the request amount reaches a certain threshold (HystrixCommandProperties. CircuitBreakerRequestVolumeThreshold ())
  2. Assuming error percentage points more than the threshold percentage error (HystrixCommandProperties. CircuitBreakerErrorThresholdPercentage ())
  3. Satisfy one, turn on the breaker.
  4. When the short-circuit is open, short-circuit all requests that pass through the short-circuit.
  5. After a period of time (HystrixCommandProperties circuitBreakerSleepWindowInMilliseconds ()), allowing a request through (short circuiter ajar) at this time, if the request is successful, the short circuit is set to open its, Otherwise, set the short-circuit breaker to off and judge from 1.

Depend on the isolation

Hystrix uses “bulkhead mode”. Thread pools are used by default. Create a separate thread pool for each dependent service so that if a dependent service fails, it only affects the invocation of that dependent service and does not drag down other services. As shown below:

  • Benefits of thread pool isolation

  • When the service recovers from the failure, the thread pool is cleaned up and the healthy service is restored immediately, with the container level much fuller.

  • Failure times, delay, timeout, rejection and other indicators will quickly reflect the problem, combined with Spring Cloud can achieve dynamic refresh.

  • Thread pools have a built-in concurrency implementation to build asynchronous access to synchronously dependent services.

Request to merge

Solve the problem of communication occupancy and connection consumption. Combine multiple requests within a very short window of time (default: 10ms) to send requests in a batch manner. Disadvantages:

  • Delay of a single response. If the single response is 5ms and the default time window is 10ms, the response to the request becomes 15ms
  • Users need to implement bulk service and processing, which adds some cost. The request merge diagram is shown below: