흐름정리 제가 이해한게 맞나요?

쿠폰 100개를 발급해야하고 이 개수는 100을 넘어가면 안됨

-> java synchronized락의 경우 쿠폰 발급을 담당하는 서버가 여러개라면 db에 쿠폰 저장(개수 업데이트) 요청이 동시에 올수 있으므로 race condition 발생

-> redis의 경우 여러 서버가 쿠폰 발급 요청을 보내도 싱글 스레드이므로 쿠폰 발급 수를 정확히 100개로 맞출 수 있음. 하지만 예제의 경우 threadpool을 사용하여 각 스레드별로 쿠폰 발급이 가능하면 바로 db에 쿠폰 저장하는 로직이라서 db 부하가 심함

-> kafka를 도입하여 스레드들이 쿠폰 발급 메세지만 카프카로 보내고 카프카 컨슈머가 이 메세지를 처리하여 db에 쿠폰을 저장함. 컨슈머 그룹에 속한 컨슈머는 현재 하나이므로 메세지 1개씩을 처리함 따라서 db에 부하가 심하지 않음.

안녕하세요, 인프런 AI 인턴입니다. 예비군갈나이님께서 질문하신 내용은 선착순 이벤트 시스템에서의 쿠폰 발급에 관한 이해를 정리하고 계신 것 같습니다. 질문하신 내용에 대해 간단히 요약하고 설명드리겠습니다.

Java Synchronized 락 문제:
- 여러 서버가 있을 때, Java의 synchronized 락은 각 서버의 인스턴스에서만 유효합니다. 즉, 각 서버가 독립적으로 락을 관리하기 때문에 race condition이 발생할 수 있습니다. 이는 중앙 DB에 대한 동시성 문제가 될 수 있습니다.
Redis 사용 이유:
- 여러 서버에서 동시에 쿠폰 발급 요청을 보내더라도, Redis는 싱글 스레드로 동작하므로 정확하게 100개의 쿠폰 발급을 관리할 수 있습니다. 하지만, Redis만 사용하여 각 스레드가 즉시 DB에 쿠폰을 저장하면 높은 부하가 발생할 수 있다는 우려가 있습니다.
Kafka 도입 이점:
- Kafka를 사용하면, 각 서버의 스레드가 쿠폰 발급 요청을 Kafka로 보내고, 이 메시지를 Kafka의 컨슈머가 처리하여 DB에 기록합니다. Kafka 컨슈머는 통상적으로 메시지를 순서대로 처리하며, 이를 통해 DB에 대한 요청을 조절하여 부하를 줄일 수 있습니다.

관련하여, 예비군갈나이님께서 이해하신 내용은 전반적으로 맞습니다. Kafka를 도입하여 메시지 큐를 통해 처리량을 조절할 수 있게 되므로 시스템의 안정성과 효율성을 향상시킬 수 있습니다. Redis는 빠른 동시에 정확한 작업을 보장하며, Kafka는 처리량을 관리하는 데 유리합니다.

기술적으로 좀 더 깊이 이해하고자 하신다면, 이벤트 처리를 위한 여러 가지 방식 같은 자료를 참고하시면 도움이 될 것입니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.

인프런 커뮤니티 질문&답변