Akka Stream Document translation: Motivation

Want to get Akka http, used for our open source project football, found Akka http in the case of a large number of Akka stream, and Akka HTTP is built on the Akka stream.

So let's take a look at Akka stream first to understand the motive behind this Akka stream project.

Motive Motivation

The-the-consume services from the Internet today includes many instances of streaming data, both down-loading from a s Ervice as well as uploading to it or peer-to-peer data transfers. Regarding data as a stream of elements instead of in it entirety is very useful because it matches the the-the-computers send and receive them (for example via TCP), but it's often also a necessity because data sets frequently become too large to Be handled as a whole. We spread computations or analyses over large clusters and call it "big Data", where the whole principle of processing the M is by feeding those data sequentially-as a stream-through some CPUs.

The way we get services from the Internet today includes a lot of streaming data, such as downloading, uploading, or peer to peer data transfer. It is more useful to think of the data as a stream of elements (i.e., the whole component) rather than as a whole, because it conforms to the way the computer actually handles it (for example, via TCP), but often this is also necessary because the datasets are often too large to be treated as a whole. We distribute computation and analysis into a large cluster called "Big Data", and its processing principle is to provide the data sequentially (as a stream) to some CPUs

Actors can seen as dealing with streams as Well:they send and receive series of messages in order to transfer KNOWLEDG E (or data) from one place to another. We have found it tedious and error-prone to implement all the proper measures in order to achieve stable streaming between Actors, since in addition to sending and receiving we also need to take care to not overflow any buffers or mailboxes in The process. Another pitfall is, the Actor messages can be lost and must being retransmitted in, case lest the stream has holes on th E receiving side. When dealing with streams of elements of a fixed given type, Actors also does not currently offer good static guarantees tha T wiring errors is made:type-safety could be improved in this case.

It can also be argued that the actor is also dealing with streams: They receive messages, send messages, and transfer knowledge (or data) from one place to another. We found that it was cumbersome and error-prone to use the proper implementation to construct a stable stream between actors, because in addition to receiving and sending, we had to make sure that buffers and mailbox (actor mailbox) were not overrun. Another pitfall is that the actor message may be lost, so a retransmission is required to avoid a vulnerability at the receiving end of the stream. Some of the flow elements are a given type, and in dealing with this situation, the actor does not provide a good static guarantee (referring to compiler type checking) to ensure that there is no change in interleaving errors (that should refer to the weaving of message flows), in which case type safety can be improved.

This paragraph illustrates the motive for designing the Akka stream:

1. Make sure that the buffer that the stream passes through does not overflow (you can think of mailbox as the actor's message buffer)

2. Guarantee the reliability of message delivery, providing message delivery semantics above at-least-once.

3. Provides type safety when handling a given stream of element types.

These problems are a very central issue in the construction of an actor system. In particular, the first two, the structure of the actor system when it is necessary to use a very cumbersome means to achieve. Actor system problems, you can refer to this article

　　Why I Don ' t like Akka Actors

)

For these reasons we decided to bundles up a solution to these problems as an Akka Streams API. The purpose is to offer an intuitive and safe-to-formulate stream processing setups such that we can then execute them Efficiently and with bounded resource usage-no more outofmemoryerrors. In order to achieve this we streams need to is able to limit the buffering that they employ, they need to being able to slow Down producers if the consumers cannot keep up. This feature are called Back-pressure and are at the core of the reactive STREAMS initiative of which Akka are a founding mem ber. For your This means, the hard problem of propagating and reacting to back-pressure have been incorporated in the design of Akka Streams already, so you had one less thing to worry about; It also means that Akka Streams interoperate seamlessly with all other reactive STREAMS implementations (where reactive St Reams interfaces define the interoperability SPI while implementations like Akka Streams offer a nice User API) . 

For these reasons, we want to package the solution into the Akka Stream API. The goal is to provide an intuitive and secure way to design the flow process so that we can execute them efficiently and use bounded resource consumption-no more outofmemoryerrors. To achieve this, our flows need to be able to limit the size of the buffers they use, and we need to be able to slow down the producers when consumers can't keep up with the producers. This feature is called back pressure (Back-pressure), which is the core proposition of reactive streams, and Akka is the founding member of reactive streams. For you this means that the issue of delivery and response to Back-pressure has been incorporated into the design of Akka stream, so you may have one less worry, which also means that akka streams can be seamlessly implemented with other reactive streams ( The reactive streams interface defines interoperable service Provider Interface, and implementations like Akka provide a good user API for interoperability.

Reactive streams looks very NB, there are more than 500 stars on GitHub .

Akka Stream Document translation: Motivation