비관적 락, 낙관적 락, 분산 락을 다 써보고 나서야 정리했다지난 글 마지막에 커넥션 풀 데드락 얘기를 했다. 한 스레드가 커넥션 두 개를 잡으려다 서로 물려서 멈추는 상황이었다. 그걸 정리하다 보니 다음 질문이 자연스럽게 따라왔다. 애초에 락은 왜 걸고, 어떤 락을 골라야 하는 걸까.마침 내가 한 프로젝트들에 서로 다른 락이 들어가 있었다. 짠팟에서는 중복 챌린지를 막으려고 DB 비관적 락을 걸었고, Keepit에서는 AI 요약이 중복 실행되는 걸 막으려고 Redis 분산 락을 썼다. 당시엔 "이게 맞는 것 같아서" 골랐는데, 왜 그게 맞았는지 설명해보라고 하면 말이 막혔다. 그래서 이번에 제대로 정리했다.락은 왜 필요한가동시성 문제의 본질은 대부분 갱신 손실(Lost Update) 이다.스레드 A: ..

이번 주제인 메시지 큐와 이벤트 브로커는 일을 나눠서, 기다리지 않고 처리하는 도구다.메시지 큐는 프로젝트에서 "써봤다"고 말하기 쉬운 기술이지만, 막상 "왜 도입했나요?"라는 질문을 받으면 대답이 얕아지기 쉽다고 느꼈다. 그래서 이번에는 어떻게 쓰는지보다 왜 필요한지를 중심으로 정리해 보려 한다.1. 동기와 비동기: 주문 버튼을 누르고 몇 초씩 기다려야 할까?비동기 처리는 요청을 보낸 뒤 응답을 기다리지 않고 다음 작업을 진행하는 방식이다.동기 방식은 응답이 올 때까지 대기한 뒤 다음 작업으로 넘어간다. 사용자가 상품을 주문하면 서버는 이런 일들을 해야 한다.주문 생성 → 결제 처리 → 재고 차감 → 배송 요청 생성 → 알림/이메일 발송 → 주문 정보 저장 → "주문 성공!" 이 작업을 전부 순차적으로..

소개이 장에서는 분산 메시지 큐를 설계한다.메시지 큐의 이점:결합도 완화(Decoupling): 컴포넌트 간의 강한 결합을 제거해 각각 독립적으로 업데이트할 수 있다.향상된 확장성: 생산자 및 소비자는 트래픽에 따라 독립적으로 확장될 수 있다.가용성 향상: 시스템의 한 부분이 중단되어도 다른 부분은 계속 큐와 상호작용한다.더 나은 성능: 생산자는 소비자의 확인을 기다리지 않고 메시지를 생산할 수 있다.대표적인 메시지 큐 구현으로 Kafka, RabbitMQ, RocketMQ, Apache Pulsar, ActiveMQ, ZeroMQ가 있다.엄밀히 말하면 Kafka와 Pulsar는 메시지 큐가 아니라 이벤트 스트리밍 플랫폼이다. 하지만 두 유형의 기능이 서로 수렴하면서 메시지 큐와 이벤트 스트리밍 플랫폼의..