Gidhub BE Developer

Kafka 커밋 타입 :: 수동 커밋(Manual Commit)

2019-12-26
goodGid

이 글의 코드 및 정보들은 을 바탕으로 작성하였습니다.

Manual Commit

  • 수동 커밋은

  • 자동 커밋과 달리

  • 메시지 처리가 완료될 때까지

  • 메시지를 가져온 것으로 간주되어서는 안 되는 경우에 사용한다.

Example

  • 컨슈머가 메시지를 가져와서

  • DB에 저장하는 상황이라 가정해보자.


  • 만약 자동 커밋을 사용하는 경우라면

  • 자동 커밋의 주기로 인해 poll()하면서

  • 마지막 값의 오프셋을 자동 커밋이 되었고

  • 일부 메시지들은

  • DB에 저장하지 못한 상태로

  • 컨슈머 장애가 발생한다면

  • 해당 메시지들은 손실될 수 있다.


  • 이러한 경우를 방지하기 위해

  • 컨슈머가 메시지를 가져오자마자

  • 커밋을 하는 것이 아니라

  • DB에 메시지를 저장한 후

  • 수동으로 커밋을 해야만 안전하다.

주의 사항

  • 수동 커밋의 경우에도

  • 자동 커밋과 마찬가지로 중복이 발생할 수 있다.

  • 메시지들을 DB에 저장하는 도중에

  • 실패하게 된다면

  • 마지막 커밋된 오프셋부터

  • 메시지를 다시 가져오기 때문에

  • 일부 메시지들은 DB에 중복으로 저장될 수 있다.

// DB에 저장하는 상황에서
// Transaction 단위로 동작하지 않을 경우
// or
// Data Roll Back이 설정되지 않은 경우


100개의 데이터를 50개씩 나눠서 DB에 저장하는데

1~50개의 데이터를 저장하고

51~100개의 데이터를 저장하는데 에러가 발생하면 

카프카는 다시 1~100개의 메시지를 갖고오고

1~50개의 데이터를 중복해서 저장할 수 있다.

Summary

  • 이렇게 카프카에서는

  • 장애 등의 이유로 중복이 발생할 수 있다는 점을 인지해야한다.

  • 하지만 카프카는

  • 중복은 있지만

  • 손실은 없음을 보장한다.


Reference


Recommend

Index