이번 포스팅에서는 반응형(Reactive) 모델이 최근 떠오르고 있는 이유와 이에 대한 장단점, 반응형 프로그래밍을 표준화하기 위한 과정들, Spring에서 기존 서블릿을 대체하는 반응형 네트워크 엔진 등에 대해 알아본다. Blocking I/O와 Non-Blocking I/O의 동작 원리 반응형(Reactive) 프로그래밍을 이해하기 위해선 Non-Blocking I/O의 동작 원리와 Blocking I/O와 비교했을 때 어떤 장단점이 있는지를 명확하게 이해해야 한다. 위 그림과 같이 Non-Blokcing I/O 모델은 I/O가 발생하더라도 block되지 않기 때문에 다른 요청을 처리할 수 있게 된다. 따라서 더 적은 양의 쓰레드와 CPU로 다수의 요청을 동시에(Parallel의 의미가 아니라 Con..
Netty에서 제공되는 I/O는 모두 Non-Blocking 기반이다. 예를 들어, Bootstrap에 대한 connect, bind 또는 writeAndFlush 등의 I/O 메소드는 모두 Non-blocking I/O 기반으로 동작한다. Non-Blocking I/O Non-Blocking I/O는 쓰레드가 실행 중에 I/O 연산을 마주했을 때 system call을 하고 바로 빠져나와(Non-Blocking I/O) 다음 작업을 처리하는 방식이다. 따라서 Non-blocking I/O기반의 작업은 I/O가 완료되기 전까지 다른 작업을 수행할 수 있다는 게 핵심이다. 이러한 개념에 비추어 봤을 때, I/O 시간이 오래걸리는 것에 대해서 Non-blocking을 기반으로 하는 것이 좋다. I/O 시간이..
이 글에서 말하는 Stream I/O는 일반적으로 자바에서 말하는, 필더링, 리덕션 등의 고차 함수를 이용하는 Stream과 다르다. I/O라는 용어가 붙었기 때문에 file, device, socket I/O 등 운영체제의 도움을 받아 처리되는 데이터의 입출력을 말하는 것이다. Stream I/O 추상적으로 Stream은 '데이터의 흐름'이다. 좀 더 이해를 쉽게 하자면 '데이터가 이동하는 통로'라고 생각해도 좋다. 자바에서 Stream(java.io)은 단방향 통신만을 지원하기 때문에 InputStream과 OutputStream을 따로 둘 수밖에 없었다. 또한 Stream은 Blocking I/O 만을 지원하기 때문에 모든 I/O 작업이 완료되기 전까지 자바 프로세스가 다른 작업을 수행할 수 없다...
- Total
- Today
- Yesterday
- K8s
- rolling update
- jvm
- kafka
- Kotlin
- go
- ci/cd
- argocd
- CICD
- github actions
- 우분투
- Kubernetes
- Non-Blocking
- Stream
- golang
- 컨트롤러
- 코틀린
- db
- ubuntu
- 카프카
- GitOps
- Linux
- container
- docker
- LFCS
- 쿠버네티스
- Controller
- Java
- RDB
- spring
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |