1. FIFO 구조와 같이 먼저 들어간 레코드는 컨슈머가 먼저 가져가게 된다.
다만, 일반적인 자료구조로 사용되는 큐는 데이터를 가져가면(pop) 삭제하지만 카프카에서는 삭제하지 않는다.
2. 파티션의 레코드는 컨슈머가 가져가는 것과 별개로 관리된다.
이러한 특징 때문에 토픽의 레코드는 다양한 목적을 가진 여러 컨슈머 그룹들이 토픽의 데이터를 여러번 가져갈 수 있다. ### 5. 토픽 생성시 파티션이 배치되는 방법
1. 0번 브로커부터 시작하여 round-robin 방식으로 리더 파티션들이 생성된다.
2. 카프카 클라이언트는 리더 파티션이 있는 브로커와 통신하여 데이터를 주고 받으므로 여러 브로커에 골고루 네트워크 통신을 하게 된다.
3. 이를 통해, 데이터가 특정 서버(브로커)와 통신이 집중되는(hot spot) 현상을 막고 선형 확장(linear scale out)을 하여 데이터가 많아지더라도 자연스럽게 대응할 수 있게 된다.
4. 팔로워 파티션은 리더 파티션 기준으로 순차적으로 다음 브로커에 생성된다.
5. 특정 브로커에 파티션이 쏠린 현상
1. 카프카 클러스터를 운영할 때 파티션이 쏠리는 현상을 막는것이 중요하다.
2. 특정 브로커에 파티션이 몰리는 경우에는 `[kafka-reassign-partitions.sh](http://kafka-reassign-partitions.sh)` 명령으로 파티션을 재분배 할 수 있다. (카프카에는 운영을 위해 다양한 쉘스크립트가 제공되고있다.) ### 6. 파티션 갯수와 컨슈머 갯수의 처리량
1. 기본적으로 파티션과 컨슈머는 1:1 관계이다.
2. 한개의 파티션은 최대 한개의 컨슈머만 가질 수 있다.
3. 데이터 처리량을 늘리기 위해서는 파티션을 늘리고 그와 동시에 컨슈머의 갯수도 늘려야한다. (병렬 처리량 증가)
- 컨슈머의 갯수가 파티션의 갯수보다 작아지더라도 한개의 컨슈머에 여러개의 파티션이 할당되어 처리가 가능하다.
4. 데이터 처리 지연
- 프로듀서의 이밴트 발생 속도보다 컨슈머의 처리 속도가 느릴 경우 지연이 발생한다. (컨슈머 랙)
- 프로듀서에 초당 10개의 이벤트가 발생하고 컨슈머의 처리 속도는 초당 1개인 경우 파티션을 10개로 늘리고 컨슈머도 10개로 늘리면된다. 일반적으로 딱 맞추기 보다는 더 넉넉하게 가져간다 ### 7. 파티션 갯수를 줄이는 것은 불가능
1. 카프카에서 파티션 갯수를 줄이는 것은 지원하지 않는다. 그러므로 파티션을 늘리는 작업을 할 때는 신중히 파티션 갯수를 정해야한다.
2. 한번 늘리면 줄이는 것은 불가능하기 때문에 토픽을 삭제하고 재생성하는 방법외에는 없기 때문이다.
3. KIP-694 (카프카 jira) 에서 파티션 갯수를 줄이는 것을 논의했지만 더 이상 진행되지 않고 있다.
Comments