요청이 완료될 때마다 clearDataSource()를 호출하여 ThreadLocal 변수를 비우는 것이 중요할 것 같네요 🤔
AOP 또는 인터셉터를 사용해 각 요청의 시작과 끝에서 자동으로 데이터 소스를 설정하고 해제하면, 여러 요청이 한 스레드에서 일어날 때도 데이터 소스가 정확하게 선택되도록 구성하면 될 듯해요
현재 clear 함수가 있...
사실 상수 분리, 에러 객체 분리, 원시값 포장을 적용하고 싶었으나 시간 관계상의 문제가 컸어요!
현재 미션에서 집중할 부분이 DB 복제 지연 문제라 생각하여... 복제 지연에 집중했는데
해당 조건들이 있는 이상 구현을 하는 것은 필요한 것 같아 딱 충족하도록 구현을 하였습니다
2단계 PR를 내고 진행해 볼까 싶어요!
> 복제 지연 방식은 read 조회 후 없다면, write를 조회하는 방식을 사용하셨군요👍 해당 방식을 사용한 이유가 궁금합니다~
현재는 가장 합당한 방법이라 생각했습니다! 캐시 서버와 같은 다른 데이터베이스를 사용하지 않고 현재 사용할 수 있는 최선을 찾은 것 같아요!
물론 특정 상황에서는 트래픽이 전부 write로 몰릴 수 있는 가능성은 있...
이 부분은 제가 '모든 읽기 요청'을 강조해서, 헷갈리게 질문을 드렸던 것 같아요😅
(스미마셍..)
제 질문의 의도는,
'로컬 캐시 → 리모트 캐시로 바뀌게 되면 추가적인 네트워크 오버헤드가 발생할텐데 그럼에도 현 구조를 유지할 것인가?'
에 대한 내용이었습니다 ㅎㅎ
로컬 캐시에서 얻는 '빠르다'는 이점이, 리모트 캐시에서는 흐려질 수 ...
조이썬 안녕하세요! 정말 오랜만에 돌아왔습니다.
요것저것 찾아보며 최대한 답글 남겨두었는데, 모호하거나 이상한 부분이 많을 것 같아요. 많은 가르침 부탁드립니다 😅
> 즉시 복제가 보장되어야 하는 로직이라면 바로 writer DB를 사용하도록
설정 때문에 쿠폰을 발급하고, 쿠폰을 조회하는 연산을 모두 WRITE DB 로 쏘게 되었습니다. 이...
구현해보려고 시도했는데, 생각보다 난관에 봉착했습니다 😢
기존 분기는 `@Transactional` 분기인데다 전체적인 테이블 이름을 캐시에 저장해두었는데요, 마크의 방식을 적용하기 위해서는 서비스 차원에서 어떤 ID를 사용하고 있는지를 알아야 하더라고요.
그 중에서도 ID를 활용하는, 그리고 활용하지 않는 메서드들을 분리하는 것도 어려워서 반...
> DataSource라는 같은 타입의 빈을 writerDataSource, readerDataSource, routingDataSource, dataSource라는 이름으로 총 4개나 등록하고 있으니, 스프링컨테이너에서 각 빈을 생성할 때 어떤 빈을 먼저 생성해야 DI 과정에서 문제가 발생하지 않는지 판단하기 어렵나?
스프링에서 빈의 등록 순서...