m=32MB짜리 10개와 m=512MB짜리 1개의 경우를 비교해주셨습니다.그런데 이는 샤딩을 통해서 메모리 효율적으로 됐다기 보다는 메모리 총량이 512MB->320MB로 감소했기 때문에 오차율이 조금 증가하는 대신 메모리를 덜 쓸 수 있는 것 아닌가요?예를 들어 320MB 짜리 1개인 경우와 32MB짜리 10개인 경우의 오차율이 똑같지 않나 하는 생각이 들어서 질문드립니다! 

"Split 전략에서 항상 모든 Split을 조회한다."요 부분이 이해가 가지 않아서 질문드립니다!findSplitIndex로 계산한 split에만 접근하는 것 아닌가요?아니면 모든 스플릿이 단일 redis 내에 존재하는 것이 문제라는 의도로 말씀하신걸까요?

@Slf4j @SpringBootTest class SplitBloomFilterRedisHandlerTest extends RedisTestContainerSupport { @Autowired SplitBloomFilterRedisHandler splitBloomFilterRedisHandler; @Test void mightContain() { SplitBloomFilter splitBloomFilter = SplitBloomFilter.create("testId", 1000, 0.01); List<String> values = IntStream.range(0, 1000).mapToObj(idx -> "value" + idx).toList(); for (String value : values) { splitBloomFilterRedisHandler.add(splitBloomFilter, value); } for (String value : values) { boolean result = splitBloomFilterRedisHandler.mightContain(splitBloomFilter, value); assertThat(result).isTrue(); } for (int i = 0; i < 1000; i++) { String value = "notAddedValue" + i; boolean result = splitBloomFilterRedisHandler.mightContain(splitBloomFilter, value); if (result) { log.info("value={}", value); } } } }  위 코드는 SplitBloomFilterRedisHandlerTest 인데요.강의 중 코드입니다 1000 크기에 0.01 오차율의 Bloom Filter 를 만들고1000개의 데이터를 넣고 False Positive 까지 검증해보는 코드인데요.질문입니다Split 전략을 배우기 전에순수한 Bloom Filter 구현 강의에서도 위와 동일한 테스트 코드가 있는데요이 때, 순수한 Bloom Filter 의 한계로써생성한 Bloom Filter 크기를 초과하여 데이터를 넣으면 비트 1이 많아져 오차율이 증가하고그로 인해 False Positive 데이터가 많이 조회되는 현상을 살펴보거든요.그리고 그 해결책으로처음부터 큰 Bloom Filter 를 만드는 것 이외에Split / Sharding / Sub Filter 전략이라고 말씀하시는데요근데 위 Split 전략의 테스트 코드에서 BloomFilter 크기는 1000으로 만들고 데이터를 훨씬 초과하여 2000개 만들어 넣어보면순수한 Bloom Filter 때처럼 False Positive 데이터가 많이 조회됩니다.저는 PC 가 느려서 False Positive 를 1000번으로 조회하였고오차율 (0.01) 에 의하면 약 10개의 False Positive 가 나와야 하는데데이터 1000개를 저장했을 때는 오차율에 맞게 8개로 떨어지는데데이터 2000개를 저장했을 때는 오차율을 훨씬 넘어갑니다제가 코드를 잘못 따라 친건지.. Split 도 원래 그런건지..제 질문 의미가 전달될지는 모르겠지만.. 명확하게 개념 정리가 되지 않아 질문드립니다

강의를 보다가 궁금한 부분들이 생겨 질문드립니다!!1. RateLimit Boundary Burst 관련RateLimit을 설명해주시는 부분을 보면서 한 가지 의문이 들었습니다.예를 들어 1초에 100개로 제한을 두었을 때,0.9초 시점에 100개 요청이 들어오고 1초가 되자마자 다시 100개가 들어온다면실제로는 매우 짧은 시간 안에 200개의 요청이 처리될 수 있지 않을까 하는 생각이 들었습니다.찾아보니 이러한 문제를 Boundary Burst라고 부른다는 것을 알게 되었습니다.이를 해결하기 위해:Sliding WindowSliding Window CounterToken BucketLeaky Bucket등의 방식이 있다는 것을 확인했습니다.실무 관점에서는 이런 경계 구간 Burst 문제를 어떤 방식으로 해결하는지 궁금합니다.2. Request Collapsing 관련Request Collapsing을 설명해주신 부분을 보면서,여러 요청을 하나로 모아서 처리하는 방식으로 Golang의 SingleFlight 패턴을 응용하는 방법도 가능하지 않을까 생각해보았습니다.이와 관련해서 아래와 같은 예제 코드도 작성해 보았습니다.private final StringRedisTemplate redisTemplate; private final Map<String, CompletableFuture<?>> singleFlightMap = new ConcurrentHashMap<>(); @Override public <T> T fetch(String key, Duration ttl, Supplier<T> supplier, Class<T> clazz) { String cached = redisTemplate.opsForValue().get(key); if (cached != null) { return DataSerializer.deserializeOrNull(cached, clazz); } CompletableFuture<T> newFuture = new CompletableFuture<>(); CompletableFuture<T> existing = (CompletableFuture<T>) singleFlightMap.putIfAbsent(key, newFuture); if (existing != null) { // 다른 스레드가 실행 중 → 기다림 return existing.join(); } // 내가 실행자 (락 없이 실행) try { T result = refresh(key, ttl, supplier); newFuture.complete(result); return result; } catch (Throwable t) { newFuture.completeExceptionally(t); throw t; } finally { singleFlightMap.remove(key, newFuture); } } private <T> T refresh(String key, Duration ttl, Supplier<T> dataSourceSupplier) { T result = dataSourceSupplier.get(); put(key, ttl, result); return result; }이 방식은 분산 락이나 폴링 방식 없이도 동일 인스턴스 내 요청을 모을 수 있다는 장점이 있다고 생각했습니다.물론 이 방법은 모든 분산 서버 간 요청을 하나로 모으는 것은 아니기 때문에, 서버 인스턴스 수만큼은 요청이 발생할 수 있다는 한계가 있다고 생각합니다.하지만 인스턴스 수가 많지 않다면, 분산 락으로 인한 오버헤드나 복잡성을 줄이면서도 어느 정도 트래픽을 제어할 수 있는 현실적인 선택지가 될 수 있지 않을까 하는 생각이 들었습니다.실무 관점에서는 이런 방식에 대해 어떻게 평가하시는지 궁금합니다.3. Write Through 방식에서의 장애 처리Write Through 방식에서는 일반적으로:DB에 먼저 저장동일 데이터를 Redis에도 저장하는 구조로 이해하고 있습니다.그런데 만약:DB에는 쓰기 성공Redis에는 쓰기 실패하는 상황이 발생한다면, 이 경우를 트랜잭션 실패로 간주해야 하는지 궁금합니다.Redis 장애로 인해 캐시 반영이 실패했을 때,핵심 트랜잭션(DB 쓰기)까지 롤백해야 하는지아니면 캐시는 보조 저장소로 보고 DB 성공을 기준으로 처리해야 하는지두 저장소 간 원자성을 반드시 보장해야 하는 설계인지 실무에서는 어떤 기준으로 판단하는지 궁금합니다.

안녕하세요! 해당 강의를 통해 redis pipeline과 lua script 활용 법을 눈으로 보고 배울 수 있어서 재밌게 수강하고 있습니다.  AsyncPERStrategy() 메서드를 통해 랜덤한 확률로 레디스의 캐시 데이터를 업데이트 하는 것으로 이해하였습니다. 캐시 데이터를 업데이트를 비동기적으로 처리를 위해 프록시 기반 AOP로 동작하는 @Async 어노테이션을 활용하셨는데, 해당 메서드를 내부호출 함으로써 비동기 처리가 안되는 것으로 예상됩니다! 혹시 제가 잘못 알고있을 수도 있으니 확인 부탁드립니다!

dragonwaterr 로 인증까지 했는데 혹시 안도나요?

링크 타고 들어가서 수락하기 누르면 아래와 같이 뜨는데 어떻게해야할까요 학습 관련 질문을 남겨주세요. 구체적으로 적을수록 좋아요!어떤 섹션, 몇 분 몇 초의 내용인지어떤 부분이 이해가 안 되는지어떤 에러가 발생했는지 (에러 메시지 전체)본인이 시도해 본 방법커뮤니티 질문 & 답변에 비슷한 내용이 있었는지 먼저 검색해보세요.같은 질문이 이미 답변되었을 수 있습니다검색으로 더 빠르게 해결할 수 있어요e

비트맵 자료 구조 강의를 수강하고, 해당 자료구조가 활용되는 상황에 대해 이해하지 못한 부분이 있어 질문 드립니다.강의에서 말씀하신 비트맵을 사용하지 않았을 때 유저마다 고유한 키 값으로 string set으로 저장한다는 의미가 무엇인가요? 유저의 고유 키마다 쿠폰에 대한 set이 있고, 어떤 쿠폰이 발급됐는지 저장하는 구조인가요?강의에서의 상황은 유저가 해당 쿠폰을 발급 받았는지를 식별하기 위한 상황인가요? 해당 정보를 DB가 아닌 레디스에 저장할 이유가 무엇인가요? 아니면 둘 다 저장하는 방식인가요?만약 해당 쿠폰을 발급할 수 있는 기간이 일주일이면 일주일 동안 레디스에 해당 정보가 만료되지 않고 유지되어야 할까요?해당 상황은 쿠폰 번호가 유저마다 다른가요, 다 같은 쿠폰 번호인가요? 만약 다른 쿠폰 번호라면 db에 따로 저장이 되어야 할까요?감사합니다.

 계속해서 똑같은 오류만 나오고있습니다. 오류를 몇시간씩 찾아봤고, 테스트의 버전을 변경하고, 다 지우고 다운로드를 다시받고,jdk버전을 홈 기준 11로도 맞춰보고 다 해봤지만 계속해서 같은 오류가 나는데 어떻게 해결할 수 있을까요?

13:27초에 5단계로 나누어서문제 - 선택지 - 결정 - 구현 - 결과를 이력서에 적으라고하셨는데, 저의 이력서 같은 경우는 아래와 같이 적어두었습니다.프로젝트 개요 - 담당업무 - 성과 이런식으로 적는건 별로일까요?? 

1분30초 ~ 2분 쯤에 말씀해 주시기를 "부하를 100만건을 받는 가상 환경에서", "카프카가 100% 이득인 상황은 언제지?" 등의 긍정적인 예시를 들어주셨습니다. 하지만 면접관의 입장에서 "왜 부하를 100만건 받는 가상 환경을 만드셨나요?" "실제 트래픽이 얼마정도 였길래 100만 건의 부하 테스트를 하신건가요?", "현실적인 목표에 부합하는 부하 테스트를 하신 게 맞을까요?"등의 질문을 할 수 있지 않나요? 그럼 결국에 "학습 목적으로 사용한 kafka = 학습 목적으로 구성한 100만건의 부하 환경"이 된다고 생각합니다.즉 100만건의 부하를 받는 가상 환경을 만든 당위성이 없다고 생각합니다. 그럼 결국 당위성이 만들어지기 위해서는 꽤 많은 유저 트래픽을 받고 있는 사이드 프로젝트를 만들어야 하지 않나 생각이 들어서 질문드립니다. 

1초로하면 현재 성공, 실패 각각 200, 0으로 나오고 2초로 해야 100개 씩 성공하는데 정상인가요?

환경은 windows 11 64비트이구요,자바 21, redis는 물론 docker 8.2.1 실행 중이엇구요 하지만SplitShardedBloomFilterRedisHandlerTest 클래스에 mightContain 테스트 함수 실행 하면 첨부한 이미지 처럼 에러가 출력 됩니다. 아래는 docker 버전 정보입니다. 

 ------------------------------ 해결 방안-------------------------------저와 비슷한 이슈가 있으신분은 이렇게 처리 부탁드립니다! 인텔리제이 설정에서 Preferences > Build, Execution, Deployment > Build Tools > Gradle에서Build and run using : GradleRun tests using : Gradle 이렇게 수정 하고 다시 시도 부탁드립니다!!!  쿠케님 감사합니다 :)    안녕하세요 우선 좋은 강의 만들어주셔서 정말 감사드립니다.GET - http://localhost:8080/cache-strategy/NONE/items/{{itemId}} 해당 API 를 호출 하게 되면ItemController -> KukeCacheAspect -> KukeCacheKeyGenerator -> ItemNoneCacheService  대충 이런 흐름으로 가게 되는데요.KukeCacheKeyGenerator 객체에서 for (int i = 0; i<args.length; i++) { context.setVariable(parameterNames[i], args[i]); } parameterNames 객체에 NPE 에러가 발생 되고 있습니다.코드는 강의 자료실 통해 제공해주신 코드로 실행 해보았습니다. 이 부분 어떻게 수정을 해야 할까요?  

전 질문에 같은 내용이 있긴 한데요.. 설명과 화면이 맞지 않아 좀 당황했습니다.반드시 수정이 필요해 보입니다.. 솔직히 환불하고 싶지만 한 번만 참겠습니다.

다시보기 서비스도 제공하는지 궁금합니다.

common pool을 사용하지 않도록 thread pool을 설정 해야 된다고 주의사항을 적어주셨는데 그 이유는 무엇인가요?그리고 둘의 차이는 onPool-worker-3, pool-1-thread-8 이라고 알려주셨는데 차이가 이거밖에 없는건가요?

Redis란 무엇인가 강의 3:33초 쯤 Redis가 SSD 같은 메모리를 사용한다고 하셨는데 SSD가 메모리인가요?

안녕하세요! 알고 있는 Redis 지식을 복습하고, 또 어떤 새로운 이론이 있나 학습할 겸 강의 수강하고, 완강까지 했습니다. 강의를 들으며 궁금했던 점이 있습니다. 보통 redis-cli 환경에서 명령어를 치는 일이 많이 있는지 궁금합니다.Springboot 백엔드 개발 중 Redis를 도입해서 사용한다고 하면, 애플리케이션 단에서만 활용하고, cli환경에서 사용하는 일도 많이 있을까요!?

카프카에서도 주키퍼라는 것을 통해 클러스터의 노드들에게 주기적으로 ping을 보내 heartbeat?이란걸 체크하여 어떤 클러스터가 다운되었는지 확인하고 다운된 클러스터의 토픽이 리더 파티션이 있으면 다른 클러스터의 파티션에게 리더 파티션을 넘겨주는 역할을 하는 것으로 알고있는데 강의를 보니 sentinel이라는게 비슷한 역할을 하는것 같습니다. 제가 이해한게 맞나요?