Pargon Cave Pargon Cave

#Redisson #ShedLock💡 Spring 프로젝트: ShedLock vs Redisson📘 기술 선택 정리 @Scheduler를 이용해 평점을 업데이트하는 기능이며, 하루에 한번 특정 시간에 실행하는 기능이 있다. 기능은 평점을 조회해서 Redis 서버에 저장했다가 특정 시간에 자동 갱신 업데이트를 진행하여 Redis에 있는 데이터를 다른 기능에서 빠르게 조회하여 실행하도록 하는 기능을 구현 중이다. 왜 하필 캐시 인가, 유저테이블을 이용할 수도 있지 않는가? 실시간 업데이트의 부담 감소 > 유저 테이블에 접근해 평점 데이터를 가져오는 경우 실시간 업데이트가 되면 매번 리뷰 DB에서 평점의 평균을 계속 조회 및 계산해야 하므로트래픽이 급증할 때, 서버 부하가 심해진다.캐시는 ‘읽기에 최적..

💡 조회 기능📘 계획 11일 5분 브리핑을 할 예정이기에 준비할 내용을 위해 기능을 정리했다. 권한별로 기능을 보게 되면 피드백 작성은 튜터 전용 기능을 몰아 넣을려고 했지만, URL의 규칙을 고려해서 피드백 요청 기능으로 모았다. 유저 기준 피드백 요청 조회▶ 다건 조회로 , 유저인 경우 조회 할 경우가 다양하다. 1. 튜터 기준으로 조회 2. 문서 기준으로 조회 3. 신청 상태 (대기, 취소 ....) 기준으로 조회 4. 날짜를 기준으로 조회 총 4가지의 개별 경우로 각각있을 것이고, 두 개 이상 조합하는 경우가 있을 것이다. 예를 들어 A튜터를 기준으로 여러개 문서로 신청한 경우, 날짜를 기준으로 신청 상태를 조회 하는 경우도 있을 것이다. 다양한 조..

💡 조회 기능📘 계획 11일 5분 브리핑을 할 예정이기에 준비할 내용을 위해 기능을 정리했다. 권한별로 기능을 보게 되면 피드백 작성은 튜터 전용 기능을 몰아 넣을려고 했지만, URL의 규칙을 고려해서 피드백 요청 기능으로 모았다. 유저 기준 피드백 요청 조회▶ 다건 조회로 , 유저인 경우 조회 할 경우가 다양하다. 1. 튜터 기준으로 조회 2. 문서 기준으로 조회 3. 신청 상태 (대기, 취소 ....) 기준으로 조회 4. 날짜를 기준으로 조회총 4가지의 개별 경우로 각각있을 것이고, 두 개 이상 조합하는 경우가 있을 것이다. 예를 들어 A튜터를 기준으로 여러개 문서로 신청한 경우, 날짜를 기준으로 신청 상태를 조회 하는 경우도 있을 것이다. 다양한 조합..

💡 기능 구현 단계🔄 서비스 전체 흐름로그인한 유저가 피드백 신청을 완료 후 튜터는 신청 내용을 보고 수락할지 여부를 확인해서 수락이면 피드백 작성 한다.이후 유저는 피드백 확인한 다음 피드백의 만족도를 평가해 후기와 함께 리뷰를 남긴다.리뷰는 1~5를 입력한다. API 문서 , ERD 테이블 작성 완료.⚠️ 튜터님의 피드백 내용피브백 신청, 피드백 작성, 리뷰 작성 할 때 중복된 경우는 어떻게 처리 할것인가?알림 실시간은 웹소켓인가? SSE로 할것인가?✨ 회고세세한 부분보다는 전체 흐름과정에 필요한 CRUD를 만들고 나서 업데이트 할때 완료해야 겠다.

#FeedPrep 💡 프로젝트 주제 선정📘 주제 선정(5/27 ~ 5/29)“개발자 취업 준비생에게 실질적인 피드백을 제공하는 유료 플랫폼”을 만들기로 결정.피드백 대상은 자소서, 이력서, 코드 전반으로 설정.MVP 구현 목표와 핵심 기능을 도출하고 역할 기반 기능 설계를 시작함. 🔄 MVP 기능 1. 튜터의 피드백 서비스 (유료 서비스) 학생이 업로드한 자소서/이력서/코드에 대해 튜터가 피드백을 제공.피드백 완료 시 학생은 후기를 남기고 튜터에게 별점을 부여할 수 있음.튜터가 피드백을 거절할 경우, 포인트는 자동 복구 처리됨. 2. 사용자 권한별 서비스 기능유저이력서 파일 업로드 (AWS S3, Presigned URL)튜터 검색 및 조회필터: 관심 기술 스택, 분야, 평점순, 응답 시간..

✅ 1. 캐시 무효화란?캐시는 보통 DB나 외부 API보다 빠른 조회를 위해 저장된 데이터인데,원본 데이터가 바뀌었을 때 이 캐시도 함께 바꿔줘야 일관성이 유지돼.그런데 이걸 어떻게, 언제, 무엇을 무효화할지 정하는 것이 바로 캐시 무효화야.✅ 2. 캐시 무효화 전략대표적인 전략은 3가지:1. Write-through데이터가 변경될 때 DB에 먼저 쓰고, 동시에 캐시도 갱신.캐시와 DB의 일관성이 좋지만, 쓰기 속도가 느려질 수 있음.2. Write-behind (Write-back)변경은 캐시에 먼저 적용하고, 나중에 비동기로 DB에 반영.속도는 빠르지만, 데이터 유실 가능성 존재 (예: 시스템 장애 시).3. Cache-aside (Lazy-loading)읽을 때 캐시에 없으면 DB에서 읽고 캐시에 ..

Testcode에서 발생한 직렬화/역직렬화 문제 증상 commentService.getCommentCount(findByProduct.getId())//계속 null로 반환 ✅ 왜 MockitoBean이 위험했냐?@MockkitoBean = 아무 동작도 없는 가짜 객체메서드 호출하면 null 리턴함네가 new CommentServiceImpl(..., commentCacheService) 했을 때,그 commentCacheService는 아무것도 하지 않는 Mock이었던 것 해결방법 @Autowired private CommentService commentService; @Autowired private CommentCacheService commentCacheService; @Bean..

#cache 💡 Spring 정리: Cashe📘 개념 정리@Cacheable메서드 결과를 캐시에 저장, 다음엔 캐시에서 조회함@CacheEvict캐시 무효화, 즉 삭제. 새로 저장/삭제할 때 주로 사용@CachePut메서드 실행 결과로 캐시 갱신 (잘 안 쓰임)TTL (Time To Live)RedisCacheManager 설정에서 지정, 시간이 지나면 자동 삭제키 전략조건이 많을 경우, "productId:min:max:page:size" 같이 구성캐시 공간 분리서로 다른 응답 타입이면 cache name도 분리해야 안전 private final CommentRepository commentRepository;private final ProductRepository productRepository;..