순위가 동률일 때의 처리에 대해 질문드립니다.

안녕하세요. 실무에서 부딪힐 만한 좋은 질문 주셨네요. 😊여러 방안이 있을 수 있겠습니다.1. 공동 순위로 처리화면 표시 순서는 애플리케이션에서 담당.(예: 달성 시간, 닉네임 가나다순 등)가장 심플. 안전. 권장. (ZSet의 순위에 영향을 주는게 아니니 깔끔함)(공동순위로 하고 화면 표시만 다르게 해도 대부분의 서비스에서 허용 가능) 2. 먼저 달성한 사람을 상위 순위로점수 + 시간을 하나의 score로 인코딩합니다.score = 실제점수 * scale + (scale - custom_timestamp) scale두 값의 자릿수를 분리하는 상수 custom_timestamp 최댓값보다 커야 함(ex: 10⁹) custom_timestamp먼저 달성한 사람이 더 작은 값이 되도록 해서 높은 순위가 되도록 함계산식: 점수 달성 시각 - 기준 시각(ex: 서비스 출시일)Unix timestamp를 그대로 사용하면, 초 단위로도 10자리라서 scale을 더 크게 잡아야 하고,그만큼 ZSET score의 double 정밀도 한계(~10¹⁵)에서 실제점수에 쓸 수 있는 자릿수가 줄어듦. 따라서 기준 시점을 서비스 출시일로 잡으면 custom_timestamp가 8~9자리로 줄어들어 정밀도 예산을 아낄 수 있음. 3. 3개 이상의 기준 필요시 (1)말씀하신 대로 자릿수를 잘게 쪼개는 방식은 정밀도 한계 때문에 빠르게 무너질 수 있습니다. 이때는 Redis와 다른 자료구조의 역할을 분리하는 것을 생각해 볼 수 있습니다.ZSET: 1차 정렬 기준만 score에 저장 (ex: 점수)Hash 또는 RDBMS: 멤버별 상세 정보 저장 (2차·3차 기준)이후 조회 흐름 (페이징 / Top-N 조회)1) ZSET에서 1차 기준으로 해당 페이지에 해당하는 Top-N 후보 조회 (동점이 많을 수 있는 것을 감안해서 보여줄 개수보다 여유 있게 가져오기)2) Hash 또는 RDBMS에서 후보들의 상세 정보 조회. (RDBMS 사용 시 IN 절 인덱스 쿼리 필수)3) 애플리케이션에서 전체 기준으로 최종 정렬 후 페이지 단위로 응답 4. 3개 이상의 기준 필요시 (2)순위에 영향을 주는 여러 요인을 서비스 내부 공식을 따로 만들어서 최종 계산 값을 score로 사용기타 여러 방안이 있을 수 있겠으나, 대체로 이 범위 안에서 해결 할 수 있을거 같습니다. 좋은 질문 감사합니다. 화이팅입니다. 👍

Redlock 알고리즘 관해 궁금한게 있습니다!

안녕하세요. 질문에 답변 드립니다.1. Redis 노드들끼리 알아서 자동으로 동기화 되는 건 아니고, 클라이언트가 각 노드에 직접 SET NX PX 를 요청합니다. 즉 수동으로 동일한 값을 각 노드에 입력하는 것입니다. (Redis 노드들 끼리는 서로 전혀 모르는 사이입니다.)2. 이렇게 하면 노드마다 미세한 시간 차가 생기는 게 맞습니다. 그래서 Redlock은 "설정 TTL - 락 획득에 걸린 시간"으로 실제 유효 TTL을 다시 계산하고, 이 유효 TTL안에 작업을 끝내도록 합니다. 만일 유효 TTL이 작업하기에 너무 짧으면 락 획득 자체를 포기합니다.

좋아요/조회수 카운팅 병목현상에 대해서 궁금한점이 있습니다.

안녕하세요. 좋은 질문 주셨네요.Redis도 싱글스레드이기 때문에 요청이 몰리면, 줄을 서는 것은 동일합니다.(RDB는 Lock으로 대기를 하는 거지만, 줄을 서는 것은 동일합니다.)다만, 이 둘 간의 처리 속도는 상당히 차이가 납니다.RDB: Lock 획득과 대기, Lock 해제 + Disk 쓰기(or WAL 기록) --> 수십 ~ 수백 마이크로초(µs) 소요Redis INCR: 메모리 연산 1회 --> 수백 나노초(ns) 소요(참고) 1 마이크로초 = 1,000 나노초속도 차이가 100배~1000배 수준이라, 같은 수만 건을 처리할 때 RDB가 병목이 될 가능성이 더 큽니다.물론 Redis도 감당 못 할 수준의 트래픽(초당 수백만 건 이상)이라면 뭔가 튜닝이 필요합니다.

백엔드 서버 코드 변경에서 프론트엔드 서버가 값을 파싱하지 못하는 문제

오. 감사합니다. 😊오타가 있었나 보네요. 수업 노트에 반영 했습니다.정말 열심히 하시네요. 화이팅입니다 👍

강사님 GETDEL 관련해서 질문 있습니다

안녕하세요. 😊날카로운 지적 감사합니다! 코드를 깊이 있게 분석해 주셨네요.말씀하신 대로 GETDEL을 사용하면 값을 읽어옴과 동시에 키가 삭제되므로, 유저가 실수로 오타를 냈을 때 재시도할 기회조차 없이 바로 폐기되어 새 인증번호를 요청해야만 합니다.GETDEL은 아주 엄격한 보안이 요구되는 상황 즉, "단 1회의 비교 시도만 허용(일치 여부와 무관하게 즉시 파기)"하는 완전한 일회성 토큰의 원자성을 보장하고 싶을 때 사용하면 좋은 명령어입니다.하지만 그렇지 않은 일반적인 서비스에서는 사용자 편의성(UX)을 저하시킬 수 있습니다. 현재 작성된 코드 역시 '인증번호가 일치할 경우에만 DEL을 수행'하도록 의도되어 있는데, 제가 GETDEL을 단순 권장 사항으로 덧붙이면서 두 로직 간에 모순이 발생해 버렸습니다.명령어의 원자적 실행이라는 측면에만 포커스를 맞추다 보니, 샘플 코드의 전체 흐름과 충돌하는 설명을 드렸네요. 정확하게 짚어주셔서 감사합니다.그리고 말씀하신대로 인증번호 일치 여부 판단 후, 삭제하는 로직을 루아스크립트로 작성하면 원자성과 사용자 편의성을 모두 만족시킬 수 있습니다.학습에 혼란을 드려 죄송하며, 강의 노트와 내용에 해당 부분에 대한 코멘트를 추가하도록 하겠습니다.훌륭한 시야로 질문 남겨주셔서 다시 한번 감사드리며, 앞으로도 완강까지 화이팅하시길 응원하겠습니다!

비밀번호를 걸고 실행된 레디스 서버에 lua 스크립트를 등록하는 경우

아. 실습 과정에서 비밀번호 설정 때문에 계속 걸리시는 것 같네요. 😊테스트 환경이 공인 IP를 사용하는 경우라도, 127.0.0.1로 바인딩하셨다면 비밀번호 설정까지는 하지 않으셔도 괜찮습니다.계속 진행되는 실습과정에서 불편함을 겪을실까 염려되네요.가능하시다면 아래와 같이 기존 컨테이너를 삭제하고, (비밀번호 설정 없이) 다시 생성하시는 것을 권장드립니다.docker rm -f my-redisdocker run -d --name my-redis -p 127.0.0.1:6379:6379 redis

보안 설정을 한 수강생들은 Connection Settings에 비밀번호를 넣어야 추가되네요

안녕하세요 😊Redis Insight 말씀이시군요. 안내해 주셔서 감사합니다.저도 해당 강의의 노트에 가이드 해 두도록 하겠습니다.감사합니다. 👍

Redis Container 해킹

안녕하세요! 😊아.. 공인 IP가 있는 환경에서 테스트하고 계신가 봐요.말씀하신 현상은 외부에 노출된 Redis에 자동 스캔 봇이 접근했을 가능성이 높고, 설정 변경 방향도 아주 잘 잡으셨습니다.특히 아래 2가지는 가장 중요한 조치입니다:-p 127.0.0.1:6379:6379 → 외부에서 직접 접근 차단 (가장 중요)--requirepass → 인증 없는 접근 방지이 두 가지만으로도 대부분의 자동 스캔/공격은 효과적으로 막을 수 있습니다.

예시 코드가 어디있는지요?

안녕하세요. 소스코드는 각 강의의 수업노트에 있습니다. 😊이른시간에 열공. 화이팅입니다~ 👍

10. 파이썬 클래스와 객체 구현(self의 동작원리) 소스코드

아하. 그렇군요.방금 확인하고 수업노트에 업뎃 했습니다. 죄송해요 ^^