fix: 공통 추천 목록의 오래된 인메모리 캐시 제거#800
Conversation
|
Warning Review limit reached
More reviews will be available in 5 minutes and 5 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more credits in the billing tab to continue. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits. 🚦 How do rate limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
Walkthrough
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Suggested reviewers
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 4f763ed65b
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| @ThunderingHerdCaching( | ||
| key = "university:recommend:general:{0}", | ||
| cacheManager = "customCacheManager", | ||
| ttlSec = GENERAL_RECOMMEND_CACHE_TTL_SEC |
There was a problem hiding this comment.
Recompute cached recommendations instead of extending stale values
For this @ThunderingHerdCaching cache, ttlSec does not bound staleness under traffic: ThunderingHerdCachingAspect.refreshCache handles the last-10%-of-TTL path by calling getAndExpire and returning cachedValue, not by proceeding to rebuild from DB. When a popular /univ-apply-infos/recommend key is hit near expiry, a deleted or updated university can keep being served indefinitely unless an explicit prefix eviction runs, so the new 1-hour TTL does not provide the intended freshness window.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@src/main/java/com/example/solidconnection/university/service/GeneralUnivApplyInfoRecommendService.java`:
- Around line 30-39: 현재 getGeneralRecommends의 캐시 키가 termId만 사용해서 termName 변경 시
이전 응답이 TTL 동안 남을 수 있으니, GeneralUnivApplyInfoRecommendService의 캐시 계약을 더 안전하게
고정하세요. Term 갱신/삭제 경로에서 university:recommend:general:{termId}를 evict하도록 추가하거나,
필요하면 캐시 키에 termName 또는 Term 버전을 포함하도록 수정해 응답과 입력 계약이 항상 일치하게 만드세요.
In
`@src/test/java/com/example/solidconnection/university/service/GeneralUnivApplyInfoRecommendServiceTest.java`:
- Around line 44-56: The test setup in GeneralUnivApplyInfoRecommendServiceTest
should clear the general recommendation cache before each test so results stay
isolated. Update setUp() to remove the Redis entry for
university:recommend:general:{termId} after creating the term and before
building currentTermUnivApplyInfos, using the existing cache/redis access used
by the recommendation service or test fixtures. This ensures prior test
responses cannot leak into tests that reuse the same termId.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 7887c5f7-eefc-4c0b-84cf-0046bf0ffcf1
📒 Files selected for processing (4)
src/main/java/com/example/solidconnection/university/service/GeneralUnivApplyInfoRecommendService.javasrc/main/java/com/example/solidconnection/university/service/UnivApplyInfoRecommendService.javasrc/test/java/com/example/solidconnection/university/service/GeneralUnivApplyInfoRecommendServiceTest.javasrc/test/java/com/example/solidconnection/university/service/UnivApplyInfoRecommendServiceTest.java
lsy1307
left a comment
There was a problem hiding this comment.
수고하셨습니다. codex가 지적한 부분만 수정하면 될 것 같은데 다른 pr에서 수정하신다고 하셨으니 이대로 마무리하시면 될 것 같습니다.
관련 이슈
작업 내용
GeneralUnivApplyInfoRecommendService에서 서버 기동 시점에 공통 추천 목록을 저장하던generalRecommends인메모리 캐시를 제거했습니다.termId기준으로 추천 목록 조회 후 Redis에 저장하고 반환termId를 포함했습니다.university:recommend:general:{termId}86400초에서3600초로 낮췄습니다.특이 사항
이번 변경 방식을 선택한 이유는 캐시의 출처를 Redis 하나로 단순화하기 위해서입니다.
기존 방식은 서버 기동 시점에 생성한
generalRecommends인메모리 객체와 Redis 캐시를 함께 사용했습니다. 이 구조에서는 잘못된 추천 응답이 Redis에 저장된 경우DEL university:recommend:general로 Redis 값을 삭제해도, 서버 메모리에 남아 있는 오래된generalRecommends가 같은 값을 다시 Redis에 저장했습니다. 그래서 잘못된 캐싱을 운영에서 해소하려면 결국 서버 재시작이 필요하다는 단점이 있었습니다.이번 변경으로 Redis 캐시가 비워졌을 때 현재 DB 기준으로 추천 목록이 다시 만들어지므로, 데이터 정합성 문제가 생겼을 때 서버 재시작 없이 캐시 삭제만으로 복구할 수 있습니다.
기존 어드민 캐시 무효화는
university:recommend:generalprefix 기반이라, 새 key인university:recommend:general:{termId}도 함께 무효화됩니다.테스트:
bash ./gradlew test --tests GeneralUnivApplyInfoRecommendServiceTest --tests UnivApplyInfoRecommendServiceTest리뷰 요구사항 (선택)
3600초로 낮춘 것이 적절한지 확인 부탁드립니다.ORDER BY RAND()비용을 고려하면 너무 짧은 TTL은 부담이 될 수 있습니다.86400초는 잘못된 추천 데이터가 오래 유지될 수 있어 운영 복구 관점에서 길다고 판단했습니다.termId를 캐시 key에 포함한 방식이 현재 term 변경 시나리오에 충분한지도 함께 봐주시면 좋겠습니다.