Home Reactive Programming
Post
Cancel

Reactive Programming

❓ Reactive System

응답이 잘 되고, 탄력적이며 유연하고 메시지 기반으로 동작하는 시스템


📜 리액티브 선언문

  • 유연하고, 느슨한 결합을 가지며, 확장성이 있다.
  • 이로 인해 개발 및 변경 사항을 적용하기 쉽다.
  • 장애가 발생하더라도, 간단한 방식으로 해결한다.
  • 높은 응답성을 가지며, 사용자에게 효과적인 상호적 피드백을 제공한다.


🔎 Reactive System 특징

Responsive (응답성)

  • 요청에 대해 시스템은 가능한 즉각적으로 응답해야 한다.

Resilient (탄력성)

  • 장애가 발생하더라도 응답성을 유지한다.

Elastic (유연성)

  • 사용량의 변화에 대해 유연하게 대응한다.

Message Driven (메시지 구동)

  • 탄력성을 유지하기 위해 비동기 메시지 전달에 의존하여 구성 요소 사이에서 경계 형성


❓ Reactive Programming

데이터의 흐름과 변화의 전파에 중점을 둔 프로그래밍 패러다임

  • 기존의 명령형 프로그래밍은 작성한 코드의 순서대로 진행된다.
  • 리액티브 프로그래밍은 데이터의 흐름을 정의하면 데이터의변화 혹은 작업의 종료에 따라 반응하여 진행된다.
  • 데이터 흐름을 따라 하위 로직에 자동으로 변화를 전파할 수 있어야 한다.


📋 Reactive Programming 주요 요소

image https://reactivex.io/

Observable

  • 데이터 스트림
  • 데이터 압축, 방출하는 역할

Observers

  • Observable을 구독하고 방출된 데이터 스트림을 받아서 처리하는 역할

Schedulers

  • 비동기 프로그래밍을 위한 요소
  • Observable과 Observers에게 실행되어야 할 스레드를 알려주는 역할


📊 Marble Diagram

image https://reactivex.io/

Reactive Programming을 통해 발생하는 비동기적인 데이터 흐름을 시간에 따라 시각화한 다이어그램


❓ Reactive Stream

Nonblocking Backrpessure를 이용한 비동기 스트림 처리의 표준

🧐 BackPressure

  • 기존 옵저버 패턴은 Push 방식으로, Publisher가 데이터가 변경될 때마다 데이터 생성
  • BackPressure은 Pull 방식으로, Subscriber가 필요한 만큼만 요청


📱 Reactive Stream을 구성하는 인터페이스

Processor

  • 오퍼레이터 모음

Publisher

  • 데이터를 생성하는 역할

Subscriber

  • 데이터를 구독하고 처리하는 역할

Subscription

  • Subscriber와 Publisher 사이의 데이터가 교환될 수 있도록 연결하는 역할
  • 전달 받을 데이터의 개수를 요청하거나, 구독을 해지 할 수 있다.


❓ Reactor

  • 스프링 리액티브 개발에 사용되는 Reactive Stream의 구현체 중 하나


🎁 Publisher의 구현체

Flux

image https://projectreactor.io/docs/core/release/reference/#flux

  • 비동기 sequence
  • 0 ~ N개의 아이템을 가진다.

Mono

image https://projectreactor.io/docs/core/release/reference/#mono

  • 비동기 item
  • 0 또는 1개의 아이템을 가진다.


🍃 Sequence

변화 가능한 데이터의 흐름

  • Publisher에 의해 publish 되고 Subscriber에 의해 subscription


👮 Schedulers

오퍼레이터를 처리할 스레드를 지정한다.

  • Reactor는 비동기 실행을 강제하지 않기 때문에 스케줄러를 사용하여 스레드를 지정한다.
  • 스케줄러를 설정하지 않으면, 메인 스레드에서 동기적으로 실행

publishOn()

  • 신호 처리 스케줄링
  • next, complete, error 신호 처리 스레드 설정
  • 다음 publishOn을 만날 때까지 같은 스레드에서 동작

subscribeOn()

  • 구독 처리 스케줄링
  • 시퀀스를 실행할 스레드 결정
  • publishOn을 만날 때까지 같은 스레드에서 동작
  • publishOn이 신호를 처리할 스레드를 지정하므로, publishOn 뒤에 오는 subscribeOn은 무시된다.


📊 publishOn() and subscribeOn() Comparison

공통점

스케줄러를 통해 스레드를 분리한다

차이점

publishOn 메서드는 신호, subscribeOn 메서드는 시퀀스를 처리할 스레드 지정
publishOn 메서드가 subscribeOn 메서드보다 우선 순위가 높다.


📒 Schedulers 종류

Immediate

  • 지금 실행 중인 스레드에서 실행

Single

  • 단일 스레드를 생성해 계속 재사용

Parallel

  • Core 개수만큼의 스레드 생성
  • 주로 CPU를 많이 사용하지만 생명주기가 짧은 작업 실행

매번 새로운 스레드를 사용한다.

Elastic

  • 스레드 무한정 생성 @Deprecated

BoundedElastic

  • Default로 Core * 10 만큼의 스레드 생성

우선적으로 스레드 풀에서 놀고 있는 스레드를 사용하고, 없으면 새로 만들어 사용한다.


✨ Reactive Programming 장점

1. 장애가 전파되지 않는다.

  • 장애가 발생한 처리자는 구독한 데이터를 처리할 수 없다.
  • 시퀀스에서 처리되지 않은 데이터는 그대로 흘러간다.

2. 비동기 처리

  • 스케줄러를 이용하여 스레드를 쉽게 사용할 수 있다.

3. 리소스의 효율적인 사용

  • 요청자는 처리자가 작업을 완료하기 전까지 다른 작업을 하거나 리소스를 반납한다.
  • 스레드를 점유하지 않는다.


This post is licensed under CC BY 4.0 by the author.