8 asked

0

예비군갈나이님 안녕하세요. 답변이 늦어서 죄송합니다.
이해하신 버전이 맞습니다!

추가적으로 아래와 같은것들이 가능합니다.

1. 더 높은 처리량이 필요하다면 성능테스트를 해보며 적절한 컨슈머 개수를 찾을 수 있습니다.

2. 너무 많은 요청이 온다면 대기열을 만들어 진입점을 조절할 수 있습니다.

0

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

1. Java Synchronized 락 문제:

   • 여러 서버가 있을 때, Java의 synchronized 락은 각 서버의 인스턴스에서만 유효합니다. 즉, 각 서버가 독립적으로 락을 관리하기 때문에 race condition이 발생할 수 있습니다. 이는 중앙 DB에 대한 동시성 문제가 될 수 있습니다.
     

2. Redis 사용 이유:

   • 여러 서버에서 동시에 쿠폰 발급 요청을 보내더라도, Redis는 싱글 스레드로 동작하므로 정확하게 100개의 쿠폰 발급을 관리할 수 있습니다. 하지만, Redis만 사용하여 각 스레드가 즉시 DB에 쿠폰을 저장하면 높은 부하가 발생할 수 있다는 우려가 있습니다.
     

3. Kafka 도입 이점:

   • Kafka를 사용하면, 각 서버의 스레드가 쿠폰 발급 요청을 Kafka로 보내고, 이 메시지를 Kafka의 컨슈머가 처리하여 DB에 기록합니다. Kafka 컨슈머는 통상적으로 메시지를 순서대로 처리하며, 이를 통해 DB에 대한 요청을 조절하여 부하를 줄일 수 있습니다.
     

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

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

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