Rate Limiter 강의 그림으로 된 예제에 대해 질문있습니다!트랜젝션 시작을 알리는 "MULTI" 명령어 이후 "EXPIRE 1.1.1.1:10 60 / EXEC" 코드가 있습니다! 제가 잘못 이해한 걸 수도 있지만, 이렇게 하면 요청마다 만료 시간이 다시 1분으로 초기화되는 것이 아닌지 궁금합니다. 그러면 1분 안에 요청 수를 제한하는 것이 아니라 1분 안에 요청이 없으면 만료되는 형식이 될 것 같은데 제가 생각한 것이 맞을까요?

사용자가 온라인 된 경우 1로 bit를 업데이트 하고이후에 통신이 되지 않으면 비트값이 추가로 업데이트 되지 않는다 설명하셨는데그 사이에 어떤 동작으로 통신이 되지 않는지 여부를 확인하는지, 비트는 어떻게 처리되는지에 대한 설명이 없어 이해가 어렵네요.매 분마다 요청이 온다는 가정하에 비트값을 매분마다 1씩 업데이트 하는데, 해당 요청이 없어서 비트값이 더 이상 업데이트 하지 않게 되면, 해당 시간만큼 오프라인 상태였다이 시나리오가 맞을까요?그렇다면 서버에서 임의의 시간, 예시로 3분 이상 미 접속시 오프라인이라 평가하여 커뮤니티 웹, 온라인 게임이나 채팅 등의 사용자의 온라인 여부가 필요한 서비스에서 해당 값을 참고하여 특정 시간에서 부터 bit 증가가 없다면 오프라인이라 평가하게 된다고 보면 될까요?그런데 이렇게 하면 시:분으로 시작하는 key로 부터 bit는 접속하게 되는 분 단위가 되는거고, 다른 사용자가 이 사용자의 온라인 상태를 알고자 한다면, 현재 시간에서 key와 bit를 연산한 시간을 비교해야 온라인인지 여부를 알 수 있게 되는건데 제가 이해하고 있는게 맞는지 알고 싶습니다.

해당 클래스의 주된 내용은 동시 로그인 제한으로 이해를 했습니다.그런데 설명을 해주시는 부분에 있어서 set-cookie 부분에서 부터 이해가 잘 되지 않네요.먼저 설명 부분에 있어서set-cookie로 session id를 보내고갑자기 결제가 필요한 유료 api에 접근을 요청하고redis의 캐시에서 해당 유저가 프리미엄 등급임을 확인하고유료 api 요청을 처리한다 하셨는데동시 로그인 제한이라면 pc나 모바일 등 여러 장비에서 접속하는 session의 처리를 의미하는거라 생각이 됩니다.그리고 redis의 캐시로 프리미엄 등급을 확인한다는것도 이해가 되지 않는게 해당 데이터는 캐시로 다뤄질 데이터가 아니지 않나요?초반 설명하셨던 동시 로그인 제한이란 소주제의 목적이다이어그램을 통해 설명한 내용과 다른것 같습니다.혹시 제가 이해한게 잘못된 것인지 알고 싶습니다.n(로그인 세션)

1.1.1.1:10 으로 key가 만들어 졌을 때, 만료가 11분이 되는건가요?설명에는 10분에서 11분까지로 알려주시던데20이라는 요청 제한 수는 프로그램에서 관리하는 수가 되는거죠?다이어 그림에 expire 1.1.1.1:10 60 / exec 의 의미는 무엇인가요?

ZRANGE points 0 -1 REV WITHSCORES위 명령어를 입력하면 ERR syntax error가 발생합니다.gpt로 확인하니 ZREVRANGE points 0 -1 WITHSCORES를 제시해주고결과도 역순으로 출력이 됩니다.rev 지원이 안되는거 같은데 버전의 차이 등의 이슈가 있는 것인지 알고 싶습니다.

안녕하세요.  강의를 잘 보고 있는 와중에 온라인 상태 표시 관련한 궁금증이 생겨서 질문을 남기게 됐습니다. (※ 다른 분이 남겨주신 온라인 상태 표시 질문 글도 읽었습니다.) Bitamps의 장점은 하나의 key에서 offset을 사용하여 값을 비트별로 나눠서 읽고 쓰기 때문에 적은 메모리와 빠른 비트 연산을 제공한다고 생각이 되는데요.올려주신 예시를 보면 key는 계속해서 바뀌고 있고, offset도 전혀 사용하지 않는 것 같습니다.해당 상황에서도 일반적인 Strings 대신에 Bitamps를 쓰신 특별한 이유가 있는지 궁금합니다.   

이미 레디스 cli가 띄워져 있다고 해서요..

안녕하세요 제로초님!  같이 프로젝트를 진행한 동기가 말하기를 "서비스에 join 작업이 많은 데이터의 반복적인 요청이 많을때에는 lazy loading 이슈가 있을 수 있기 때문에 mongoDB를 사용하는게 좋다" 고 하는데... 이게 무슨 말인지 잘 모르겠습니다. mysql에서 join한 데이터를 반복적으로 조회하는게 lazy loading 이슈가 있을 수 있다는 건 이해가 되지만, mogoDB도 mongoose의 populate를 사용하기 때문에 똑같이 lazy loading 이슈가 있을 수 있는거 아닌가요?