안녕하세요. 11:18분쯤 전체 사용자 조회할 때 강의에서 오류가 나지 않아서 여쭈어봅니다.. apigateway 에서는 yml파일을 바라보는 파일이 ecommerce 이고, user-service에서는 user-service yml파일을 바라보고 있는데 두 개의 secret key 값이 다른데 오류가 안나는 게 정상인가요..? 코드 바뀐 부분을 영상에서 말씀을 안해주셔서 매번 이 강의 깃허브랑, yml 파일들이 들어가있는 깃허브를 확인하면서 진행하는데 깃허브 업데이트가 안된건지 .. 궁금합니다.. 제가 임의로 ecommerce secret key값을 application.yml 파일과 동일하게 하니 오류는 해결되었는데.. 강사님 영상 보면서 할 때 오류가 나지 않아야 한다면 제가 잘못 한건지 궁금해요.. https://github.com/joneconsulting/new-toy-msa/blob/ch10-1/apigateway-service/src/main/resources/bootstrap.yml https://github.com/joneconsulting/spring-cloud-config/blob/master/ecommerce.yml
1. retries가 Integer.MAX_VALUE로 설정되는 이유? 아래와 같은 이유로 retries가 Integer.MAX_VALUE로 설정되는 것인지 궁금합니다. 멱등성 프로듀서는 각 파티션 단위에서만 멱등성이 보장되는 것으로 알고 있습니다. (SID를 브로커의 메모리에 저장하기 때문에) 레코드에 key가 없고 라운드로빈으로 파티션을 결정하는 형태라는 가정하에서, 강의에서 소개해주신 예제(프로듀서가 레코드를 정상적으로 보냈으나 네트워크 이슈 등으로 ack를 받지 못한 케이스)를 생각해봤을 때, retries를 Integer_MAX_VALUE로 설정한 이유는 다른 파티션으로 레코드를 보내는 상황을 막기 위함인 건가요? 위 예제의 강의 자료내 그림에 대해서도 질문이 있는데, ack를 받지 못했을 때 send()를 통해 다시 보내는 것처럼 그림이 되어 있는데, 이것이 실제로 프로듀서가 다시 send() 하는 것을 의미하신 건지, retry를 의미하신 건지 궁금합니다. 2. retries를 Integer.MAX_VALUE로 설정되어도 괜찮은가요? 네트워크 순단 등은 괜찮을 것 같은데 애플리케이션과 카프카 브로커 간 장기적인 네트워크 문제가 발생한다면 retries Integer.MAX_VALUE 설정은 단일실패지점이 되지 않을까 싶은 생각이 들었습니다.(데이터 정합성도 중요하지만 애플리케이션에서 다른 여러 서비스를 운영하고 있을 경우 서비스의 지속성이 더 중요할 경우) 이런 점을 고려하여 멱등성 프로듀서를 사용할 때는 애플리케이션 내에서 프로듀서를 별도의 스레드 풀로 관리하는 비동기 처리, 비동기 큐 관리(Backpressure 등)을 반드시 마련해야하는지 궁금합니다.
안녕하세요! 이번에 카프카를 처음 접해본 초보 개발자입니다. 이번 카프카를 공부하면서 프로젝트로 여러 사람들이 채팅방에서 채팅하는 기능을 만들어보고싶은데요.. 몇가지 질문이 있어 문의드립니다! webflux를 사용한 비동기 식을 채팅을 구현하려고 합니다. 그래서 알아보니 reactor-kafka란게 있던데 실제 현업에서도 reactor-kafka를 사용해서 구현을 할까요..?? 하나의 채팅방 토픽이 있을 때, A유저가 메시지를 보내면, 다른 유저들에게도 메시지를 브로드캐스트로 전달해야하는데.. 이때 보통 어떤 방식을 하는지 알고싶습니다.. 각 유저마다 컨슈머 아이디를 따로 줘야하는지..... 메시지는 쌓이는데 어떻게 전달해야할지.. 잘 감이 안잡힙니다.. 프로듀서를 통해 전달된 데이터를 카프카가 뒷단 레디스에 채팅 데이터를 시키려고 합니다. 이때.. 새로 들어온 유저들은 이전 채팅이력을 받아와야한다면, 레디스에서 바로 가져오는게 좋을까요? 아니면 카프카에 있는 데이터를 삭제 설정을 길게 두고 카프카에서 바로 가져가게 하는게 좋을까요...;;
지금은 멀티 모듈로 프로젝트를 설정해서 common이라는 공통 모듈로 분리해도 문제가 없을 것 같은데, 정말 개발 환경이 달라지면 어떻게 진행이 되나요? 예를 들어, board는 java, comment는 python으로 개발이 된다고 하면, board와 comment에 사용될 common을 팀끼리 약속을 해두고 각각 서버에 구현을 해서 사용하게 되나요?
안녕하세요 cdc를 현업에 적용시키려고 하는데 노하우가 없어 문의 드립니다. 현재 maria db mmm이중화 솔루션을 사용하고있는데, CDC적용 시 마스터를 바라보게 하여 failover를 적용하는게 맞나요?? 혹시모를 장애떄문에, 슬레이브에 binlog 및 gtid를 킨 후 도메인으로 묶어서 주키퍼 등을 사용해 failover를 생각해봤으나 너무 복잡해지는 것 같아 연락 드립니다. 보통 현업에서는 어떻게 사용하는지 의견들을 수 있을까요
CommonService 클래스 부분에서 이 코드 테스트를 하며 생각을 해봤는데요 EX) 루트 댓글 A(논리삭제) ㄴ 댓글 B ㄴ 대댓글 C 상황인 경우에서 B를 삭제했을 경우에 논리 삭제 되어있던 루트 댓글A도 삭제가 되면서 루트 댓글 A(물리삭제) ㄴ 댓글 B(물리삭제) ㄴ 대댓글 C 이런 상황으로 된다면 대댓글 C는 물리삭제 된 루트 댓글A를 parent로 가지는 고아 댓글이 되어버리는 것은 아닌가 궁금해서요!! 깔끔하게 딥한 강의 너무 잘 듣고 있어요!! 감사합니다 :)
코드를 한줄 한줄 같이 치면서 학습을 하는데요, 강사님께서도 코드 한줄 한줄 같이 치신다고 하셨으나 이번 , 다음 강의에서는 yml, controller, service, vo등 모든 것이 작성이 되어있더라고요. 따로 설명 하는 부분 없이 바로 서버 실행 하시는 거 보고 당황했습니다. 코드를 직접 쳐가면서 학습을 하고 싶은데 그러지 못한거 같아 아쉽고, 어디 까지 깃허브에서 코드를 가져와서 사용해야 하나 궁금합니다.
127, 128 섹션 관련 문의드립니다. 2개의 오더 마이크로서비스 각각에 연결된 데이터베이스로 인한 동기화 문제를 위해 카프카 커넥터를 활용하여 하나의 단일 디비로 문제를 처리한다고 하셨는데, 결국 2개의 오더 마이크로서비스에 카프카 커넥터를 사용하지 않고 동일한 디비 1개를 직접 연결해서 사용하면 동기화 문제가 발생하지 않는건 마찬가지아닌가요? 동일한 오더 마이크로서비스를 스케일아웃 하는 상황에서 카프카 커넥터를 사용하는게 목적에 맞는지 의아해서 질문드립니다.
안녕하세요 쿠케님 강의 잘 보고 있습니다! 강의를 보다가 갑자기 궁금한 점이 생겨서 질문 드립니다. 샤딩의 기준이 현재는 article_id로 되어 있는데, 특정 샤드에 댓글 데이터가 엄청 생성되어서 불균형하게 저장이 되는 경우도 있을까요?? 있다면 샤딩의 기준을 다시 정의하는 일도 있는지 궁금합니다. 항상 잘 보고 있습니다. 감사합니다.
안녕하세요! 강의 잘 듣고 있습니다. 좋은 강의 감사합니다. 실습하다가 오류가 생겨 문의 드립니다. void like(Long articleId, Long userId, String lockType) { restClient.post() .uri("/v1/article-likes/articles/{articleId}/users/{userId}/" + lockType, articleId, userId) .retrieve(); } @Test void likePerformanceTest() throws InterruptedException { ExecutorService executorService = Executors.newFixedThreadPool(100); // 100개의 스레드 풀 생성 // 각 lock type별로 테스트 likePerformanceTest(executorService, 1111L, "pessimistic-lock-1"); likePerformanceTest(executorService, 2222L, "pessimistic-lock-2"); likePerformanceTest(executorService, 3333L, "optimistic-lock"); } void likePerformanceTest(ExecutorService executorService, Long articleId, String lockType) throws InterruptedException { CountDownLatch latch = new CountDownLatch(3000); System.out.println(lockType = " start"); like(articleId, 1L, lockType); long start = System.nanoTime(); for (int i = 0; i < 3000; i++) { long userId = i + 2; // String finalLockType = lockType; executorService.submit(() -> { like(articleId, userId, lockType); latch.countDown(); }); } latch.await(); long end = System.nanoTime(); System.out.println("lockType = " + lockType + ", time = " + (end - start) / 1_000_000 + " ms"); System.out.println(lockType + " end"); Long count = restClient.get() .uri("/v1/article-likes/articles/{articleId}/count", articleId) .retrieve() .body(Long.class); System.out.println("count = " + count); } 여기서 '람다 식에 사용되는 변수는 final 또는 유사 final이어야 합니다' 라는 오류가 뜨더라고요. // String finalLockType = lockType; 부분 주석 해제하고 람다 내부에 like(articleId, userId, finalLockType); 으로 하면 start lockType = start, time = 914 ms start end count = 0 start lockType = start, time = 589 ms start end count = 0 start lockType = start, time = 567 ms start end count = 0 으로 출력도 잘 안 나옵니다. 애플리케이션 콘솔에는 아래 로고만 찍히고 나머지는 안 나옵니다. Hibernate: select alc1_0.article_id,alc1_ 0.like _count,alc1_0.version from article_like_count alc1_0 where alc1_0.article_id=? Hibernate: select alc1_0.article_id,alc1_ 0.like _count,alc1_0.version from article_like_count alc1_0 where alc1_0.article_id=? Hibernate: select alc1_0.article_id,alc1_ 0.like _count,alc1_0.version from article_like_count alc1_0 where alc1_0.article_id=? 어느 부분이 문제일까요? ArticleLikeController에서 count 경로는 테스트처럼 뒤에 /count 추가했습니다.
운영중인 서비스에서 선착순 100명 이벤트를 적용한다고 가정하겠습니다. redis를 통해 100명을 제한했고, kafka를 적용하여 부하를 줄여주는 것은 까지는 이해했습니다. 부하를 줄이는 방법이 kafka를 적용할때 때 provider가 topic을 생성하고 consumer가 topic을 가져와서 DB에 입력하는 작업을 하는 것으로 이해했는데요. 만약 이게 실제 운영 환경이라고 가정했을때 궁금한것은 다음과 같습니다. 사용자가 이벤트 신청 redis에서 쿠폰 생성 수량 확인 결과 생성 가능한 조건 임으로 새로운 쿠폰 발급 provider가 새로운 토픽을 생성 토픽을 생성한 그 순간 바로 직후, 사용자는 새로운 쿠폰이 발급된 것으로 확인 해야함. 그치만 consumer에서 topic을 가져오기 전으로 DB에는 새로운 쿠폰이 생성되지 않음. 쿠폰을 사용(또는 확인) 하려고 DB에서 select해보니 쿠폰이 없음 consumer가 이제서야 쿠폰 생성 이 경우에서 보는 것과 같이. provider가 topic을 생성하고 consumer가 topic을 가져와서 DB에 넣는 과정 사이에 사용자가 select를 진행하는 케이스가 있을것같습니다. 이 부분은 어떻게 해결할 수 있을까요? 혹시 다음과 같이 해결 할 수 있을까요? provider가 topic을 생성하는 과정에서 발급 내역을 redis에 입력 consumer가 모든 토픽을 전부 사용하여 DB에 입력하기 전까지 redis에 입력되어 있는 쿠폰 정보로 사용자에게 보여줌 consumer가 모든 토픽을 사용했을때(= 생성된 모든 쿠폰정보를 DB에 입력했을때) redis에 있는 쿠폰정보는 삭제하고 DB에서 select해서 보여줌. 궁금합니다.
