Redis
1.AOF만으로 충분할까? 더티 체킹 개념을 적용해본 Redis 로그 최적화 실험 ( Redis AOF 실험 )
계기 > 저번에 Redis를 활용해 데이터를 임시로 저장하는 구조를 살펴보면서, 장애가 발생할 경우 저장되기 전 메모리에 있던 모든 데이터가 소실될 수 있다는 점을 예측할 수 있었다. > 그렇다면 이러한 문제를 방지하려면 어떻게 해야 할까? 오늘은 이 문제를 해결할 수
2.Redis는 언제, 왜, 어떻게 써야 할까? ( Redis )
계기 > 약 한달 전. DB 락 전략 - 분산락 에서 Redis 를 언급한 적이 있다. > > 지금 내가 알고있는 Redis라는 건 빠른 저장소와 공용 창고 느낌으로만 알고 있다. 하지만, 아는 내용이 너무 추상적이다 보니 깊이 있게 조사하고 싶어졌다. 목표 Red
3.마스터-슬레이브 복제 실습과 장애 복구 대응 ( Redis )
계기 >이전에 Redis의 AOF(Append Only File) 방식을 실습하며, Dirty Checking 개념을 적용해 변경된 값만 기록하도록 최적화하는 실험을 진행했다. 이 실습을 통해 다음과 같은 한계를 느꼈다 AOF는 데이터 복구에는 강하지만, Redis
4.고가용성 Redis 설계 Sentinel과 Cluster
계기 > >이전 시간에는 Redis의 마스터-슬레이브 복제 전략에 대해 살펴보았다. 이 구조를 통해 서비스가 중단되지 않고 이어서 처리할 수는 있었지만, 장애 발생 시 슬레이브를 수동으로 마스터로 승격해야 한다는 단점이 있었다. Redis 공식 문서를 참고해보니,
5.Redis와 Spring의 @Cacheable 활용 (실습)
계기 > 이전 AOF 에 대해서 배울 떄 Redis를 하나의 저장소 개념으로 접했었다. 하지만 실제로는 Redis를 캐시 개념으로 활용하는 경우가 훨씬 많다. > 그리고 프로젝트에서 Redis를 직접 명령어로 일일이 다루는 코드를 작성하지는 않을 것이다. 예를 들어
6.Redis @Cacheable 사용 중 날짜 포맷 트러블슈팅
문제 > @Cacheable 실습 중 발생한 오류에 대해서 트러블슈팅을 자세하게 기록해보겠다. 에러 메세지에 해답이 다 나와있어서 금방해결하긴 했지만 해결 과정을 체계적으로 정리하여 비슷한 문제를 겪는 개발자에게 도움이 되고자 한다. 원인 분석 에러 메시지 및 로그