Reactive Programming: Difference between revisions
| Line 9: | Line 9: | ||
The underlying principles of reactive applications inform overall system design. | The underlying principles of reactive applications inform overall system design. | ||
Message-driven runtime. One of the key elements to reactive programming is being able to execute tasks asynchronously. Reactive runtimes use an event loop or a shared dispatcher infrastructure based on a thread pool. This allows sharing threads, which are expensive resources, among cheaper constructs: actors. It can be seen as a multiplexing technique. This approach allows for a pattern where we can afford to have one actor per a specific entity in the system, where entities can be quite large in number. <font color=darkgray>State synchronization issue.</font> Reactive applications must avoid blocking the event loop, thus making a specific thread (which can sometimes be the only thread in the system) unavailable. When a reactive application performs such an operation, the thread must be given back to the pool so it can be allocated to other "actors". In this context, blocking is not evil, but needs careful management. | Message-driven runtime. One of the key elements to reactive programming is being able to execute tasks asynchronously. Reactive runtimes use an event loop or a shared dispatcher infrastructure based on a thread pool. This allows sharing threads, which are expensive resources, among cheaper constructs: actors. It can be seen as a multiplexing technique. This approach allows for a pattern where we can afford to have one actor per a specific entity in the system, where entities can be quite large in number. <font color=darkgray>State synchronization issue.</font> Reactive applications must avoid blocking the event loop, thus making a specific thread (which can sometimes be the only thread in the system) unavailable. When a reactive application performs such an operation, the thread must be given back to the pool so it can be allocated to other "actors". In this context, blocking is not evil, but needs careful management. Reactive [[#Framework|frameworks]] deal with this issue by isolating the blocking behavior on a different thread pool, that is dedicated for such operations. This technique is called "sandboxing" or "bulkheading". | ||
Programming model. | Programming model. | ||
Revision as of 20:00, 20 July 2018
Internal
Overview
The underlying principles of reactive applications inform overall system design.
Message-driven runtime. One of the key elements to reactive programming is being able to execute tasks asynchronously. Reactive runtimes use an event loop or a shared dispatcher infrastructure based on a thread pool. This allows sharing threads, which are expensive resources, among cheaper constructs: actors. It can be seen as a multiplexing technique. This approach allows for a pattern where we can afford to have one actor per a specific entity in the system, where entities can be quite large in number. State synchronization issue. Reactive applications must avoid blocking the event loop, thus making a specific thread (which can sometimes be the only thread in the system) unavailable. When a reactive application performs such an operation, the thread must be given back to the pool so it can be allocated to other "actors". In this context, blocking is not evil, but needs careful management. Reactive frameworks deal with this issue by isolating the blocking behavior on a different thread pool, that is dedicated for such operations. This technique is called "sandboxing" or "bulkheading".
Programming model.
Resource utilization. Responsiveness is achieved by efficiently using the hardware. Better resource utilization is a component of scalability.
Decoupling promotes scale-out, as various components can be scaled independently. Asynchronous communication is key to achieve decoupling. It separates the lifecycle of the request initiator from the lifecycle of the request target.
Reactive streams.
Same reactive principles apply to the local (application) level of the system and to the distributed system, allowing composing a distributed system from reactive building blocks from bottom up.
In the academic world, "reactive" stands for "functional reactive programming" (FPR), or "functional reactive activation". This technique is very useful for reactive systems.
Reactive System Tenets according to the Reactive Manifesto
- Responsiveness refers to the capability of the system to be consistently responsive to the user and never fail; it refers to the value brought by such systems.
- Resilience is the capability of the system to self-heal, and refers to form in which reactive systems are delivered.
- Elasticity is the capability of the system to scale out and up/ in and down across physical and cloud infrastructure refers to form in which reactive systems are delivered.
- Message-driven refers to the means used to implement reactive systems. A message-driven system is powered by means of asynchronous, non-blocking communication. This enables first and foremost isolation.
Frameworks
Companies
TODO
- The Reactive Manifesto http://www.reactivemanifesto.org
- https://developers.redhat.com/blog/2017/06/30/5-things-to-know-about-reactive-programming
- ReactiveX http://reactivex.io
- https://github.com/ReactiveX/RxJava
- https://blog.takipi.com/reactive-streams-and-the-weird-case-of-back-pressure/
- http://www.reactive-streams.org
- RSocket - steaming message protocol with reactive extension/stream semantics https://github.com/rsocket/rsocket/blob/master/Motivations.md