안녕하세요, 강의 잘 듣고 있습니다. 양질의 강의 감사드립니다.Sorted Set을 활용한 리더보드 강의 시청 후 궁금한 점이 생겨 질문 남깁니다.Redis 공식 문서에 따르면 Score가 동률일 때 사전순(lexicographical)으로 처리된다고 명시되어 있는데요, 실제 비즈니스 환경에서는 사전순이 아닌 여러 기준을 복합적으로 비교해야 하는 경우가 많을 것 같습니다.Score가 64비트 부동소수점임을 활용해, 자릿수별로 기준을 나누는 방안(예: 1~8자리는 기본 점수, 9~12자리는 2순위 기준, 13~15자리는 3순위 기준 ...)도 생각해 보았습니다. 다만 동률 비교 기준이 많아지거나 기본 점수 자체가 클 경우 double 정밀도 한계로 인해 적용이 어렵겠다는 생각이 들었습니다.실무에서는 이러한 복잡한 동률 상황을 어떤 방식으로 처리하는지 팁을 여쭤봐도 될까요?감사합니다.

안녕하세요, 선생님! 강의 들으면서 Service 및 Cache Handler 구성간 Create/Update <-> Delete 간의 Return Record 여부 차이에 대해 질문드리고자 합니다. 서비스도 그렇고, 핸들러도 그렇고, Return type이 Create/Update는 전달받은 Record를 Entity Context에 적용한 객체인데, delete의 경우 void로 운용하시는 것을 보고 어떤 차이점이 있는지 궁금하여 질문드리게 되었습니다. create, update 모두 반영 이후의 내역을 바로 반환하여 보여준다는 의미로 생각하였는데, delete를 보면 그런 것 같지는 않아서 따로 다른 의미가 있는지(실무에서 이렇게 많이 사용한다던가), 별 의미가 없는지 구체적으로 문의드리고자 합니다. 감사합니다.

안녕하세요. 인덱스를 활용한 조회 성능 개선을 공부하던 중 궁금한 점이 생겨 질문드립니다.현재 저는 OFFSET 기반 pagination을 사용하는 서비스를 개발하고 있으며, 다음과 같은 환경에서 성능 테스트를 진행했습니다.데이터: 약 1,000만 건서버: EC2 t3.smallDB: RDS t4g.microk6 vus1001. 문제 상황초기에는 OFFSET 제한 없이 마지막 페이지까지 이동 가능하도록 구현했습니다.하지만 데이터가 1,000만 건 수준으로 증가하자, 깊은 페이지로 갈수록 조회 속도가 급격히 느려지는 문제를 확인했습니다.2. 고민 및 제약일반적으로 이 문제는 Keyset Pagination(커서 기반)으로 해결하라고 많이 알려져 있습니다.하지만 제 서비스는👉네비게이션 바를 통한 페이지 직접 이동 (ex. 1, 10, 100 페이지 클릭)이 필요하기 때문에 Keyset 방식만으로는 요구사항을 만족시키기 어렵다고 판단했습니다.3. 적용한 개선 방법다음과 같은 방식으로 성능 개선을 진행했습니다.OFFSET 최대 범위를 제한 (최대 10,000 페이지 / OFFSET 100,000)커버링 인덱스 적용조회 방식 개선먼저 ID만 조회 → 이후 필요한 10건만 상세 조회전체 게시글 수(count)는 캐싱 처리4. 성능 개선 결과[Page 10] avg: 1.4s → 700ms p95: 4.5s → 1.8s [Page 100] avg: 17s → 1.18s p95: 24s → 3.3s [Page 1000] avg: 32.1s → 1.7s p95: 59s → 4.27s SQL 쿼리는 분석결과 약 1700MS -> 70MS 까지 단축한 것 같습니다.5. 추가 제약사항로그인 사용자와 비로그인 사용자의 조회 결과가 다름(사용자별 구독 게시글이 포함됨)따라서 캐시는 비로그인 사용자에만 적용위 성능 수치는 로그인 사용자 기준6. 현재 고민위와 같이 개선했지만,👉 여전히 성능이 충분하지 않다고 느끼고 있습니다.특히 궁금한 점은 다음과 같습니다.7. 질문OFFSET 기반 pagination을 유지하면서👉추가로 성능을 개선할 수 있는 방법이 있을까요?다음과 같은 방법들을 고려했는데, 방향성이 맞는지 궁금합니다.RDS를 2개를 사용하여 조회 성능 데이터를 각각 2개의 db가 처리하도록 한다?Keyset + OFFSET 혼합 방식(일반적인 페이지 이동은 Keyset Pagination을 사용하고,사용자가 특정 페이지를 직접 입력하거나 점프하는 경우에만제한적으로 OFFSET 기반 조회를 사용하는 혼합 방식)RDS 스펙 업그레이드또한 에펨코리아(https://www.fmkorea.com/)와 같은 대형 커뮤니티는 제가 원하는 페이지 네이션 방식을 사용하면서 깊은페이지(최대 1만)도 지원하고동시접속자 수십만페이지 수천~수만대량 데이터환경에서도 빠른 조회 성능을 유지하는데👉이러한 서비스들은 어떤 방식으로 pagination 및 조회 성능을 처리하는지 궁금합니다.

레디스 서버 한대가 죽더라도 락의 안전성을 보장하기 위해 3~5대의 다른 레디스 서버도 함꼐 있는거라면 이 서비스의 경우에는 레디스의 데이터를 모두 동기화시키는 작업이 매 요청마다 실행되는 건가요?동기화 시키는 과정에서 TTL 에 작은 차이가 생길 수도 있디고 생각하는데 무시가능한 정도인지요??동기화를 시키지 않는다면 또 그 여러대의 레디스 서버가 봐라봐야할 한 곳이 다시 존재하게 됨으로써 어짜피 똑같은 건 아닌지.. 궁금합니다!

좋아요, 조회수등 단순 카운트에서 Redis를 쓰는 이유중 하나로 RDB 의 병목현상을 말씀해 주셨는데Redis의 INCR 명령어 역시 수만개의 좋아요 처리를 한다면 같은 이유로 병목 현상이 발생하는게 아닌지 궁금합니다.  

다른 분들에게 도움이 될까 글을 작성합니다.  저는 윈도우 환경에서 InteliJ를 사용하고 CLI 화면이 편하기 때문에 WSL를 사용하여 도커를 사용했습니다. 해당 전에 문제 해결들은 자료가 없어서 해결 방안만 말씀드리겠습니다.cloud... gradle 문제 해당 프로젝트가 One Driver에 있기 때문에 클라우드 상에 있는 그레이들이 안되는 것으로 알고 있습니다. 만약 프로젝트가 One Driver에 있다면 One driver 밖으로 이동 시켜주세요WSL 도커를 실행해도 윈도우 환경에서는 컨테이너를 찾지 못하는 경우가 있기 때문에 Window 환경에서 도커를 실행 하세요 해당 예외들이 터진 후에 모든 테스트 로직에 대해 예외가 발생합니다.BackendportfolioApplicationTests > contextLoads() FAILED java.lang.IllegalStateException at DefaultCacheAwareContextLoaderDelegate.java:143 Caused by: java.lang.IllegalStateException at LoadingCache.java:75 Caused by: java.lang.ExceptionInInitializerError at Class.java:-2 Caused by: java.lang.IllegalStateException at DockerClientProviderStrategy.java:277원래 전에는 build와 테스트가 잘 진행되었는데 무슨 일인지 Test에서 도커를 만들지 못하는 문제가 생겼나 봅니다. 저는 테스트에서 사용되는 DB Config들을 사용하는 곳에 주석 처리하고 도커 컴포즈로 DB를 주석 처리하고 테스트에서 사용되는 DB들은 Docker compose에 사용되는 DB를 켜서 사용했습니다. Docker Compose에서 사용되는 DB로 사용되기 싫으시다면 Docker 컨테이너로 따로 만드시면 될 것 같아요 @Target(ElementType.TYPE) @Retention(RetentionPolicy.RUNTIME) @SpringBootTest //@Import({TestDatabaseConfig.class, TestRedisConfig.class}) public @interface IntegrationTest { } docker compose up db redis -d   build 관련 에러들은 어노테이션 설정, gradle 설정, 컴파일 설정 등 많은 이유가 있어 하루 종일 붙잡아도 문제 해결이 안되는 점이 많아 시간으 며칠 잡아 먹었네요 글을 깔끔하게 가독성 좋게 작성하지 못해 아쉽지만 다른 사람들이 똑같은 문제를 맞았을 때 해당 글이 도움이 되길 바랍니다.

안녕하세요. kafka 관련해서 질문이 있습니다.MessageRelay > publishEvent 에서 outbox를 삭제했는데 consumer에서 에러가 발생하면 데이터가 유실되는게 아닌가요?

DataInitializer 자체가 이해가 안되는게 있습니다.Test 환경에서 @Autowired 가 가능한건지 궁금하네요

섹션 2 강의 4 5 6 전부 검은 화면으로 나옵니다. 나머지 강의들은 제대로 영상이 틀어지고요. Inflearn 에서 제공해주는 영상 FAQ의 조치를 다따라 해봤는데도 되지않습니다.

bitmap은 db 테이블에서 정보가 보이지 않던데 , redis 명령어로만 확인이 가능한 건가요??

주제영역3 데이타 조회 문의 입니다. 저는 쿼리문장을 날리면건수가 10개만 조회가됩니다.managed_smartcar_drive_info 테이블를 전체데이타 건수는43000건 정도나옵니다.주제영역4는 실행하면 33건이 나오고있습니다.질문은 주제영역3는 결과가 94건인데..저는 10건이라서 제가 어떤 부분을 잘못한건지?아니면 저사향이고 랜덤으로 자바파일 로그 데이타 생성이므로 문제가 없는 건지 질문드립니다.또한 , 10건이여도 7장이후 분석에서 문제가 없는지 질문합니다.

안녕하세요. 인덱스를 활용한 조회 성능 개선을 공부하던 중 궁금한 점이 생겨 질문드립니다.현재 저는 OFFSET 기반 pagination을 사용하는 서비스를 개발하고 있으며, 다음과 같은 환경에서 성능 테스트를 진행했습니다.데이터: 약 1,000만 건서버: EC2 t3.smallDB: RDS t4g.microk6 vus1001. 문제 상황초기에는 OFFSET 제한 없이 마지막 페이지까지 이동 가능하도록 구현했습니다.하지만 데이터가 1,000만 건 수준으로 증가하자, 깊은 페이지로 갈수록 조회 속도가 급격히 느려지는 문제를 확인했습니다.2. 고민 및 제약일반적으로 이 문제는 Keyset Pagination(커서 기반)으로 해결하라고 많이 알려져 있습니다.하지만 제 서비스는👉네비게이션 바를 통한 페이지 직접 이동 (ex. 1, 10, 100 페이지 클릭)이 필요하기 때문에 Keyset 방식만으로는 요구사항을 만족시키기 어렵다고 판단했습니다.3. 적용한 개선 방법다음과 같은 방식으로 성능 개선을 진행했습니다.OFFSET 최대 범위를 제한 (최대 10,000 페이지 / OFFSET 100,000)커버링 인덱스 적용조회 방식 개선먼저 ID만 조회 → 이후 필요한 10건만 상세 조회전체 게시글 수(count)는 캐싱 처리4. 성능 개선 결과[Page 10] avg: 1.4s → 700ms p95: 4.5s → 1.8s [Page 100] avg: 17s → 1.18s p95: 24s → 3.3s [Page 1000] avg: 32.1s → 1.7s p95: 59s → 4.27s5. 추가 제약사항로그인 사용자와 비로그인 사용자의 조회 결과가 다름(사용자별 구독 게시글이 포함됨)따라서 캐시는 비로그인 사용자에만 적용위 성능 수치는 로그인 사용자 기준6. 현재 고민위와 같이 개선했지만,👉 여전히 성능이 충분하지 않다고 느끼고 있습니다.특히 궁금한 점은 다음과 같습니다.7. 질문OFFSET 기반 pagination을 유지하면서👉추가로 성능을 개선할 수 있는 방법이 있을까요?다음과 같은 방법들을 고려했는데, 방향성이 맞는지 궁금합니다.RDS를 2개를 사용하여 조회 성능 데이터를 각각 2개의 db가 처리하도록 한다?Keyset + OFFSET 혼합 방식 (일반적인 페이지 이동은 Keyset Pagination을 사용하고,사용자가 특정 페이지를 직접 입력하거나 점프하는 경우에만제한적으로 OFFSET 기반 조회를 사용하는 혼합 방식)RDS 스펙 업그레이드또한 에펨코리아(https://www.fmkorea.com/)와 같은 대형 커뮤니티는 제가 원하는 페이지 네이션 방식을 사용하면서 깊은페이지(최대 1만)도 지원하고동시접속자 수십만페이지 수천~수만대량 데이터환경에서도 빠른 조회 성능을 유지하는데👉이러한 서비스들은 어떤 방식으로 pagination 및 조회 성능을 처리하는지 궁금합니다.

1. 현재 학습 진도몇 챕터/몇 강을 수강 중이신가요? 여기까지 이해하신 내용은 무엇인가요?강사님 안녕하세요 :)현재 4-9 낙관적 락, 비관적 락 강의를 수강하는 중이며, 단일 행에 대해 배타 락을 거는 방식을 학습한 후 관련 문의 드립니다. 2. 어려움을 겪는 부분어느 부분에서 막히셨나요?코드의 어떤 로직이 이해가 안 되시나요?어떤 개념이 헷갈리시나요?만약비관적 락(PESSIMISTIC_WRITE) 방식으로 한 테이블의 여러 행에 락을 걸어야 한다면, 아래 두 방식 중 어느 방식이 적절한지 궁금합니다.N번의 DB 조회를 방지하기 위해 아래 1번 방식을 고려했으나, 관련 케이스가 많지 않아 제가 놓치는 부분이 있는지 여쭤보고 싶습니다. 더불어 실무에서는 어떤 방식으로 접근하시는지도 궁금합니다. :) 3. 시도해보신 내용문제 해결을 위해 어떤 시도를 해보셨나요?에러가 발생했다면 어떤 에러인가요?현재 작성하신 코드를 공유해주세요1. IN절 조회 후 락 걸기@Lock(LockModeType.PESSIMISTIC_WRITE)@Query("select p from Product p where p.productNumber in :productNumbers")List<Product> findAllByProductNumberIn(@Param("productNumbers") List<String> productNumbers);만약 1번 방식이 적절하다면, 데드락 방지를 위해 ORDER BY 정렬이 필수인지 궁금합니다.2. 루프를 돌며 조회 후 락 걸기for (String productNumber : productNumbers) { Product product = productRepository.findByProductNumberWithLock(productNumber) .orElseThrow( ··· ); ··· }@Lock(LockModeType.PESSIMISTIC_WRITE)@Query("SELECT p FROM Product p WHERE p.productNumber = :productNumber")Optional<Product> findByProductNumberWithLock(@Param("productNumber") String productNumber); 이렇게 구체적으로 알려주시면, 더 정확하고 도움이 되는 답변을 드릴 수 있습니다!

stream_notices 내부의 event_generator 함수 코드에서 yield f"data: {data}\\n\\n"위의 개행 문자에 이스케이프가 두번 들어가서 메시지가 정상적으로 전송되어도 파싱 오류로 화면에 표시되지 않는 문제가 있는것 같습니다.해결책은 이스케이프 문자를 하나만 사용하면 개행도 정상적으로 되고 문자열도 올바르게 출력됩니다.yield f"data: {data}\n\n"

# Redis 6.2 이상일 경우 GETDEL 사용 권장 # saved_code = await rd.getdel(cache_key)이 코드 사용을 권장하셨는데 입력 값 비교 검증까지 통과하기 전에 값을 가져와서 바로 지워버리면 사용자가 실수로 인증번호 입력을 실패해도 다시 요청하도록 해야하는데 이를 감안하고서라도 GETDEL을 사용해야 한다면 이는 verify_code 함수의 원자성을 지키기 위한 권장 사항인가요?혹은 verify_code 함수에 트랜잭션 관련 설정을 하고 GET과 DEL 호출을 쪼개서 하거나 Redis Functions을 사용하는 것을 고려하는게 더 나은지 궁금합니다. 

docker exec -i my-redis redis-cli -x FUNCTION LOAD REPLACE < coupon_logic.lua위의 기존 코드를 실행시키면 NOAUTH Authentication required 라는 오류가 발생합니다. 이 경우에는 docker exec -i my-redis redis-cli -a <비밀번호> -x FUNCTION LOAD REPLACE < coupon_logic.lua와 같은 형식으로 입력하시면 정상 등록됩니다.경고가 뜨긴 하는데 커맨드라인에 비밀번호를 직접 입력하지 말라고 하는거네요.

보안 설정이 걸려 있어서 그런지 바로 목록에 로컬 레디스가 보이는건 아니고 Connect existing database 누르고 세팅에서 비밀번호를 입력한 후에 add를 해야 정상적으로 목록에 표시됩니다.

안녕하세요. 좋은 강의 감사합니다! docker container로 redis 실습 중 모든 키가 제거되고 backup1,backup2 와 같은 키가 남아있는 현상을 확인했는데 서칭 결과 크롤링 봇에 의한 해킹이라고 진단했습니다.해킹 원인은 public ip를 사용하는 pc에서 포트를 ip 제한 없이 열어서 그런 것으로 추측했습니다.그래서 기존 컨테이너 생성 코드container run --name my-redis -p 6379:6379 redis에서docker run -d \ --name my-secure-redis \ -p 127.0.0.1:6379:6379 \ --restart always \ redis:latest \ redis-server --requirepass "비밀번호" --appendonly yes로 변경하여 local ip 지정 뿐만 아니라 권한 설정, 데이터 백업 등이 설정 된 새로운 컨테이너를 생성했습니다.수정 후 지금까지는 키가 삭제 현상이 다시 나타나지 않았는데 혹시 잘못된 부분이 있으면 지적 부탁 드립니다. 감사합니다!

강의 내용을 듣고 생각했을때 ,대부분의 경우 Redis String 보다 Redis Hash 사용하는게 대부분 이득일것 같다 생각이 들던데...어떻게 사용하고 계시나요 ?? 사실 저는 Redis String 으로 Json 으로 많이 사용했었습니다. 그리고 큰 장애를 경험하지 못했는데요 아무래도 트래픽에 대한 차이인것 같네요

강의 잘 들었습니다.Redis 주로 그냥 일반적으로 메모리에 저장하고 호출하는 정도로만 사용을 하고 있는데요BLPOP ,RPUSH job_queue job1 와 같은 기능은 언제 사용하게 되나요 ??