컨슈머가 poll() 을 호출할 때마다 컨슈머 그룹은 카프카에서 저장되어 있는 읽지 않은 메시지를 가져옴 컨슈머 그룹의 컨슈머들은 가각의 파티션에 자신이 가져간 메시지의 위치 정보(offset) 을 기록 각 파티션에 대해 현재 위치를 업데이트 하는 동작을 commit 각 컨슈머 그룹별로 offset 정보를 저장하기 위한 저장소 별도로 사용 0.9 이전 버전은 zookeeper 에 저장 이후 버전은 카프카 내에 별도의 토픽을 만들어서 저장 → __consumer_offsets 컨슈머가 갑자기 다운 또는 새로운 컨슈머가 조인한다면 → 컨슈머 그룹 내에서 rebalance 발생 리벨런스 후 각각의 컨슈머는 이전에 처리했던 토픽의 파티션이 아닌 다른 새로운 파티션에 할당 → d컨슈머는 새로운 파티션에 대해 가장..
토픽의 파티션 수가 증가함에 따라 빠른 전송이 가능 하지만 무조건 파티션 수를 늘려주는 것이 좋을까? → 파티션 수의 변경은 신중하게 결정 장점 높은 처리량 : 파티션은 카프카에서 병렬 처리르 지원하도록 구성하는 방안 하드웨어 자원을 최대한 활용 가능 이슈 파일 핸들러 낭비 카프카에서는 모든 디렉토리의 파일들에 대해 파일 핸들을 열게됨 파티션의 수가 많을수록 파일 핸들 수 역시 많아 지게 되어 리소스 낭비 발생 장애 복구 시간 증가 프로듀서 메모리 증가 토픽의 적절한 파티션 수는? 하나의 파티션에 두개의 컨슈머 연결은 불가능 (하지만 1개의 컨슈머가 같은 토픽의 다른 2개의 파티션 연결은 가능) Java 코드에서 consumer.assign 으로 파티션설정시 array 로 설정하기 때문에 n개의 파티션으..
kafka version 2.11 - 카프카 성능 테스트 정리 - Kafka 에서 제공하는 테스트용 스크립트 이용 - path : kafka/bin - kafka-producer-perf-test.sh - kafka-consumer-perf-test.sh - 위 스크립트를 옵션 없이 실행 시 아래와 같이 사용법 및 옵션 확인 가능 테스트용 토픽을 생성해서 테스트 진행 default 설정으로 사용시 최대 전송 가능한 record-size = 1MB (1048588 bytes) 1MB 이상 전송 시 카프카 설정 수정 후 재시작 server.properties → message.max.bytes producer.properties → max.request.size consumer.properties → max..
- Total
- Today
- Yesterday
- 문자열
- 티스토리초대장
- mysql
- string
- elastic stack
- Database
- Algorithm
- kafka
- 카프카
- ArrayList
- scouter
- JDBC
- PreparedStatement
- 알고리즘
- 서울카페
- 미사맛집
- db
- jenkins
- 자바
- Array
- spring
- keycloak
- 잠실맛집
- 자료구조
- docker
- 초대장
- 도커
- 리스트
- 송리단길맛집
- Java
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |