브로커의 역할
컨트롤러
- 브로커중 한대가 컨트롤러 역할.
- 다른 브로커들 상태를 계속 체크
- 카프카는 지속적 데이터 처리, 브로커가 비정상이면 빠르게 뺀다.
- 리더 재분배
데이터 삭제
- 컨슈머가 데이터를 가져가도 토픽 데이터 삭제 X
- 오직 브로커만 데이터 삭제 가능.
- 삭제는 파일 단위로 ->'로그 세그먼트'
특정 데이터 삭제 불가능
컨슈머 오프셋 저장
- 책갈피 느낌?
- 어느 파티션의 어느 레코드까지 가져 갔는지 커밋
- __consumer_offsets -> 인터널 토픽
그룹 코디네이터
- 컨슈머 그룹 상태 체크
- 파티션을 컨슈머와 매칭되도록 분배하는 역할
- 컨슈머가 그룹에서 빠지면 매칭되지 않은 파티션을 재할당(리밸런스)
데이터 저장
- config/server.properties의 log.dir 옵션에 정의한 dir에 데이터 저장
- log에는 메시지, 메타데이터 저장
- index -> 메시지 오프셋 인덱싱 정보...
로그(log.segment.bytes) -> 바이트 단위 설정, 기본값 1GB, 최대 세그먼트 크기 지정
시간(log.roll.ms(hours)) -> 시간 단위 설정, 기본 7일, 다음 파일로 넘어가는 시간 주기
오프셋 -> 레코드의 고유한 번호, 최초 오프셋 이름이 파일 이름
active segment -> 사용가능한 가장 최근 세그먼트(읽고있는, 쓰기가 일어나고 있는...)
cleanup.policy=delete -> 삭제 주기...
log.retention.check.interval.ms -> 세그먼트가 삭제 영억에 들어왔는지 확인하느 간격(기본 5분)
retention.ms -> 세그먼트를 보유할 최대 기간(보통 3일)
retention.bytes -> 파티션당 로그 적재 바이트 값
오프셋 수정 X
레코드 수정, 삭제 불가능
cleanup.policy=compact
- 가장 최근 key만 남기고 삭제
- 삭제 정책과 다르게 레코드 삭제
- active 제외
테일 영역 -> 압축 완료된 레코드, 클린 로그라고 부른다. 중복 메시지 키 x
헤드 영역 -> 압축 전 레코드, 더티 로그, 중복 메시지 키 0
압축이 일어나면 중간에 오프셋이 빈다.
min.cleanable.dirty.ratio
- active 제외, 테일 영역의 레코드 개수와 헤드 영역의 레코드 개수의 비율.
ex) 0.5 -> tail, head 레코드 개수가 동일하면 압축 실행
복제
- 파티션 단위 복제
replication factor 설정(갯수)
2 ~ 3으로...
복제 갯수가 늘어나면 저장 용량도 늘어나야함
컨슈머, 프로듀서는 리더와 통신
팔로우는 복제 역할
만약 유실되어도 상관이 없는 데이터면 replication factor 1로 설정(기본값)
ex)실시간 차량데이터...
ISR(In-Sync-Replicas) -> 리더와 팔로워 파티션의 오프셋 크기가 같다(팔로워 파티션 동기화 완료)
만약 데이터를 모두 복제하지 못한 상태이면..?
unclean.leader.election.enable=true
- 유실 감수, 복제 안된 팔로워 파티션 리더 승급
unclean.leader.election.enable=flase
- 유실 감수x, 리더 복구될 때까지 중단
토픽에 따라 설정 가능!!
