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

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

[가상 면접 사례로 배우는 대규모 시스템 설계 기초 2] 2장 - 주변 친구1장의 근접성 서비스는 사업장 위치를 다뤘다. 사업장 주소는 거의 바뀌지 않는 정적인 데이터였다. 2장의 주변 친구는 다르다. 사용자는 계속 움직이고, 위치는 몇 초 단위로 바뀐다. 자주 바뀌는 위치를 어떻게 실시간에 가깝게 친구들에게 전달할 것인가가 이번 장의 핵심이었다.1단계: 문제 이해 및 설계 범위 확정면접관과 합의한 조건은 다음과 같았다.'주변'의 기준은 반경 5마일이고, 이 값은 설정할 수 있다.거리는 친구 사이의 직선 거리로 계산한다. 강이나 도로 같은 장애물은 고려하지 않는다.전체 사용자 10억 명 중 10% 정도가 주변 친구 기능을 쓴다.사용자의 위치 이동 이력은 따로 보관한다. 나중에 머신러닝 등에 쓸 수 있다...