프로듀서는 카프카에서 데이터의 시작점이다. 프로듀서 애플리케이션은 카프카에 필요한 데이터를 선언하고 브로커의 특정 토픽의 파티션에 전송한다. 프로듀서가 데이터를 전송할 때 리더 파티션을 가지고 있는 카프카 브로커와 직접 통신하는데, 카프카 브로커로 데이터를 전송할 때 내부적으로 파티셔너, 배치 생성 단계를 거친다. 프로듀서 내부 구조 ProducerRecord: 프로듀서에서 생성하는 레코드, 오프셋은 미포함 send(): 레코드를 전송 요청하는 메서드 Partitioner: 어느 파티션으로 전송할지 지정하는 파티셔너 Accumulator: 배치로 묶어 전송할 데이터를 모으는 버퍼 Default Partitioner 프로듀서 API를 사용하면 UniformStickyPartitioner 와 RoundRob..
토픽 & 파티션 토픽은 카프카에서 데이터를 구분하기 위해 사용하는 단위이다. 파티션에는 프로듀서가 보낸 데이터들이 들어가 저장되는데 이 데이터를 레코드라고 부르며, 1개 이상의 파티션을 소유하고 있다. FIFO 구조와 같이 먼저 들어간 레코드를 컨슈머가 먼저 가져가게 된다. 일반적인 자료구조의 큐는 데이터를 가져가면 삭제 되지만 카프카에서는 삭제되지 않고, 파티션의 레코드는 컨슈머가 가져가는 것과 별개로 관리된다. 이런 특징때문에 토픽의 레코드는 다양한 목적을 가진 여러 컨슈머 그룹들이 토픽의 데이터를 여러번 가져갈 수 있다. 토픽 생성시 파티션이 배치되는 방법 파티션이 5개인 토픽을 생성했을 경우, 첫 번째 그림과 같이 0번 브로커부터 시작하여 round-robin 방식으로 리더 파티션들이 생성된다. ..
카프카 생태계 프로듀서: 토픽으로 데이터(메세지)를 발행한다. 컨슈머: 토픽에서 데이터(메세지)를 소비한다. 토픽: 목적에 따라서 생성된 데이터(메세지)이다. 스트림즈: 프로세싱을 통해서 토픽에 존재하는 데이터를 처리하고, 다시 토픽에 넣는 역할을 수행한다. 커넥트: 데이터 파이프라인을 운영하는 가장 핵심적인 툴이다. 소스 커넥트: 특정 DB나 AWS S3와 같은곳에서 데이터(메세지)를 가져와서 토픽으로 발행한다. 싱크 커넥트: 타켓 애플리케이션으로 데이터(메시지)를 소비한다. 주키퍼 카프카 클러스터를 운영하기 위해서 반드시 필요한 애플리케이션이다. 카프카 2.x 버전까지는 반드시 주키퍼가 필요하고, 3.x 버전부터는 주키퍼가 없더라도 운영이 가능하지만, 아직까지는 완벽하게 주키퍼를 대체하지 못하는 부분..
- Total
- Today
- Yesterday
- 그리디
- 노마드코더
- webflux
- leetcode
- Spring
- 김영한
- 자료구조
- mysql 8.0
- 알고리즘
- 인프런
- 파이썬
- 구현
- kotlin
- 리팩토링
- 스프링
- 코테
- Algorithm
- 문자열
- 릿코드
- 정렬
- 코틀린
- 스프링부트
- spring boot
- Real MySQL
- 스프링 부트
- 노마드
- MySQL
- 데이터베이스
- 북클럽
- 백준
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 | 31 |