카프카 컨슈밍 규칙

1. 왜 특정 STG 에서만 데이터를 처리하는가. 

 

그룹 개수: 그룹 ID를 stage 단위로 잡는다면(group.id = stg1-group, stg2-group...) 그룹은 4개. 각 그룹 안에 그 stage의 API 서버 4대가 멤버

각 서버는 애초에 자기한테 할당된 파티션의 메시지만 받게 됨

 

 

2. Offset의 의미

offset은 "파티션 안에서 메시지 하나하나에 매겨진 순번"

 

"커밋된 위치"와 "실제로 처리를 끝낸 위치"가 어긋날 때 생기는 문제

1) 커밋이 처리(DB) 보다 앞서 있으면 → 유실 (건너뜀)

 

 

• 컨슈머가 offset 51~100번 메시지를 poll해서 메모리에 가져옴
• auto-commit 타이머가 돌아서 "100까지 다 처리했다"고 카프카에 먼저 커밋해버림
• 근데 실제로는 51~60번 정도까지만 DB 반영(가격 처리)하다가 서버가 죽음
• 재시작하면 카프카는 "너 100까지 커밋했잖아" 하고 101번부터 줘버림
• 61~100번 사이 가격 변경 이벤트는 영원히 그 컨슈머 인생에서 다시 안 보임 → 데이터 유실

 

 

 

2) 처리(DB) 가 커밋보다 앞서 있으면 → 중복 (다시 처리) — 리밸런싱/재시작 시 흔한 케이스

• 컨슈머 A가 51~60번 메시지를 이미 DB에 반영(가격 UPDATE)
• 아직 auto-commit 주기가 안 돌아서 커밋은 50에 머물러 있는 상태
• 리밸런싱(배포, 재시작, 스케일 조정 등)이 발생하면, 파티션이 컨슈머 B로 넘어감
• B는 카프카에 기록된 "커밋된 offset 50"부터 다시 읽음
• 51~60번은 이미 DB에 반영된 이벤트를 한 번 더 처리하게 되는데, 이때 DB가 "어? 이미 처리된 상태인데?" 하면서 에러