Introduction to the

A programming paradigm for data flow and change propagation. Static or dynamic data flows can be easily expressed programmatically, and the associated computational model automatically propagates the changing values through the data flow. Originally proposed as a way to simplify the creation of interactive user interfaces and the drawing of real-time system animations, it is essentially a general programming paradigm.

Reactive Streams refers to a specification, and to Java developers, Reactive Streams is an API that allows us to do Reactive programming.

At the core of the Reactive model are threads and message pipes. Threads are used to listen for events, and message pipes are used to communicate different messages between threads.

Declaration of reaction

www.reactivemanifesto.org/zh-CN

Four key attributes of reactive systems are described: Responsive, Resilient, Elastic and Message Driven.

  • The system is Responsive whenever possible. In addition to being a cornerstone of system usability, sensitivity also means that system problems can be detected and resolved quickly. Sensitive systems focus on responding quickly and consistently, providing reliable and consistent quality of service.

  • Resilient: In the event of a failure, the system remains responsive. A non-recoverable system becomes unresponsive once it fails. Recoverability can be achieved through replication, containment, isolation, and delegation. In a recoverable system, faults are contained within each component, which is isolated from each other, allowing some parts of the system to fail and recover without bringing down the entire system.

  • Elastic: The system remains responsive under different workloads. The system can dynamically increase or decrease the resources used by the system depending on the input workload. This means that the system can be designed to dynamically apply for system resources and carry out load balancing through fragmentation and replication, so as to decentralize and avoid node bottlenecks.

  • Message Driven: Reactive systems rely on asynchronous messaging mechanisms to establish boundaries between components that guarantee loose coupling, isolation, location transparency, and provide a means to delegate failures in the form of messages.

  • Failures at Messages: In Reactive programming, we usually have to deal with streams of information, and the last thing you want is to throw an exception and have your operations aborted. The ideal solution would be for us to write down the error and then start performing some sort of retry or restore logic. In Reactive Streams, exceptions are first-class citizens, they are not thrown rudely, and error handling is formally built into the Specification of the Reactive Streams API.

  • Back-pressure: When the consumption power of the consumer side cannot keep up with the production speed of the production side, the downstream consumer of the message flow tells the upstream producer: “I’m full, please slow down”. In the world of Reactive, we want downstream consumers to have some mechanism to request a certain number of messages to consume on demand (this is similar to the concept of pull in message queues). Rather than pouring a large number of messages upstream to downstream consumers and then throttling is done programmatically rather than blocking threads.

  • Non-blocking: Data processing is processed in a non-blocking manner and the thread does not get stuck waiting for other processing. Compare a Node.js Server with a non-blocking event loop (such as a highway) to a traditional Java multi-threaded service (such as an intersection with traffic lights)