[Asac 웹풀스택] 리액트공부

[Asac 웹풀스택] 리액트공부 

 

[백엔드 개발자의 스프링부트 공부노트]  표준 디렉토리 레이아웃 소개

 

공통 디렉토리 레이아웃을 사용하면 하나의 Maven 프로젝트에 익숙한 사용자가 다른 Maven 프로젝트에서 즉시 편안함을 느낄 수 있습니다. 이점은 사이트 전체의 모양과 느낌을 채택하는 것과 유사합니다.

다음 섹션에서는 Maven에서 예상하는 디렉터리 레이아웃과 Maven에서 만든 디렉터리 레이아웃을 설명합니다. 가능한 한 이 구조를 따르도록 노력하십시오. 그러나 그렇게 할 수 없는 경우 프로젝트 설명자를 통해 이러한 설정을 재정의할 수 있습니다.

src/main/java 애플리케이션/라이브러리 소스
src/main/resources 애플리케이션/라이브러리 리소스
src/main/filters 리소스 필터 파일
src/main/webapp 웹 애플리케이션 소스
src/test/java 테스트 소스
src/test/resources 테스트 리소스
src/test/filters 리소스 필터 파일 테스트
src/it 통합 테스트(주로 플러그인용)
src/assembly 어셈블리 설명자
src/site 대지
LICENSE.txt 프로젝트 라이선스
NOTICE.txt 프로젝트가 의존하는 라이브러리에 필요한 알림 및 속성
README.txt 프로젝트의 읽어보기
최상위 수준에서 프로젝트를 설명하는 파일: 파일 pom.xml. 또한 사용자가 소스를 받는 즉시 읽을 수 있는 텍스트 문서가 있습니다: README.txt, LICENSE.txt등.

이 구조에는 두 개의 하위 디렉토리가 있습니다: src및 target. 여기서 예상되는 유일한 다른 디렉토리는 CVS, .git또는 와 같은 메타데이터 .svn및 다중 프로젝트 빌드의 모든 하위 프로젝트(각각 위와 같이 배치됨)입니다.

이 target디렉터리는 빌드의 모든 출력을 저장하는 데 사용됩니다.

디렉토리 src에는 프로젝트, 해당 사이트 등을 구축하기 위한 모든 소스 자료가 포함되어 있습니다. main여기에는 기본 빌드 아티팩트, test단위 테스트 코드 및 리소스 site등 각 유형에 대한 하위 디렉터리가 포함됩니다 .

아티팩트 생성 소스 디렉토리(예: main및 test)에는 언어용 디렉토리 java(일반 패키지 계층 구조가 존재함) 및 디렉토리 resources(기본 리소스 정의가 지정된 대상 클래스 경로에 복사되는 구조)용 디렉토리가 있습니다.

아티팩트 빌드에 기여하는 다른 소스가 있는 경우 다른 하위 디렉토리 아래에 있을 것입니다. 예를 들어 src/main/antlrAntlr 문법 정의 파일을 포함합니다.

 

 

[백엔드 개발자의 스프링부트 공부노트] 리액트, 응답성, 회복력, 메시지 기반

 

리액트: 리액트(React)는 페이스북이 개발한 자바스크립트 라이브러리로, 웹 애플리케이션의 사용자 인터페이스를 구현하는 데 사용됩니다. 컴포넌트 기반의 개발을 통해 코드 재사용성이 높아지며, UI의 변경 사항을 효율적으로 관리할 수 있습니다. 

 

응답성: 응답성(responsiveness)은 웹 애플리케이션에서 사용자의 입력에 신속하게 대응하는 기능을 말합니다. 사용자가 버튼을 클릭하거나 메뉴를 선택할 때 바로 그에 맞는 화면이 뜨거나 결과가 나타나는 것이 응답성이 좋다고 표현합니다. 회복력: 

 

회복력(resilience)은 시스템이 장애나 에러가 발생한 뒤 원래의 상태나 기능으로 복구되는 능력을 말합니다. 장기적인 안정성을 확보하기 위해 고려되어야 하는 요소 중 하나입니다. 탄력성: 탄력성(elasticity)은 시스템이 부하의 변화에 따라 자동으로 리소스를 조절하여 성능을 유지하는 능력을 말합니다. 필요할 때는 리소스를 증가시켜 처리 능력을 높이거나, 부하가 줄어들면 리소스를 축소하여 비용을 절약할 수 있습니다. 

 

메시지 기반: 메시지 기반(message-based)은 컴포넌트끼리 데이터를 전달하는 방식이 메시지를 통해 이루어진다는 것을 의미합니다. 

 

이를 통해 시스템이 분산되어 있거나 서로 다른 기술 스택을 가진 컴포넌트 간에도 상호작용이 가능하게 됩니다. 거시적 수준에서 가용성, 확장성, 성능을 극대화한다: 거시적(macroscopic) 수준에서는 전체 시스템의 가용성, 확장성, 성능을 최적화하는 것을 목표로 합니다. 이를 통해 사용자의 요구에 맞춰 시스템을 안정적으로 운영하고, 큰 규모의 트래픽이 발생하더라도 수용할 수 있는 구조가 되도록 합니다.

 

[백엔드 개발자의 스프링부트 공부노트] 반응성 스트림 논문 주소

 

https://github.com/reactive-streams/reactive-streams-jvm/blob/v1.0.4/README.md 

 

반응성 스트림
Reactive Streams의 목적은 non-blocking backpressure로 비동기 스트림 처리를 위한 표준을 제공하는 것입니다.

최신 릴리스는 Maven Central에서 다음과 같이 사용할 수 있습니다.

<dependency>
  <groupId>org.reactivestreams</groupId>
  <artifactId>reactive-streams</artifactId>
  <version>1.0.4</version>
</dependency>
<dependency>
  <groupId>org.reactivestreams</groupId>
  <artifactId>reactive-streams-tck</artifactId>
  <version>1.0.4</version>
  <scope>test</scope>
</dependency>

 

목표, 설계 및 범위
데이터 스트림, 특히 볼륨이 미리 결정되지 않은 "라이브" 데이터를 처리하려면 비동기식 시스템에서 특별한 주의가 필요합니다. 가장 눈에 띄는 문제는 빠른 데이터 원본이 스트림 대상을 압도하지 않도록 리소스 소비를 신중하게 제어해야 한다는 것입니다. 비동기는 컴퓨팅 리소스의 병렬 사용, 네트워크 호스트 협력 또는 단일 시스템 내의 여러 CPU 코어에서 필요합니다.

Reactive Streams의 주요 목표는 수신측이 임의의 양의 데이터를 버퍼링하도록 강제되지 않도록 하면서 비동기 경계를 넘어 스트림 데이터 교환을 관리하는 것입니다. 즉, 배압은 스레드 사이를 중재하는 큐가 제한될 수 있도록 하기 위해 이 모델의 필수적인 부분입니다. 배압 신호가 동기식( Reactive Manifesto 참조)인 경우 비동기식 처리의 이점이 무효화되므로 Reactive Streams 구현의 모든 측면에서 완전한 비차단 및 비동기식 동작을 요구하도록 주의를 기울였습니다.

이 사양의 의도는 스트림 애플리케이션의 전체 처리 그래프에서 앞서 언급한 이점과 특성을 유지하면서 규칙을 준수함으로써 원활하게 상호 운용할 수 있는 많은 준수 구현을 생성할 수 있도록 하는 것입니다.

스트림 조작(변환, 분할, 병합 등)의 정확한 특성은 이 사양에서 다루지 않는다는 점에 유의해야 합니다. Reactive Streams는 서로 다른 API 구성 요소 간의 데이터 스트림을 중재하는 데에만 관심이 있습니다 . 개발 과정에서 스트림을 결합하는 모든 기본 방법을 표현할 수 있도록 주의를 기울였습니다.

요약하면 Reactive Streams는 JVM을 위한 스트림 지향 라이브러리의 표준 및 사양입니다.

잠재적으로 무한한 수의 요소 처리
순서대로,
구성 요소 간에 요소를 비동기적으로 전달
필수 비 차단 배압.
Reactive Streams 사양은 다음 부분으로 구성됩니다.

API는 Reactive Streams를 구현하고 서로 다른 구현 간의 상호 운용성을 달성하기 위한 유형을 지정합니다.

TCK(Technology Compatibility Kit)는 구현의 적합성 테스트를 위한 표준 테스트 스위트입니다.

구현은 API 요구 사항을 준수하고 TCK의 테스트를 통과하는 한 사양에서 다루지 않는 추가 기능을 자유롭게 구현할 수 있습니다.

API 구성 요소
API는 Reactive Stream 구현에서 제공해야 하는 다음 구성 요소로 구성됩니다.

발행자
구독자
신청
프로세서
게시자 는 잠재적으로 무한한 수의 연속된 요소를 제공하여 구독자로부터 받은 요청에 따라 게시합니다.

Publisher.subscribe(Subscriber)의 메소드에 대한 가능한 호출 순서에 대한 호출에 대한 응답으로 Subscriber다음 프로토콜에 의해 제공됩니다.

onSubscribe onNext* (onError | onComplete)?
즉, 가 onSubscribe항상 신호를 받고, 무한 수의 onNext신호( 에서 요청한 대로 Subscriber) onError와 실패가 있는 경우 신호가 오고 더 이상 사용할 수 있는 요소가 없을 때 신호가 옵니다. 모두 가 취소되지 않는 onComplete한입니다 .Subscription

노트
아래 사양은 https://www.ietf.org/rfc/rfc2119.txt 의 대문자로 된 바인딩 단어를 사용합니다.
용어 사전
용어 정의
신호 명사: , , onSubscribe, onNext또는 방법 중 하나 . 동사로: 신호를 호출/호출.onCompleteonErrorrequest(n)cancel
수요 명사로서 게시자가 아직 전달(이행)하지 않은 구독자가 요청한 요소의 집계된 수입니다. 동사로서 더 많은 요소를 -ing하는 행위 request.
동기식(ly) 호출 스레드에서 실행됩니다.
정상 복귀 선언된 유형의 값만 호출자에게 반환합니다. a에 실패 신호를 보내는 유일한 법적 방법은 메서드를 Subscriber통하는 것입니다 onError.
책임감 대응 준비/능력. 이 문서에서는 서로 다른 구성 요소가 서로의 응답 능력을 손상시키지 않아야 함을 나타내는 데 사용됩니다.
비방해 호출 스레드에서 가능한 한 빨리 실행되는 메서드를 설명하는 품질입니다. 이는 예를 들어 무거운 계산 및 호출자의 실행 스레드를 지연시킬 수 있는 기타 사항을 방지함을 의미합니다.
터미널 상태 발행인의 경우: 언제 onComplete또는 onError신호를 받았습니다. 가입자의 경우: onComplete또는 onError수신되었을 때.
NOP 호출 스레드에 감지할 수 있는 영향이 없고 여러 번 안전하게 호출할 수 있는 실행입니다.
직렬(ly) Signal 의 맥락에서 겹치지 않습니다. JVM의 컨텍스트에서 개체의 메서드에 대한 호출은 이러한 호출 사이에 사전 발생 관계가 있는 경우에만 직렬입니다(호출이 겹치지 않음을 의미함). 호출이 비동기식으로 수행될 때 사전 발생 관계를 설정하기 위한 조정은 원자성, 모니터 또는 잠금과 같은 기술을 사용하여 구현되어야 합니다.
스레드 안전 프로그램 정확성을 보장하기 위해 외부 동기화 없이 동기식 또는 비동기식으로 안전하게 호출할 수 있습니다.
사양
1. 발행인( 코드 )
public interface Publisher<T> {
    public void subscribe(Subscriber<? super T> s);
}

 

ID 규칙
1 a 에서 a로 onNext신호를 보낸 ´ 의 총 수는 항상 해당 ´ 가 요청한 요소의 총 수보다 작거나 같아야 합니다 .PublisherSubscriberSubscriberSubscription

 

💡 이 규칙의 의도는 게시자가 구독자가 요청한 것보다 더 많은 요소를 신호할 수 없음을 분명히 하는 것입니다. 이 규칙에는 암묵적이지만 중요한 결과가 있습니다. 요청은 수신된 후에만 충족될 수 있기 때문에 요청 요소와 수신 요소 사이에는 사전 발생 관계가 있습니다.

 

2 Publisher요청된 것보다 적은 수의 신호가 있을 수 있으며 또는 를 호출하여 onNext종료합니다 .SubscriptiononCompleteonError

 

💡 이 규칙의 의도는 게시자가 요청된 요소 수를 생성할 수 있음을 보장할 수 없음을 분명히 하는 것입니다. 단순히 그것들을 모두 생산할 수 없을 수도 있습니다. 실패한 상태일 수 있습니다. 비어 있거나 이미 완료되었을 수 있습니다.
삼 onSubscribe, onNext, onError및 onComplete에 신호를 보내는 것은 직렬로Subscriber 신호를 보내야 합니다 .

 

💡 이 규칙의 의도는 각 신호 간에 발생 전 관계가 설정되는 경우에만 신호 신호(여러 스레드 포함)를 허용하는 것입니다.

 

 

4 가 Publisher실패하면 에 신호를 보내야 합니다 onError.

 

💡 이 규칙의 의도는 게시자가 진행할 수 없음을 감지한 경우 게시자가 구독자에게 알릴 책임이 있음을 분명히 하기 위한 것입니다. 구독자는 리소스를 정리하거나 게시자의 실패를 처리할 기회를 받아야 합니다.

 

5 가 Publisher성공적으로 종료되면(유한 스트림) 에 신호를 보내야 합니다 onComplete.

 

💡 이 규칙의 목적은 게시자가 구독자에게 최종 상태에 도달했음을 알릴 책임이 있음을 분명히 하는 것입니다. 그러면 구독자는 이 정보에 따라 조치를 취할 수 있습니다. 리소스 정리 등

 

6 a 가 또는 a에서 Publisher신호를 보내면 취소된 것으로 간주해야 합니다 .onErroronCompleteSubscriberSubscriberSubscription

 

💡 이 규칙의 목적은 구독이 취소되었는지, 게시자가 onError 또는 onComplete 신호를 보냈는지에 관계없이 구독이 동일하게 취급되도록 하는 것입니다.

 

7 터미널 상태 가 신호( onError, ) 되면 onComplete더 이상 신호가 발생하지 않는 것이 필요합니다.

 

💡 이 규칙의 의도는 onError 및 onComplete가 게시자와 구독자 쌍 간의 상호 작용의 최종 상태인지 확인하는 것입니다.

 

8 a가 Subscription취소 되면 Subscriber결국 신호를 중지해야 합니다.

 

💡 이 규칙의 목적은 게시자가 Subscription.cancel()이 호출되었을 때 구독을 취소하라는 구독자의 요청을 존중하도록 하는 것입니다. 결국 그 이유는 신호가 비동기화되어 전파 지연을 가질 수 있기 때문입니다.

 

9 Publisher.subscribe다른 모든 신호에 앞서 onSubscribe제공된 를 호출해야 하며 반드시 정상적으로 반환 해야 합니다 . 단, 제공된 경우를 제외 하고 호출자에게 a를 던져야 합니다 . 전화로 (전화 후 ).SubscriberSubscriberSubscribernulljava.lang.NullPointerExceptionSubscriberonErroronSubscribe

 

💡 이 규칙의 의도는 가 onSubscribe항상 다른 신호보다 먼저 신호를 받도록 하여 신호를 수신할 때 구독자가 초기화 논리를 실행할 수 있도록 하는 것입니다. 또한 onSubscribe최대 한 번만 호출해야 합니다[ 2.12 참조 ]. 제공된 Subscriber가 이면 null호출자 외에는 신호를 보낼 다른 곳이 없으므로 a 를 java.lang.NullPointerException던져야 합니다. 가능한 상황의 예: 상태 저장 게시자는 압도당하거나 한정된 수의 기본 리소스에 의해 제한되거나 소진되거나 최종 상태 에 있을 수 있습니다 .
10 Publisher.subscribe원하는 만큼 여러 번 호출될 수 있지만 Subscriber매번 다른 이름으로 호출되어야 합니다[ 2.12 참조 ].

 

💡 이 규칙의 목적은 subscribe일반 게시자와 일반 구독자가 여러 번 연결되는 것을 지원한다고 가정할 수 없음을 호출자가 인식하도록 하는 것입니다. 또한 의 의미 체계는 subscribe호출 횟수에 관계없이 유지되어야 합니다.
11 A Publisher는 여러 Subscribers를 지원할 수 있으며 각각이 Subscription유니캐스트인지 멀티캐스트인지를 결정할 수 있습니다.

 

💡 이 규칙의 의도는 게시자 구현이 지원할 구독자 수와 요소 배포 방법을 결정할 수 있는 유연성을 제공하는 것입니다.

 

2. 가입자( 코드 )
public interface Subscriber<T> {
    public void onSubscribe(Subscription s);
    public void onNext(T t);
    public void onError(Throwable t);
    public void onComplete();
}

 

ID 규칙

 

1 신호를 수신 하려면 반드시 Subscriber신호 ​​요구를 해야 합니다 .Subscription.request(long n)onNext
💡 이 규칙의 의도는 언제 얼마나 많은 요소를 받을 수 있고 기꺼이 받을지 결정하는 것이 가입자의 책임임을 확립하는 것입니다. 재진입 구독 방법으로 인한 신호 재정렬을 방지하기 위해 동기 구독자 구현이 신호 처리의 맨 끝에서 구독 방법을 호출하는 것이 강력히 권장됩니다. 한 번에 하나의 요소만 요청하면 본질적으로 비효율적인 "정지 후 대기" 프로토콜이 발생하므로 가입자가 처리할 수 있는 것의 상한을 요청하는 것이 좋습니다.

 

2 Subscriber신호 처리가 응답성에 부정적인 영향을 미칠 것으로 의심되는 경우 Publisher신호를 비동기식으로 발송하는 것이 좋습니다(RECOMMENDED).
💡 이 규칙의 의도는 구독자가 실행 관점에서 게시자의 진행을 방해해서는 안 된다는 것입니다. 즉, 구독자는 게시자가 CPU 주기를 수신하지 못하게 해서는 안 됩니다.

 

삼 Subscriber.onComplete()에 Subscriber.onError(Throwable t)대한 메서드를 호출해서는 안 됩니다(MUST NOT ) .SubscriptionPublisher
💡 이 규칙의 목적은 완료 신호를 처리하는 동안 Publisher, Subscription 및 Subscriber 사이의 주기 및 경쟁 조건을 방지하는 것입니다.

 

4 Subscriber.onComplete()Subscriber.onError(Throwable t)신호를 수신한 후 구독이 취소된 것으로 간주해야 합니다(MUST) .
💡 이 규칙의 목적은 구독자가 게시자의 최종 상태 신호를 존중하는지 확인하는 것입니다. onComplete 또는 onError 신호를 수신한 후에는 구독이 더 이상 유효하지 않습니다.

 

5 이미 active 가 있는 경우 신호 후에 주어진 을 Subscriber반드시 호출해야 합니다 .Subscription.cancel()SubscriptiononSubscribeSubscription
💡 이 규칙의 목적은 두 개 이상의 개별 게시자가 동일한 구독자와 상호 작용을 시도하지 못하도록 하는 것입니다. 이 규칙을 적용하면 추가 구독이 취소되므로 리소스 누수가 방지됩니다. 이 규칙을 준수하지 않으면 게시자 규칙 1 등을 위반할 수 있습니다. 이러한 위반은 진단하기 어려운 버그로 이어질 수 있습니다.

 

6 더 이상 필요하지 않은 경우 Subscriber반드시 전화해야 합니다 .Subscription.cancel()Subscription
💡 이 규칙의 의도는 구독자가 더 이상 필요하지 않을 때 구독을 그냥 버릴 수 없으며 cancel해당 구독이 보유한 리소스를 안전하고 시기 적절하게 회수할 수 있도록 호출해야 한다는 것을 설정하는 것입니다. 예를 들어 특정 요소에만 관심이 있는 구독자는 게시자에게 완료 신호를 보내기 위해 구독을 취소합니다.

 

7 구독자는 구독의 요청 및 취소 방법에 대한 모든 호출이 순차적으로 수행되도록 해야 합니다 .
💡 이 규칙의 의도는 각 호출 사이에 직렬 관계가 설정된 경우에만 요청 및 취소 메서드(여러 스레드 포함)의 호출을 허용하는 것입니다 .

 

8 A는 여전히 보류 중인 요청 요소가 있는 경우 호출한 후 Subscriber하나 이상의 신호를 수신할 준비가 되어 있어야 합니다 [ 3.12 참조 ]. 기본 정리 작업을 즉시 수행한다고 보장하지 않습니다.onNextSubscription.cancel()Subscription.cancel()
💡 이 규칙의 의도는 호출 cancel과 해당 취소를 관찰하는 게시자 사이에 지연이 있을 수 있음을 강조하는 것입니다.

 

9 A는 선행 호출이 있든 없든 신호를 Subscriber수신할 준비가 되어 있어야 합니다 .onCompleteSubscription.request(long n)
💡 이 규칙의 목적은 완료가 수요 흐름과 관련이 없다는 것을 확립하는 것입니다. 이렇게 하면 스트림이 일찍 완료되고 완료를 위해 폴링할 필요가 없습니다 .

 

10 A는 선행 호출이 있든 없든 신호를 Subscriber수신할 준비가 되어 있어야 합니다 .onErrorSubscription.request(long n)
💡 이 규칙의 의도는 게시자 실패가 신호 수요와 완전히 관련이 없을 수 있음을 확인하는 것입니다. 이는 게시자가 요청을 이행할 수 없는지 확인하기 위해 구독자가 폴링할 필요가 없음을 의미합니다.

 

11 A는 각 신호를 처리하기 전에 해당 신호Subscriber 메서드 에 대한 모든 호출이 발생하는지 확인해야 합니다 . 즉 가입자는 처리 논리에 신호를 적절하게 게시하는 데 주의를 기울여야 합니다.
💡 이 규칙의 의도는 신호의 비동기 처리가 스레드로부터 안전한지 확인하는 것이 구독자 구현의 책임임을 확립하는 것입니다. 섹션 17.4.5에서 Happens-Before의 JMM 정의를 참조하십시오 .

 

12 Subscriber.onSubscribe주어진 객체에 대해 최대 한 번 호출해야 합니다 Subscriber(객체 동등성을 기반으로 함).
💡 이 규칙의 의도는 동일한 가입자가 최대 한 번만 가입할 수 있다고 가정해야 한다는 것을 설정하는 것입니다. 입니다 . object equality_a.equals(b)

 

13 onSubscribe, onNext또는 호출하는 것은 제공된 매개변수가 호출자에게 를 던져야 하는 경우를 제외하고는 정상적으로 반환 해야 합니다 . 다른 모든 상황에서 신호 실패에 대한 유일한 법적 방법 onError은 해당 . 이 규칙을 위반한 경우에 관련된 모든 것이 취소 된 것으로 간주되어야 하며 호출자는 런타임 환경에 적합한 방식으로 이 오류 조건을 제기해야 합니다.onCompletenulljava.lang.NullPointerExceptionSubscriberSubscriptionSubscriptionSubscriber
💡 이 규칙의 의도는 이 규칙을 위반한 경우 게시자가 수행할 수 있는 작업과 구독자의 메서드에 대한 의미 체계를 설정하는 것입니다. «런타임 환경에 적합한 방식으로 이 오류 조건을 발생시키십시오»는 오류를 기록하는 것을 의미할 수 있습니다. 그렇지 않으면 오류가 잘못된 구독자에게 신호를 보낼 수 없기 때문에 다른 사람 또는 무언가가 상황을 인식하게 할 수 있습니다.

 

3. 구독 ( 코드 )
public interface Subscription {
    public void request(long n);
    public void cancel();
}

 

ID 규칙

 

1 Subscription.requestSubscription.cancel컨텍스트 내에서만 호출되어야 합니다 Subscriber.
💡 이 규칙의 목적은 구독이 구독자와 게시자 간의 고유한 관계를 나타내는 것을 설정하는 것입니다[ 2.12 참조 ]. 구독자는 요소가 요청되는 시점과 더 이상 요소가 더 이상 필요하지 않은 시점을 제어합니다.

 

2 가 내부에서 또는 에서 동기적으로 호출할 수 있도록 Subscription허용해야 합니다 .SubscriberSubscription.requestonNextonSubscribe
💡 이 규칙의 의도는 and 사이의 상호 재귀 (그리고 결국 / ) request의 경우 스택 오버플로를 방지하기 위해 구현이 재진입 가능해야 함을 분명히 하는 것입니다 . 이는 게시자가 , 즉 를 호출하는 스레드에서 신호를 보낼 수 있음을 의미합니다 .requestonNextonCompleteonErrorsynchronousonNextrequest

 

삼 Subscription.requestPublisher와 사이의 가능한 동기 재귀에 상한선을 설정해야 합니다(MUST) Subscriber.
💡 이 규칙 의 의도는 and 사이의 상호 재귀에 대한 상한을 지정하여 [ 3.2 참조 ]를 보완하는 것입니다 . 구현은 스택 공간을 보존하기 위해 이 상호 재귀를 깊이(ONE)로 제한하는 것이 좋습니다(RECOMMENDED) . 바람직하지 않은 동기식 개방형 재귀의 예는 Subscriber.onNext -> Subscription.request -> Subscriber.onNext -> …일 것입니다. 그렇지 않으면 호출 스레드의 스택이 날아가기 때문입니다.requestonNextonCompleteonError1

 

4 Subscription.request적시에 반환하여 호출자의 응답성을 존중해야 합니다(SHOULD).
💡 이 규칙의 의도는 비방해request 메서드를 설정하고 호출 스레드에서 가능한 한 빨리 실행되어야 하므로 과도한 계산 및 호출자의 실행 스레드를 지연시키는 기타 사항을 피하는 것입니다. .

 

5 Subscription.cancel적시에 반환하여 호출자의 응답성을 존중해야 하며 멱등적이어야 하고 스레드로부터 안전 해야 합니다(MUST ).
💡 이 규칙의 의도는 비방해cancel 메서드를 설정하고 호출 스레드에서 가능한 한 빨리 실행되어야 하므로 과도한 계산 및 호출자의 실행 스레드를 지연시키는 기타 사항을 피하는 것입니다. . 또한 부작용 없이 여러 번 호출할 수 있는 것도 중요합니다.

 

6 Subscription가 취소된 후 추가는 NOPSubscription.request(long n) 여야 합니다 .
💡 이 규칙의 의도는 구독 취소와 후속 요소 추가 요청 비작동 간의 인과 관계를 설정하는 것입니다.

 

7 Subscription가 취소된 후 추가는 NOPSubscription.cancel() 여야 합니다 .
💡 이 규칙의 의도는 3.5 로 대체됩니다 .

 

8 가 Subscription취소되지 않은 상태에서 Subscription.request(long n)해당 구독자에게 생산할 추가 요소를 주어진 개수만큼 등록해야 합니다.
💡 이 규칙의 의도는 -ing이 추가 작업인지 확인 request하고 요소에 대한 요청이 게시자에게 전달되도록 하는 것입니다.

 

9 Subscription가 취소되지 않은 동안 인수가 <= 0인 경우 Subscription.request(long n)신호를 보내야 합니다 onError. java.lang.IllegalArgumentException원인 메시지는 비양성 요청 신호가 불법임을 설명해야 합니다(SHOULD).
💡 이 규칙의 의도는 잘못된 구현이 예외 없이 작업을 계속 진행하는 것을 방지하는 것입니다. 요청이 추가되기 때문에 음수 또는 0 요소 수를 요청하면 구독자를 대신하여 잘못된 계산의 결과가 될 가능성이 큽니다.

 

10 가 Subscription취소되지 않는 동안 이(또는 다른) 가입자를 Subscription.request(long n)동기적으로 호출할 수 있습니다 .onNext
💡 이 규칙의 의도는 동기 게시자, 즉 호출 스레드에서 논리를 실행하는 게시자를 만들 수 있도록 설정하는 것입니다.

 

11 가 Subscription취소되지 않는 동안 이(또는 다른) 가입자를 동 Subscription.request(long n)기적으로 호출할 수 있습니다 .onCompleteonError
💡 이 규칙의 의도는 동기 게시자, 즉 호출 스레드에서 논리를 실행하는 게시자를 만들 수 있도록 설정하는 것입니다.

 

12 가 Subscription취소되지 않은 동안 에 신호를 보내는 것을 결국 중지하도록 Subscription.cancel()요청해야 합니다(MUST ). 즉시 영향을 미치기 위해 작업이 필요하지 않습니다 .PublisherSubscriberSubscription
💡 이 규칙의 의도는 신호를 수신하기까지 어느 정도 시간이 걸릴 수 있음을 인정하면서 게시자가 구독 취소 의사를 결국 존중하도록 설정하는 것입니다.

 

13 가 Subscription취소되지 않은 동안 해당 구독자에 대한 모든 참조를 결국 삭제하도록 Subscription.cancel()요청해야 합니다(MUST) .Publisher
💡 이 규칙의 목적은 구독이 더 이상 유효하지 않은 후 구독자가 적절하게 가비지 수집될 수 있도록 하는 것입니다. 동일한 구독자 개체로 다시 구독하는 것은 권장되지 않지만[ 2.12 참조 ], 이전에 취소된 구독을 무기한 저장해야 함을 의미하기 때문에 이 사양은 허용되지 않는다고 규정하지 않습니다.

 

14 가 Subscription취소되지 않은 동안 호출하면 가 이 시점에 존재하지 않는 경우 상태 로 전환될 Subscription.cancel수 있습니다 [ 1.9 참조 ].Publishershut-downSubscription
💡 이 규칙의 목적은 게시자가 기존 구독자의 취소 신호에 대한 응답으로 새로운 구독자를 위해 신호를 보내 onComplete거나 onError팔로우하도록 허용하는 것입니다.onSubscribe

 

15 호출은 정상적으로 반환되어야Subscription.cancel 합니다 .
💡 이 규칙의 의도는 구현이 cancel호출에 대한 응답으로 예외를 throw하는 것을 허용하지 않는 것입니다.

 

16 호출은 정상적으로 반환되어야Subscription.request 합니다 .
💡 이 규칙의 의도는 구현이 request호출에 대한 응답으로 예외를 throw하는 것을 허용하지 않는 것입니다.

 

17 A는 Subscription제한 없는 수의 호출을 지원해야 하며 request최대 2^63-1( java.lang.Long.MAX_VALUE)의 요구를 지원해야 합니다. 2^63-1( )보다 크거나 같은 요구는 "효과적으로 무제한" java.lang.Long.MAX_VALUE으로 간주될 수 있습니다 .Publisher
💡 이 규칙의 의도는 의 호출 횟수에 관계없이 가입자가 0 이상의 증분[ 3.9 참조 ] 으로 무제한 요소 수를 요청할 수 있도록 설정하는 것입니다 request. 2^63-1의 수요를 충족시키기 위해 합리적인 시간(나노초당 1개의 요소는 292년이 소요됨) 내에 현재 또는 예상되는 하드웨어로 도달할 수 없기 때문에 게시자는 이 이상으로 수요 추적을 중지할 수 있습니다. 가리키다.
A는 이 쌍 간의 데이터 교환을 중재하기 위해 정확히 하나 와 하나 Subscription에 의해 공유됩니다 . 이것이 메서드가 생성된 것을 반환하지 않고 대신 반환하는 이유입니다 . the는 콜백을 통해서만 the로 전달됩니다 .PublisherSubscribersubscribe()SubscriptionvoidSubscriptionSubscriberonSubscribe

4.프로세서( 코드 )
public interface Processor<T, R> extends Subscriber<T>, Publisher<R> {
}

 

ID 규칙

 

1 A는 Processor처리 단계를 나타내며 a Subscriber와 a 모두 Publisher이며 두 계약을 모두 준수해야 합니다.
💡 이 규칙의 목적은 프로세서가 게시자 및 구독자 사양 모두에 따라 동작하고 바인딩되도록 설정하는 것입니다.

 

2 A Processor는 신호 복구를 선택할 수 있습니다 onError. 그렇게 하기로 선택하면 취소된 것으로 간주해야 하며 , 그렇지 않으면 즉시 구독자에게 신호를 Subscription전파해야 합니다 .onError
💡 이 규칙의 의도는 구현이 단순한 변환 이상일 수 있음을 알리는 것입니다.
필수 사항은 아니지만 취소 신호가 업스트림 Processor으로 전파되도록 하기 위해 마지막이 취소하는 Subscription경우 업스트림을 취소하는 것이 좋습니다 .SubscriberSubscription

비동기식 대 동기식 처리
Reactive Streams API는 요소( onNext) 또는 종료 신호( onError, onComplete) 의 모든 처리 가Publisher . 그러나 각 on*핸들러는 이벤트를 동기식 또는 비동기식으로 처리할 수 있습니다.

다음 예를 들어보세요.

nioSelectorThreadOrigin map(f) filter(p) consumeTo(toNioSelectorOutput)
비동기 원본과 비동기 대상이 있습니다. 출발지와 목적지가 모두 선택자 이벤트 루프라고 가정해 봅시다. Subscription.request(n)대상에서 원본으로 연결되어야 합니다 . 이것은 이제 각 구현이 이를 수행하는 방법을 선택할 수 있는 곳입니다.

다음은 파이프 |문자를 사용하여 비동기 경계(대기열 및 일정)를 알리고 R#리소스(아마도 스레드)를 나타냅니다.

nioSelectorThreadOrigin | map(f) | filter(p) | consumeTo(toNioSelectorOutput)
-------------- R1 ----  | - R2 - | -- R3 --- | ---------- R4 ----------------
map이 예에서 3 명의 소비자 각각은 작업을 비동기적으로 예약합니다 filter. consumeTo동일한 이벤트 루프(트램폴린), 별도의 스레드 등에 있을 수 있습니다.

nioSelectorThreadOrigin map(f) filter(p) | consumeTo(toNioSelectorOutput)
------------------- R1 ----------------- | ---------- R2 ----------------
여기서는 NioSelectorOutput 이벤트 루프에 작업을 추가하여 비동기식으로 예약하는 마지막 단계입니다. map및 단계 filter는 원본 스레드에서 동기적으로 수행됩니다.

또는 다른 구현은 작업을 최종 소비자에게 융합할 수 있습니다.

nioSelectorThreadOrigin | map(f) filter(p) consumeTo(toNioSelectorOutput)
--------- R1 ---------- | ------------------ R2 -------------------------
이러한 변형은 모두 "비동기 스트림"입니다. 그것들은 모두 각자의 자리를 가지고 있으며 각각은 성능 및 구현 복잡성을 포함하여 서로 다른 장단점을 가지고 있습니다.

Reactive Streams 계약을 사용하면 비차단, 비동기, 동적 푸시-풀 스트림의 범위 내에서 리소스 및 스케줄링을 관리하고 비동기 및 동기 처리를 혼합할 수 있는 유연성을 구현할 수 있습니다.

참여하는 모든 API 요소의 완전한 비동기 구현을 허용하기 위해 -- Publisher// / 이러한 인터페이스에 의해 정의된 모든 메서드는 를 반환 Subscription합니다 .SubscriberProcessorvoid

구독자 제어 대기열 범위
기본 설계 원칙 중 하나는 모든 버퍼 크기에 제한이 있으며 이러한 제한은 구독자가 알고 제어 해야 한다는 것입니다. 이러한 범위는 요소 수 (onNext의 호출 수로 변환됨) 로 표현됩니다 . 무한 스트림(특히 높은 출력 속도 스트림) 지원을 목표로 하는 모든 구현은 메모리 부족 오류를 방지하고 일반적으로 리소스 사용을 제한하기 위해 모든 과정에서 경계를 적용해야 합니다.

배압이 필수이기 때문에 무제한 버퍼의 사용을 피할 수 있습니다. 일반적으로 대기열이 제한 없이 증가할 수 있는 유일한 시간은 게시자 측이 오랜 기간 동안 구독자보다 높은 비율을 유지할 때이지만 이 시나리오는 대신 배압으로 처리됩니다.

큐 경계는 적절한 수의 요소에 대한 요구 신호를 보내는 구독자에 의해 제어될 수 있습니다. 구독자는 언제든지 다음을 알고 있습니다.

요청된 요소의 총 수:P
처리된 요소 수:N

그런 다음 게시자에게 더 많은 수요가 신호를 보낼 때까지 도착할 수 있는 최대 요소 수는 입니다 P - N. 구독자가 입력 버퍼에 있는 요소 B의 수를 알고 있는 경우 이 범위를 로 세분화할 수 있습니다 P - B - N.

이러한 경계는 그것이 나타내는 소스가 배압될 수 있는지 여부와 관계없이 게시자에 의해 존중되어야 합니다. 생성 속도에 영향을 줄 수 없는 소스(예: 시계 틱 또는 마우스 움직임)의 경우 게시자는 부과된 범위를 준수하기 위해 요소를 버퍼링하거나 드롭하도록 선택해야 합니다.

요소 수신 후 하나의 요소에 대한 요구 신호를 보내는 가입자는 요구 신호가 승인과 동일한 Stop-and-Wait 프로토콜을 효과적으로 구현합니다. 여러 요소에 대한 수요를 제공함으로써 확인 비용이 상각됩니다. 구독자는 언제든지 수요 신호를 보낼 수 있으므로 게시자와 구독자 사이의 불필요한 지연을 피할 수 있습니다(즉, 전체 왕복을 기다리지 않고 입력 버퍼를 채운 상태로 유지).

 

[백엔드 개발자의 스프링부트 공부노트] 리액티브 파이프라인 예제

리액티브 파이프라인 예제

 

// App 컴포넌트 정의
import React, { useState, useEffect } from "react";

// 데이터 처리 파이프라인 함수
const createReactivePipeline = (data, processor) => {
  return data.map(processor);
};

// 데이터를 두 배로 만드는 프로세서
const doubleProcessor = (number) => {
  return number * 2;
};

const App = () => {
  const initialNumbers = [1, 2, 3, 4, 5];
  const [result, setResult] = useState([]);

  useEffect(() => {
    // 초기 데이터와 프로세서를 이용하여 리액티브 파이프라인 생성
    const pipelineResult = createReactivePipeline(
      initialNumbers,
      doubleProcessor
    );
    setResult(pipelineResult);
  }, []);

  return (
    <div>
      <h1>리액티브 파이프라인 예제</h1>
      <p>초기 숫자: {initialNumbers.join(", ")}</p>
      <p>결과: {result.join(", ")}</p>
    </div>
  );
};

export default App;

 

출력값

초기 숫자: 1, 2, 3, 4, 5

결과: 2, 4, 6, 8, 10

 

 

[백엔드 개발자의 스프링부트 공부노트] 리액트에서 쓰이는 <intger>은 타입인가?

 

TypeScript 사용 시:

tsx

import React from 'react';

interface Props {
  count: number;
}

const MyComponent: React.FC<Props> = ({ count }) => {
  return <div>{count}</div>;
};

export default MyComponent;
PropTypes 사용 시:

PropTypes 사용 시:

jsx

import React from 'react';
import PropTypes from 'prop-types';

const MyComponent = ({ count }) => {
  return <div>{count}</div>;
};

MyComponent.propTypes = {
  count: PropTypes.number.isRequired,
};

export default MyComponent;

 

 

[백엔드 개발자의 스프링부트 공부노트] Mono: 0개 또는 1개의 요소를 방출합니다. 즉, 0 또는 1개의 데이터만 처리합니다.
Flux: 0개에서 n개 혹은 정의된 수의 요소를 방출합니다. 즉, 다양한 개수의 데이터를 처리할 수 있습니다.

Mono   0 또는 1만 데이터 처리

flux     여러개 정의된 수의 요소 방출

import reactor.core.publisher.Mono;
import reactor.core.publisher.Flux;

public class ReactorTypesExample {

    public static void main(String[] args) {
        // Mono 예제
        Mono<Integer> mono = Mono.just(42); // 1개의 요소를 갖는 Mono 생성
        
        // Flux 예제
        Flux<String> flux = Flux.just("A", "B", "C"); // 여러 개의 요소를 갖는 Flux 생성
        
        // 구독(subscribe)하여 데이터 처리
        mono.subscribe(item -> System.out.println("Mono: " + item));
        flux.subscribe(item -> System.out.println("Flux: " + item));
    }
}

 

출력값

Mono: 42
Flux: A
Flux: B
Flux: C

 

위 코드 예제에서, Mono.just(42)는 하나의 데이터를 갖는 Mono를 생성합니다. Flux.just("A", "B", "C")는 세 개의 데이터를 갖는 Flux를 생성합니다. 이후 subscribe를 호출하여 데이터를 처리합니다.

Mono와 Flux는 비동기적인 데이터 처리를 가능하게 하며, 필요에 따라 데이터의 개수에 따른 처리 방식을 선택할 수 있습니다. 이를 통해 데이터 흐름을 리액티브한 방식으로 다룰 수 있습니다.