onPartitionsLost — '정상적으로 반납'과 '갑자기 빼앗김'은 다르다
Kafka 트랜잭션 컨트롤 레코드 및 ConsumerRebalanceListener#onPartitionsLost(KIP-429) 공식 문서 종합 (웹 리서치, 2026) — Apache Kafka 공식 문서·기술 블로그(Kafka Transactions Deep Dive), KIP-429: Kafka Consumer Incremental Rebalance Protocol KIP-429: Kafka Consumer Incremental Rebalance Protocol
이 모듈을 다 읽으면
- onPartitionsLost가 onPartitionsRevoked와 트리거 조건에서 어떻게 다른지 설명할 수 있다
- onPartitionsLost 콜백 안에서 오프셋 커밋을 시도하면 안 되는 이유를 설명할 수 있다
kafka-learn-08에서 다룬 리밸런스 리스너(오프셋 커밋 시점 통제)를 전제로, 정상적인 리밸런스로 파티션을 '반납'하는 경우와 리밸런스를 놓쳐 그룹에서 '떨어져 나가' 파티션을 갑자기 잃어버리는 경우를 구분하는 콜백을 정리한다.
onPartitionsRevoked — 정상적인 리밸런스로 파티션을 반납
onPartitionsRevoked는 구독 변경 등으로 인해 더는 관심 대상이 아닌 파티션이 정리될 때 호출된다 — 이 시점엔 컨슈머가 아직 정상적으로 그룹에 속해 있고, 그 파티션에 대해 지금까지 처리한 만큼 오프셋을 커밋할 기회가 있다. kafka-learn-08에서 다룬 오프셋 커밋 전략이 이 콜백 안에서 실행되는 게 일반적이다.
핵심 포인트
- onPartitionsRevoked: 구독 변경 등으로 더는 관심 대상이 아닌 파티션 정리 시 호출 — 컨슈머가 아직 정상적으로 그룹에 속해 있어 오프셋 커밋 기회가 있음
onPartitionsLost — 리밸런스를 놓쳐 그룹 밖으로 떨어져 나간 경우
onPartitionsLost는 이와 근본적으로 다른 상황을 다룬다 — 멤버가 리밸런스를 놓치고 그룹에서 이미 떨어져 나간 상태에서, 그 시점에 그 컨슈머가 소유하고 있던 모든 파티션 집합에 대해 호출된다. 핵심 차이는 오프셋 처리다 — onPartitionsLost 안에서는 오프셋을 저장(커밋)할 필요가 없다(또는 시도해도 소용없다), 왜냐하면 그 시점에는 이미 그 파티션들을 이 컨슈머가 소유하고 있지 않기 때문이다. 기본 구현은 하위 호환을 위해 onPartitionsRevoked를 그대로 호출하도록 돼 있지만, 이 둘의 의미 차이를 알고 오프셋 커밋 로직을 onPartitionsLost 안에 넣지 않도록 조심해야 한다.
핵심 포인트
- onPartitionsLost: 멤버가 리밸런스를 놓쳐 그룹에서 이미 떨어져 나간 시점에, 그때 소유하고 있던 모든 파티션에 대해 호출
- 이 콜백 안에서는 오프셋 커밋이 불필요(혹은 시도해도 무의미) — 그 시점에 이미 그 파티션을 소유하고 있지 않기 때문. 기본 구현은 하위호환을 위해 onPartitionsRevoked를 그대로 호출
리밸런스 프로토콜별 호출 차이 — Eager vs Cooperative
kafka-learn-01(FAQ)에서 다룬 Eager vs Cooperative 리밸런싱 방식에 따라 이 두 콜백의 호출 조건도 달라진다. Eager 리밸런싱에서는 onPartitionsRevoked가 리밸런스 시작 시 항상 호출되지만(전체 파티션을 일단 다 반납하는 방식이므로), onPartitionsLost는 실제로 잃어버린 비어있지 않은 파티션이 있을 때만 호출된다. Cooperative 리밸런싱에서는 두 콜백 모두 실제로 반납·상실된 파티션이 있을 때만 호출된다는 공통 조건을 따른다.
핵심 포인트
- Eager 리밸런싱: onPartitionsRevoked는 리밸런스 시작 시 항상 호출(전체 반납 방식) / onPartitionsLost는 실제로 잃은 파티션이 있을 때만
- Cooperative 리밸런싱: 두 콜백 모두 실제로 반납·상실된 파티션이 있을 때만 호출