토픽 - 한 개 이상의 파티션 소유
파티션 - 데이터 저장(레코드), 큐와 비슷한 구조, FIFO, 삭제X
데이터 쏠림 방지
kafka-reassign-partitions.sh
-> 파티션 재분배
컨슈머 개수를 늘림과 동시에 파티션 개수도 늘리면 처리량이 증가하는 효과를 볼 수 있다.
파티션1 - 컨슈머2 -> 불가능
파티션2 - 컨슈머2 -> 가능
파티션2 - 컨슈머1 -> 가능
파티션 늘리면서 컨슈머도 같이 늘리기
만약 장애가 발생하면 컨슈머 한개로도 가능
파티션 개수 줄이기는 불가능
timestamp - 시간 저장, 스트림 프로세싱, 기본(생성시간)
offset - 브로커에 적재 -> 생성
header - (key-value), 스키마 버전, 포맷과 같이 데이터 프로세싱에 참고할만한 정보 담아서 사용 가능
key - 값 분류 위해 사용(파티셔닝), null이면 라운드 로빈 방식으로 데이터를 파티션에 저장, 어느 파티션에 들어갈지 정하는게 파티셔너
이다.
if 메시지 key == null -> RR방식으로 특정 토픽 파티셔너에 전달
!= null -> 해쉬값에 의해서 특정 파티션에 매칭되어 전달
value -> 문서들, 처리할 데이터 담는 공간(csv, JSON...)
브로커에 저장된 레코드의 메시지 값은 어떤 포맷인지 알 수 없기 때문에 미리 역직렬화 포맷 알아야한다.
빈 문자열 X
영어, 숫자, 마침표, 언더바, 하이픈
마침표, 언더바 두개 동시 X
토픽이 데이터의 얼굴이다...
토픽이름 변경 불가
카프카 클라이언트 ----(메타데이터 요청)---> 카프카 클러스터
카프카 클라이언트 <---(메타데이터 응답)---- 카프카 클러스터
카프카 클라이언트는 통신하고자 하는 리더 파티션의 위치를 알기 위해 메타데이터를 브로커로부터 전달 받는다.
카프카 프로두셔 메타데이터 옵션
metadata.max.age.ms
-> 강제 리프래시 간격, 기본 5분
metadata.max.idle.ms
-> 메타데이터를 캐시에 유지하는 기간, 시간이 지나면 강제로 meta RF
클라이언트는 무조건 리더와 통신, 리프래쉬 간격 확인
만약 LEADER_NOT_AVAILABLE 익셉션이 자주 발생하면 메타데이터 리프래시 간격을 확인하자!
카프카 데이터 복제 단위는 파티션
프로듀서와 컨슈머는 리더와 통신