
DispatcherHandlerDispatcherHandler는 WebHandler를 구현하고 있고, handlerMappings, handlerAdapters, resultHandlers로 구성되어 있다.DispatcherHandler의 요청 처리 흐름DispatcherHandler에서 요청을 처리하는 흐름을 도식화하면 아래와 같이 나타낼 수 있다.Netty로부터 요청(request)이 들어온다.DispatcherHandler는 HandlerMapping List를 순회하면서 요청을 처리할 수 있는 Handler를 찾아 반환한다.Handler의 호출을 위임하기 위해 HandlerAdapter List로 가서 이 요청을 처리할 수 있는 HandlerAdapter를 조회한다.반환받은 HandlerAdapt..

각각의 스레드에서 상태 값을 저장하여 사용할 수 있는 스레드로컬과 유사하게 리액터에서는 컨텍스트를 사용해서 리액터 시퀀스상에 상태 값을 저장하고, 저장된 상태 값을 사용할 수 있다. 먼저 리액터에서의 컨텍스트가 무엇인지 살펴보고, 컨텍스트의 특징과 자주 사용되는 API를 살펴보자 컨텍스트란 Reactor Sequence상에서 상태를 저장할 수 있고, 저장된 상태 값을 Operator 체인에서 공유해서 사용할 수 있는 인터페이스이다. Context에 값을 저장하기 위해서는 contextWrite()를 사용하고, 저장된 상태 값은 key, value 형태로 저장된다. Context에 저장된 값을 읽어오기 위해서는 읽기 전용 뷰인 ContextView를 사용한다. ContextView는 Reactor Sequ..

리액터에서 스케줄러는 쓰레드를 관리하는 쓰레드 관리자 역할을 하는데, 구독시점에 데이터가 emit되는 영역과 emit된 데이터를 operator로 가공 처리하는 영역을 분리해서 손쉽게 멀티스레딩을 가능하게 한다. 또한, 리액터에서의 스케줄러는 크게 operator chain에서 스케줄러를 전환하는 역할을 하는 전용 operator와 스케줄러를 통해 생성되는 쓰레드 실행 모델을 지정하는 부분으로 구성이 되어 있다. 이 두가지 구성요소 중, 스케줄러를 전환해주는 operator에 대해 자세히 살펴보자. 스케줄러를 전환해주는 operator 리엑터에서 지원하는 스케줄러를 위한 전용 operator는 크게 세가지가 있다. publishOn(): operator chain에서 Downstream Operator의..

백프레셔는 Publisher로부터 Subscriber에게 끊임없이 전달되는 데이터를 안정적으로 처리하기 위한 처리 방식이다. 이러한 백프레셔를 좀 더 쉽게 이해하기 위해서는 Publisher와 Subscriber가 어떤 방식으로 데이터를 주고 받는지 이해하는 것이 좋다. Publisher와 Subscriber간의 프로세스 리액티브 프로그래밍은 Publisher와 Subscriber간의 Interaction이라고 볼 수 있다. 가장 먼저 Subscriber에서 subscribe() 메서드를 호출하면서 구독을 시작한다. Publisher에서는 구독이 정상적으로 이루어졌음을 onSubscribe signal로 subscriber에게 알려준다. Subscriber에서 데이터를 전달받기 위해 request sig..

리액티브 프로그래밍에서 퍼블리셔가 만들어내는 데이터의 흐름은 Cold와 Hot 두가지로 나뉜다. 참고로 리액터에서는 퍼블리셔가 만들어내는 데이터의 흐름에 대해서 시퀀스라는 용어를 사용한다. 여기서 Cold Publisher와 Hot Publisher 그리고 Cold Sequence와 Hot Sequence는 거의 같은 의미라고 할 수 있다. 그렇다면 Cold Sequence와 Hot Sequence는 대체 무슨 차이가 있는지 아래에서 알아보자. Cold Sequence Cold Publisher는 Cold Sequence라는 데이터의 흐름을 만들어내는 퍼블리셔이다. 먼저 맨 위의 첫 번째 Subscriber의 구독이 발생하고, 그 뒤 Cold publusher는 1, 3, 5, 7이라는 데이터를 차례대로..

fun main(args: Array { println("Hello, World") } 함수를 선언할 때 fun 키워드를 사용한다. 파라미터 이름 뒤에 그 파라미터의 타입을 작성한다. 이는 변수를 선언할 때도 마찬가지로 방식으로 타입을 지정한다. 함수를 최상위 수준에 정의할 수 있다. 즉, 클래스 안에 함수를 넣어야할 필요가 없다. 코틀린에서는 자바와 달리 배열 처리를 위한 문법이 따로 존재하지 않는다. 배열도 일반적인 클래스와 마찬가지이다. 코틀린 표준 라이브러리는 여러 가지 표준 자바 라이브러리 함수를 간결하게 사용할 수 있게 감싼 래퍼(wrapper)를 제공한다. 세미콜론(;)을 붙이지 않아도 된다. 함수 함수 선언은 fun 키워드로 시작하고, fun 다음에는 함수 이름이 온다. 아래 max라는 이..

취득 계기 그동안 개발자로 근무하면서 AWS가 무엇인지는 알지만, 남들 다 쓰니까 쓴다는 생각으로 사용해왔습니다. 더이상은 이렇게 사용하면 안 되겠다는 생각으로 AWS 책을 구입해서 좀 더 깊게 공부하던 중, 문득 "AWS도 자격증이 있던데 도전이나 해볼까?" 하게 되었습니다. 제 성격상 생각만 하지말고 당장 실천하자는 마음으로 자격증 취득에 도전하게 되었습니다. 공부 방법 인터넷에서 정보를 찾아보니 대부분의 블로그에서 udemy 인강(【한글자막】 AWS Certified Solutions Architect Associate 시험합격!)을 추천하고 있었고, udemy에 접속해보니 마침 운좋게도 99,000원에서 15,000원으로 할인을 하고 있었습니다. 27시간이라는 상당한 런닝타임을 자랑했지만, 공부가..

안녕하세요! 오랜만에 이슈 해결 회고 글을 작성하는 것 같습니다. 사실은 써야지 써야지하면서 치일피일 미루다가 영원히 미뤄지겠단 생각에 드디어 글을 작성하게 되었습니다. 문제점 새로운 프로젝트에서 회원 및 인증 도메인을 담당하게 되었고, 그 중 소셜 로그인 개발을 진행하면서 발생한 문제입니다. 소셜 로그인을 진행하기 위해서는 각 플랫폼 서버(네이버, 카카오 등)로부터 client-id와 client-secret 값을 얻게 되는데, 이는 외부에 노출되면 위험한 식별값입니다. 그렇기 때문에 클라이언트에서 SDK로 관리하며 통신하는 방식보다는 서버에서 관리하는 것이 좀 더 안전하겠다는 팀 내부의 니즈에 맞춰 authorization-grant-type: authorization_code 인증 방식으로 진행하기..

프로듀서는 카프카에서 데이터의 시작점이다. 프로듀서 애플리케이션은 카프카에 필요한 데이터를 선언하고 브로커의 특정 토픽의 파티션에 전송한다. 프로듀서가 데이터를 전송할 때 리더 파티션을 가지고 있는 카프카 브로커와 직접 통신하는데, 카프카 브로커로 데이터를 전송할 때 내부적으로 파티셔너, 배치 생성 단계를 거친다. 프로듀서 내부 구조 ProducerRecord: 프로듀서에서 생성하는 레코드, 오프셋은 미포함 send(): 레코드를 전송 요청하는 메서드 Partitioner: 어느 파티션으로 전송할지 지정하는 파티셔너 Accumulator: 배치로 묶어 전송할 데이터를 모으는 버퍼 Default Partitioner 프로듀서 API를 사용하면 UniformStickyPartitioner 와 RoundRob..

CPU 사용량, 메모리 사용량, 톰캣 쓰레드, DB 커넥션 풀과 같이 공통으로 사용되는 기술 메트릭은 이미 등록되어 있기 때문에, 등록된 메트릭을 사용해서 대시보드를 구성하고 모니터링 하면 된다. 만약 비즈니스에 특화된 주문수, 취소수, 재고 수량과 같은 부분을 모니터링하고 싶은데, 이 부분은 공통으로 만들 수 있는 부분이 아니라 각각의 비즈니스에 특화된 부분들이다. 결국 비즈니스에 관한 부분은 각 비즈니스 마다 구현이 다르다. 따라서 비즈니스 메트릭은 직접 등록하고 확인해야 한다. 이번에는 우리 비즈니스의 실시간 주문수, 취소수 또 실시간 재고 수량을 메트릭으로 등록하고 확인해보자. 각각의 메트릭은 아래와 같이 정의한다. 주문수, 취소수 상품을 주문하면 주문수가 증가한다. 상품을 취소해도 주문수는 유지..
- Total
- Today
- Yesterday
- 북클럽
- 노마드코더
- Algorithm
- MySQL
- 코틀린
- Spring
- 스프링부트
- 백준
- 자료구조
- 문자열
- kotlin
- 파이썬
- 그리디
- spring boot
- 코테
- 인프런
- 리팩토링
- 구현
- 스프링 부트
- webflux
- 데이터베이스
- Real MySQL
- leetcode
- 스프링
- 노마드
- 알고리즘
- 정렬
- mysql 8.0
- 김영한
- 릿코드
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 |