카프카 기본
파티션
- 카프카는 동일한 파티션 내에서는 메시지 순서를 보장한다. 하지만 멀티 파티션 환경(여러 파티션에 메시지를 분산 전송/구독)에서는 메시지 순서를 보장하지 않습니다.
오프셋
파티션 내 record는 오프셋이라는 순서의 식별하는 정보를 가진다. 각각의 파티션들을 Append-Only 방식으로 record를 기록한다.
위의 그림은 3개의 파니션을 가지는 토픽이다. record는 Append-Only 방식으로 방식으로 기록되기 때문에 새로운 record는 파티션 마지막에 추가된다. 위의 그림을 보면 오프셋은 각각의 파티션 내부에서는 순서를 보장하지만, 파티션 간에는 오프셋으로 순서를 보장하지 못한다는 것을 알 수 있다.
✔ 각 파티션 내부에서는 순서 보장, 파티션 간에는 순서 보장 안됨
프로듀서 -> 파티션으로 레코드 작성
프로듀서에서 3가지 방법으로 파티션에 레코드를 발행할 수 있다.
- 파티션 키 사용
- 카프카에 맡김
- 자체 파티셔너 구현
컨슈머
- 보통의 pub/sub 모델과는 달리, Kafka 는 메시지를 Consumer 에 전달 (push) 하지 않는다. 대신, Consumer 가 카프카의 파티션으로부터 메시지를 읽어 (pull) 가야 한다. 컨슈머는 브로커의 파티션과 연결해, 메시지들이 쓰여진 순서대로 메시지를 읽는다.
헷깔리는 point
컨슈머 그룹과 파티션의 관계
topic 핵심 명령어
--bootstrap-server와 --zookeeper
명령어 중 서버정보 입력 시 --bootstrap-server와--zookeeper가 사용되는 것을 볼 수 있다. 이 둘의 설정은 어떤 차이가 있는가?
카프카 0.9.0.0 버전 이전에는 ZooKeeper를 사용하여 카프카 클러스터의 메타데이터와 리더 정보를 관리했습니다. 하지만 최신 버전에서는 브로커들끼리 직접 통신하여 메타데이터를 관리하므로, ZooKeeper에 대한 의존성을 줄이고 --bootstrap-server를 사용하도록 권장하고 있습니다. (by chat-gpt)
topic 생성
bin/kafka-topics.sh --create --bootstrap-server localhost:9092 --topic topic01 --replication-factor 1 --partitions 1
-> replication-factor : 복제본 갯수에 대한 설정.
topic 리스트 확인
bin/kafka-topics.sh --list --bootstrap-server localhost:9092
topic 삭제
bin/kafka-topics.sh --delete --bootstrap-server localhost:9092
프로듀서 실행 및 메시지 전송
bin/kafka-console-producer.sh --bootstrap-server localhost:9092 --topic topic01
컨슈머 메시지 구독
bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic topic01
properties 설정
server.properties
내부와 외부에 오픈할 특정 IP를 별도로 두기 위해서 listeners, advertised.listeners 를 설정할 수 있다.
- listeners : 카프카 브로커가 내부적으로 바인딩하는 주소
- advertiesd.listeners : 브로커가 클라이언트(컨슈머,프로듀서)에게 노출하는 주소. 즉, 외부에 노출하는 주소이다. 설정하지 않는 경우 listeners설정을 따른다.
https://shinwusub.tistory.com/133
https://ssdragon.tistory.com/117?category=1048285
https://ggop-n.tistory.com/89 (카프카 전반적인 설명)