Shulou(Shulou.com)05/31 Report--

This article mainly introduces the knowledge points of Reactive architecture which are related knowledge, the content is detailed and easy to understand, the operation is simple and fast, and has a certain reference value. I believe you will gain something after reading this knowledge point of Reactive architecture. Let's take a look at it.

Reactive and Reactive programming

Reactive direct translation of the meaning of the reaction, reactivity. At first glance, it seems difficult to understand.

For example: in Excel, set the function Sum (value B) on cell C. when you change the value of cell An or cell B, the value of cell C also changes. This kind of behavior is Reactive.

In the field of computer programming, Reactive generally refers to Reactive programming. Refers to an asynchronous programming paradigm (asynchronous programming paradigm) that faces data flows and propagates events.

Let's give you an example:

Public static void main (String [] args) {FluxProcessor publisher = UnicastProcessor.create (); publisher.doOnNext (event-> System.out.println ("receive event:" + event)). Subscribe (); publisher.onNext (1); / / print 'receive event: 1' publisher.onNext (2); / / print 'receive event: 2'}

Code 1

In the above example code (using the Reactor class library), publisher generates a data stream (1d2) and propagates it to the OnNext event, in which lambda responds to the event and outputs the corresponding information. In the above code, the data flow is generated and the lambda is registered / executed in the same thread, but it can also be in different threads.

Note: if the above code execution logic is a little confused, you can temporarily understand lambda as callback.

Reactive Manifesto

You should feel a little bit about Reactive by now, but you are still a little vague about the value of Reactive and what design principles it has. This is the question that Reactive Manifesto has to solve.

Systems built using Reactive have the following characteristics:

Instant responsiveness (Responsive)

Whenever possible, the system will respond in a timely manner. Instant response is the cornerstone of usability and practicality, and more importantly, instant response means that problems can be detected quickly and handled effectively. The immediate response system focuses on providing fast and consistent response time and establishing reliable feedback limits to provide consistent quality of service. This consistent behavior, in turn, simplifies error handling, builds end-user trust, and encourages users to interact further with the system.

Resilience (Resilient)

The system remains responsive in the event of a failure. This applies not only to highly available, mission-critical systems-any system that is not resilient will lose immediate responsiveness after a failure. Resilience is achieved through replication, containment, isolation, and delegation. The spread of failure is contained within each component, isolated from other components, so as to ensure that the failure of one part of the system does not endanger the whole system and can be recovered independently. The recovery of each component is delegated to another (external) component, and high availability can be ensured by replication if necessary. The client of the component is no longer responsible for handling the failure of the component.

Elasticity (Elastic)

The system remains responsive under ever-changing workloads. Reactive systems can respond to rate changes in inputs (loads), such as by increasing or decreasing the resources allocated to serve these inputs (loads). This means that there are no contention points and central bottlenecks in the design, allowing components to be fragmented or copied, and to distribute input (load) between them. By providing relevant real-time performance indicators, reactive systems can support predictive and reactive scaling algorithms. These systems can achieve cost-efficient flexibility on conventional hardware and software platforms.

Message driven (Message Driven)

Reactive systems rely on asynchronous messaging, ensuring clear boundaries between loosely coupled, isolated, and location-transparent components. This boundary also provides a means to delegate failure as a message. With explicit messaging, you can achieve load management, resilience, and flow control by shaping and monitoring message flow queues in the system and applying backpressure if necessary. Using location-transparent messaging as a means of communication makes it possible to manage failures using the same structural components and semantics across clusters or in a single host. Non-blocking communication allows the receiver to consume resources only when active, thus reducing system overhead.

Note:

There are many proper nouns in the above description. You may have some doubts. You can take a look at the explanation of the relevant nouns.

Why a system built using Reactive has the above value, which I'll explain later in the Reactor chapter.

Reactive Stream

After knowing the concept, characteristics and value of Reactive, are there any relevant products or frameworks to help us build Reactive-style systems? In the early days, there are some class libraries (Rxjava 1.x, Rx.Net) that can be used, but the specification is not uniform, so later Netfilx, Pivotal and other companies developed a set of specifications to guide people to implement it (this specification is also inspired by early products), this is the role of Reactive Stream.

Reactive Stream is a standard for asynchronous flow data processing using non-blocking back pressure (backpressure). At present, the same set of semantic specifications have been implemented in JVM and JavaScript languages, and attempts have been made to define network protocols for transmitting reactive data streams on the basis of various transport protocols (TCP, UDP, HTTP and WebSockets) involved in serialization and deserialization.

The purpose of Reactive Streams is to provide a standard for asynchronous stream processing with non-blocking backpressure.

Problem scenarios solved by Reactive Streams

When unexpected data flows are encountered, the availability of the system can still be maintained under controllable resource consumption.

The goal of Reactive Streams

Controls streaming data exchange at an asynchronous boundary. For example, pass one data to another thread or thread pool to ensure that the receiver does not buffer any amount of data. Back pressure (back pressure) is an indispensable feature to solve this kind of scenario.

Scope of application of Reactive Streams specification

This standard only describes the necessary behaviors and entities to achieve asynchronous flow data exchange through backpressure, the minimum interface, such as Publisher, Subscriber below. Reactive Streams only focuses on the transfer of streaming data between these components, and does not pay attention to the assembly, segmentation, transformation and other behaviors of streaming data itself, such as map, zip and other operator. The Reactive Streams specification includes:

Publisher

Generate a data stream (which may contain unlimited data) that Subscriber can consume according to their needs.

Public interface Publisher {public void subscribe (Subscriber

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.