#29 게시글 캐싱시 리스트가 아닌 각각 캐싱하게 변경 #35
Conversation
- redisTemplate json 형식 받을시 값이 깨지지 않게 직렬화하고 클래스 여러개 사용 가능한 bean 등록 - CategoryDTO builder 적용 - ProductSearchController 검색시 초기 캐싱된 게시글로 조회되게 변경 - 사용하지않는 UserDTO RedisHash 삭제 - ProductSearchMapper selectProducts 인자 ProductDTO -> productStatus 변경 - ProductSearchServiceImpl init함수에서 게시글 최대 2000개 redisTemplate에 push - addRedisKeys, findAllProductsByCacheId 게시글 추가시 캐시 추가하는 함수, 캐싱되어있는 게시글 반환 함수 추가 - RedisKeyFactory redisTemplate 에 key 저장시 종류에따라 key반환하는 클래스 생성
- redisTemplate과 Product관련 데이터를 reids에 CRUD하는 것들을 ProdcutDao로 변경 - Product 검색시 필요한 상수 데이터들 ProductDTO로 변경 (검색 갯수, 캐시명, 카테고리 정보)
|
이쪽은 멘토링에서 말씀드린대로 페이지단위 캐싱과 만료시간 조절을 해보시면 좋겠습니다~ |
- ProductDao 추가, RedisTemplate을 이용한 product key 발급 및 bean 등록시 DEFAULT_PRODUCT_SEARCH_CACHE_KEY에 최대 2000개 게시글 등록 - 프로그램 종료시 DEFAULT_PRODUCT_SEARCH_CACHE_KEY 삭제 - 물품 삭제시 물품id값을 이용해 RedisTemplate에 등록되어있는 value의 index를 찾아 삭제 - 물품 조회시 DEFAULT_PRODUCT_SEARCH_CACHE_KEY에 있는 values 를 조회 - 물품 등록시 Product auto-Increment index를 가지고 RedisTemplate에 등록
| // 스프링 컨테이너에서 객체인 빈을 제거하기 전에 DEFAULT_PRODUCT_SEARCH_CACHE_KEY로 redisTemplate에 push된 게시물들 삭제 | ||
| @PreDestroy | ||
| public void destory() { | ||
| deleteProductsInRedisTenplate(ProductDTO.DEFAULT_PRODUCT_SEARCH_CACHE_KEY); |
There was a problem hiding this comment.
서버가 종료될때 캐시를 삭제하는 이유가 뭘까요? 다른 서버에서도 해당 데이터를 사용할텐데요
There was a problem hiding this comment.
서버가 종료될때 캐시를 제거하지 않으면
서버가 재시작 할때 2000개의 중고 물품을 다시
DEFAULT_PRODUCT_SEARCH_CACHE_KEY 키로 중고물품들을
RedisTemplate value에 insert 하기 떄문에 중복이 일어나서 하였습니다.
There was a problem hiding this comment.
WAS의 구동 여부와 상관없이 REDIS의 캐싱 데이터가 있다면 캐싱데이터를 다시로드할 필요는 없을거 같습니다.
WAS단에서 레디스가 구동되는지 체크할수 있는 함수나 방법이 있을까요? 처음 재시작 될때만 해당 2000개를 캐시에 로드하고싶습니다.
| @@ -43,7 +43,12 @@ | |||
| */ | |||
| @GetMapping | |||
| public ProductSearchResponse search(ProductDTO productDTO,CategoryDTO categoryDTO) { | |||
| List<ProductDTO> productDTOList = productSearchService.getProducts(productDTO,categoryDTO); | |||
| String accountId = ProductDTO.DEFAULT_PRODUCT_SEARCH_CACHE_KEY; | |||
There was a problem hiding this comment.
- 이 변수가 user의 id가 맞나요? 아닌 것 같습니다.
- 만약 user의 id로 캐싱하는 것을 유도하신거라면 유저별로 따로 캐시가 생성될 것이고 유저가 100만명이면 얼마나 많은 중복된 게시물들이 캐싱될까요?
There was a problem hiding this comment.
accountID 는 처음 User별 캐싱 키로 사용하려 했을떄 적었던 로컬변수인데
수정이 안된것 같습니다. 변경하겠습니다.
| @@ -43,7 +43,12 @@ | |||
| */ | |||
| @GetMapping | |||
| public ProductSearchResponse search(ProductDTO productDTO,CategoryDTO categoryDTO) { | |||
| List<ProductDTO> productDTOList = productSearchService.getProducts(productDTO,categoryDTO); | |||
| String accountId = ProductDTO.DEFAULT_PRODUCT_SEARCH_CACHE_KEY; | |||
| List<ProductDTO> productDTOList = productSearchService.findAllProductsByCacheId(accountId); | |||
There was a problem hiding this comment.
상수로 캐싱하면 무조건 항상 같은 값이 리턴되지 않나요?
There was a problem hiding this comment.
게시글 검색의 경우 처음에 userID별로 캐싱하려고 했으나
메모리 낭비로 생각하였습니다.
로그인 체크 전에도 캐싱의 KEY가 필요하여
DEFAULT_PRODUCT_SEARCH_CACHE_KEY 상수 String 값에 중고 물품들을
RedisTemplate value에 insert 하여 이용하였습니다.
변경해야할 사항