화질 문의

안녕하세요 😊제가 인프런 앱으로 몇 개 확인해 보니 그렇게 화질이 나쁘지는 않은거 같긴한데..혹시 어떤 강의 일까요?그리고 데스크탑에서도 동일하게 화질이 안좋을까요??

안녕하세요.

안녕하세요. 😊강의 자료를 하나씩 올리도록 하겠습니다.수강해 주셔서 감사합니다. ^^

Redis 비동기 I/O 멀티플렉싱이 아니라 논블로킹 I/O 멀티플렉싱이 아닌가요?

안녕하세요! 좋은 질문 감사합니다.말씀하신 내용이 정확합니다.말씀해 주신 것처럼 Redis는 논블로킹 소켓과 epoll(Linux 기준)을 활용하여 여러 소켓의 I/O 준비 상태를 확인하고 실제 데이터 읽기는 read() 계열 함수를 호출하는 방식으로 처리합니다.따라서 운영체제의 I/O 모델을 엄밀하게 구분한다면, Redis는 논블로킹 I/O + I/O 멀티플렉싱을 사용하는 동기 I/O 모델이라고 설명하는 것이 더 정확합니다.강의에서 '비동기 I/O 멀티플렉싱'이라고 표현한 것은 Redis가 특정 클라이언트의 네트워크 I/O를 기다리느라 멈춰 있지 않고 이벤트 루프를 통해 여러 클라이언트의 요청을 효율적으로 처리한다는 점을 쉽게 설명하기 위해 조금 포괄적으로 사용한 표현이었습니다.다만 말씀하신 것처럼 기술적으로 엄밀하게는 '논블로킹 I/O와 I/O 멀티플렉싱' 이라고 표현하는 것이 맞습니다.참고로 이 부분에 대한 상세한 내용은 제 유튜브 채널의 Redis 영상에서도 다루고 있습니다.아래 영상의 7분 20초 부분에서 Redis의 I/O 멀티플렉싱 동작 원리를 설명하고 있으니 함께 참고하시면 좋을 것 같습니다.https://youtu.be/H-jSrhvnaLY?si=-oMBYx85fB8lTt4M좋은 질문과 꼼꼼한 피드백 감사드립니다.앞으로도 궁금한 점이 있다면 언제든 질문해 주세요!

최근 N개 데이터 표현 시 중복 질문

네, 맞습니다. 😊Redis의 List는 중복을 허용하기 때문에 말씀하신 것처럼[101, 102, 103, 104, 105] 에서 다시 103을 LPUSH하고 LTRIM 0 4를 하면[103, 101, 102, 103, 104]처럼 중복이 생길 수 있습니다.그래서 최근 본 상품처럼 동일 항목을 하나만 유지해야 한다면 List를 사용할 경우 보통LREM → LPUSH → LTRIM순서로 처리합니다. 강의 중, 패턴 02: 최근 본 상품 리스트 구현 (Lists) 에서도 해당 내용을 안내하고 있습니다.그리고 또 다른 방법으로는 Sorted Set(ZSET) 을 사용할 수도 있습니다.상품 ID를 member로, 조회 시간을 score로 저장하는 거죠. 이렇게 하면 중복 없이 최근 N개 데이터를 표현할 수 있습니다.

강의 교재가 있나요?

안녕하세요. 각 화면 하단에 '수업노트보기'라는 버튼이 있습니다.이 버튼을 클릭하면 해당 수업에 대한 간단한 코멘트와 실습이 있을 경우 전체 소스가 제공됩니다.확인 부탁 드립니다. 😊(사진)

pub/sub의 연결 객체에 대해 질문 드립니다.

안녕하세요. 😊제가 언급한 "클라이언트 수만큼 pub/sub 연결을 하면 안된다."라는 말은 Redis 클라이언트가 아니라 브라우저를 말한 겁니다.아래와 같은 구조에서[사용자(브라우저) - 애플리케이션 - Redis]새로운 사용자(브라우저)가 접속할 때마다, 애플리케이션에서 Redis로 pub/sub 연결을 하기 때문에 문제라고 한 것입니다.그래서 정상적인 구조는애플리케이션에서 Redis로의 pub/sub 연결은 이 애플리케이션의 생명 주기 동안 1개만 유지하고, 여러 사용자(여러 브라우저)에게는 애플리케이션 차원에서 큐(Queue)와 클라이언트 목록으로 관리해서 메시지를 나눠주는 방식(Fan-out)을 사용합니다.(바로 다음 강의 [패턴 09-개선: FastAPI + Pub/Sub 연동 구조 개선] 에서 개선된 샘플을 제공하고 있습니다.즉, Redis 구독 연결은 애플리케이션(서버 프로세스)당 1개로 고정하고, 그 연결로 받은 메시지를 애플리케이션 메모리 안에서 각 브라우저 연결(Queue)에 전달해주는 거죠. 그래서 브라우저가 100명이든 10,000명이든 Redis 입장에서 보는 구독 연결은 항상 1개입니다.제가 표현을 단순히 Redis 클라이언트라고만 해서 혼란이 있었나 봅니다. 😊

인기 게시판 목록(Sorted set)

안녕하세요.Redis로 좋아요를 관리해야 될 수준으로 트래픽이 많은가 보네요.둘 중 하나를 고른다면 1번을 추천드립니다.2번 방법은 얻는 것에 비해 복잡성이 너무 커 보이네요.1번으로 했을 때, RDB에서 가져온 10개를 어플리케이션에서 다시 정렬하는 방법과 DB쿼리할 때 정렬하는 방법 둘 중에서 하나를 사용하시면 될 거 같아요.(1) 어플리케이션에서 최종 정렬Redis 에서 받은 순서 기준으로 Map을 생성해서 RDB 조회 결과를 Map기준으로 최종 정렬(2) RDB 쿼리할 때 정렬 요청MySQL의 경우 ORDERBY FIELD(id,...) 형태로 쿼리(MySQL이 아니라면 해당 DB에 맞는 정렬 쿼리 사용)(1), (2) 중에서 선택- FIELD 는 표준 쿼리가 아니기 때문에 다른 RDB와의 호환성 문제가 있음- 만을 RDB가 어떤것이든 상관 없이 동작하도록 하고 싶을 경우 (1)번 방법인 어플리케이션에서 최종 정렬함조회된 게시물 수가 10개 이기 때문에 이 정도를 다시 정렬하는 것은 거의 비용이 들지 않습니다.실제로 실무에서 많이 사용하는 형태입니다.

레디스로 재고 관리

안녕하세요! 두 질문 모두 같은 핵심을 담고 있네요. Redis의 재고 감소와 DB 반영의 정합성에 대한 문제네요. 가장 심플한 구조Lua Script로 Redis 작업을 처리한 뒤 바로 DB에 반영하는 방법이 있어요.다만 이 구조는 Redis 성공 + DB 실패 시 정합성이 깨지는 문제가 있어요. 그래서 말씀하신 대로 중간에 큐를 두는 접근이 좋습니다. (1번 질문) Redis Stream + Worker + DB제안하신 구조도 괜찮은 접근입니다. 다만 Worker 실패 시 재처리 전략을 검토해 주세요.처리 완료 → XACK미처리 메시지 확인 및 재처리 → XPENDING중복처리에 대한 멱득성 보장한 가지 더, Redis Stream은 인메모리 기반이라 Redis 장애 시 데이터 유실 가능성이 있어요. 프로덕션 환경이라면 AOF 설정을 반드시 활성화하세요. (2번 질문) Kafka 추가1번 구조에서 Worker → DB 사이에 Kafka가 추가된 구조네요. Kafka를 추가하면 Consumer를 여러 개 띄워 처리량을 늘릴 수 있지만 운영 복잡도가 증가합니다. 트래픽이 충분히 커졌을 때 or 완벽한 내구성이 필요할 때 도입하는 걸 권장드립니다.

Lock 해제 문의 드립니다.

안녕하세요. 😊release_lock의 identifier 비교 로직은 "임계영역에 대한 작업 소요 시간이 락의 TTL을 초과했을 때" 를 전제로 한 방어 코드입니다.락을 먼저 잡은 A가 임계영역에 대한 작업이 예상보다 길어져 락의 TTL이 먼저 만료되어 버리면, 락이 자동 삭제되고 다른 요청 B가 새로 락을 획득할 수 있습니다. 이 시점에 A가 작업을 끝내고 아무 검증 없이 DEL을 호출하면 B의 락을 지워버리는 문제가 생깁니다. 그래서 identifier를 비교한 뒤 삭제하면 이를 막을 수 있습니다.또한 GET → DEL 사이에 TTL이 만료되고 다른 요청이 락을 가져가는 상황이 끼어들 수 있기 때문에, Lua 스크립트로 원자적으로 묶을 것을 권장드린 것이고요.참고로 강의의 샘플 코드에서는 작업 시간(sleep(2))이 락의 TTL(5초)보다 짧아서 이와 같은 상황이 발생하지는 않겠지만, 실무에서는 DB 응답 지연, 서버 부하 등으로 작업 시간이 예상을 초과하는 일이 발생할 수 있습니다. 그래서 TTL을 작업 예상 시간보다 충분히 크게 설정하는 것이 중요합니다. 그리고 이 코드는 분산락의 기본 원리 이해 직접 구현한 샘플이고요실제 실무에서는 Lua 원자성, 다중 노드 지원(Redlock) 등을 고려해 Redisson(Java), redlock-py(Python) 같은 검증된 라이브러리 도입을 검토하시길 권장합니다.좋은 질문 감사합니다. 👍

레디스로 대기큐 구현 질문

안녕하세요. 😊유투브 영상을 보셨군요.백단의 스케줄러가 대기열(Sorted Set)에서 입장시킬 수 있는 수 만큼 뽑아서 Active User에 넣습니다. Active User에 있는 유저는 입장 허가를 받은 거죠. 이 시점부터 예매 페이지로 가서 출발시간과 좌석수 등을 선택해서 예매를 진행할 수 있게 됩니다. (이때 Active User는 개별 유저에 대해 TTL을 설정해야 하기 때문에 Redis의 String이 적합합니다. 키 예시: active:user:{uuid})그리고 나서, 유저가 최종 예매 버튼을 클릭하면 (여러 유저가 동시에 요청을 할 수 있기 때문에) 해당 시간에 남은 좌석수를 Redis의 Lua Script나 Functions를 사용해 원자적으로 계산해서 최종 예매 처리를 합니다.(예매처리는 RDB로 최종 쓰기 작업을 할 수도 있고, MQ로 보낼 수도 있습니다)화이팅입니다. 👍