Obsidian/Recognition/Programing/Kafka(AMQP)/Kafka 기본 구조.md

### 구성요소
- 주키퍼(Zookeeper) : 메타데이터(metadata) 관리 및 브로커의 정상상태 점검(health check)
- 클러스터(Kafka cluster) : 여러 대의 브로커를 구성한 클러스터
- 브로커(broker) : 카프카 애플리케이션이 설치된 서버 또는 노드
	- 컨슈며와 파티션 간 매핑 관리
	- 메시지 필터, 재전송등은 Client가 직접 해야 함
- 프로듀서(producer) : 카프카로 메시지를 보내는 역할을 하는 클라이언트로 총칭
- 컨슈머(consumer) : 카프카에서 메시지를 꺼내가는 역할을 하는 클라이언트를 총칭
- 토픽(topic) : 카프카는 메시지 피드들을 토픽으로 구분하고, 각 토픽의 이름은 카프카 내에서 고유함.
- 파티션(partition) : 병렬 처리 및 고성능을 얻기 위해 하나의 토픽을 여러 개로 나눈 것을 의미합니다
	- 한번 늘리면 파티션을 다시 줄일 수 없다.
	- 대체로 초기에 2~4 정도로 생성하고 컨슈머의 LAG를 모니터링한 뒤에 조금씩 늘리는 방식을 선택
		※ 컨슈머의 LAG :  프로듀서가 보낸 메시지수(카프카에 남아 있는 메세지 수) - 컨슈머가 가져간 메세지 수
	- 각 파티션마다 n개의 세그먼트 로그파일이 존재
	- 컨슈머가 마지막 읽은 위치를 알 수 있도록 Offset(64bit,순차증가)을 가지고 있음.
	- 한 파티션 내에서만 메시지 순서 보장.
	- 한개의 파티션은 한개의 컨슈머만 연결 가능(다른그룹의 컨슈며는 공유가능)
	- 
- 세그먼트(segment) : 프로듀서가 전송한 실제 메시지가 중개인의 로컬 디스크에 저장되는 파일
- 메시지(message) 또는 레코드(record): 프로듀서가 브로커로 전송하거나 컨슈머가 읽어가는 데이터 조각
	- 토픽의 파티션에 저장됨.
	- 세그먼트(segment)라는 로그 파일의 형태로 브로커의 로컬 디스크에 저장 (디렉토리: logs)


- 리플리케이션(replication)
	- 각 메시지들을 여러 개로 복제해서 카프카 클러스터 내 브로커들에 분산시키는 동작
	- 토픽자체가 아닌 파티션을 복제
	- 원본과 리플리케이션을 구분하기 위해 리더(leader)와 팔로워(follower)로 구분함.
	``` Text
	--partition 1, --replication-factor 3 
	=> 원본을 포함하여 3개의 replication이 있음을 의미.
	```

### 프로듀서
- 카프카의 토픽으로 메세지를 전송하는 역할
- ProducerRecord : 카프카로 전송하기 위한 실제 데이터
- 레코드는 토픽, 파티션, 키, 밸류(value) 로 구성
- 1) 프로듀서가 카프카로 레코드를 전송할 때, 특정 토픽으로 메세지를 전송하며, 레코드에서 토픽과 밸류(메세지 내용)은 필수이고, 특정 파티션을 지정하기 위한 레코드의 파티션 과 특정 파티션에 레코드들을 정렬하기 위한 레코드의 키는 선택사항 (옵션) 
- 2) 다음으로 각 레코드들은 프로듀서의 send() 메소드를 통해서 시리얼라이저(serializer, 직렬화) 그리고 파티셔너를 거치게 됨
- 3) 만약 프로듀서 레코드의 선택사항인 파티션을 지정 하였다면 파티셔너는 아무 동작도 하지 않고 지정된 파티션으로 레코드를 전달,  파티션을 지정하지 않은 경우에는 키를 가지고 파티션을 선택해 레코드를 전달하는데 기본적으로 라운드 로빈(round robin) 방식으로 동작
- 4) send() 메소드 동작 이후 레코드들을 프로듀서가 카프카로 전송하기 전에 배치 전송을 하기 위해서파티션 별로 잠시 모아둠. 전송이 실패되면 재시도 동작이 이루어지게 되고 지정한 횟수만큼 재시도가 실패하면 최종 실패로 전달하게 되고, 전송이 성공되면 성공에 대한 메타데이터를 리턴

### 컨슈머
- 컨슈머 그룹은 하나이상의 컨슈머들이 모여 있는 그룹을 의미하고 컨슈머는 반드시 컨슈머 그룹에 속하게 된다.
- 컨슈머 그룹은 각 파티션의 리더에게 카프카 토픽에 저장된 메세지를 가져오기 위한 요청을 보낸다.
- 이때 파티션 수와 컨슈머(하나의 컨슈머 그룹 안에 있는 컨슈머 수)는 일대일로 매핑 해야하는 것은 아니지만, 파티션 수보다 컨슈머 수가 많게 구현되는 것은 바람직한 구성은 아니다. (컨슈머 수가 파티션 수보다 많다면 더 많은 수의 컨슈머들은 그냥 대기 상태로 존재하기 때문에 더 빠르게 메세지를 가져오거나 처리량을 늘어나지 않기 떄문. )
- 컨슈머 그룹내에서 리밸런싱 동작을 통해 장애가 발생한 컨슈머의 역할을 동일한 그룹에 있는 다른 컨슈머가 그 역할을 대신 수행 하므로 굳이 장애 대비를 위한 추가 컨슈머 리소스를 할당하지 않아도 된다.

#### 컨슈머그룹
- 컨슈머는 컨슈머 그룹 안에 속한 것이 일반적인 구조
- 하나의 컨슈머 그룹안에 여러개의 컨슈머가 구성될 수 있다.
- 컨슈머는 토픽의 파티션과 일대일로 매핑 되어 메세지를 가져오게 된다.
- 그룹 내의 컨슈머들은 서로의 정보를 고유 하게 됨.
	- 공유하는 정보로는 예를 들어 컨슈머01이 문제가 발생하여 종료되었다면, 컨슈머02 또는 컨슈머03은 컨슈머01이 하던일을 대신해서 peter-01 토픽의 파티션 0을 컨슘하게 된다.