[캐시 설계] 가장 기본적인 다단계 캐시가 적합한지, 어떻게 구성해야 하나요?

최근에 저는 우리 시스템을 위한 1단계 캐싱 메커니즘을 구축하고 싶습니다. 하지만 늘 뭔가 부족한 느낌이 듭니다.

환경:
로드 밸런싱, 마스터-슬레이브 분리, Redis 독립형(향후 여러 머신 사용 가능)

현재 예비 아이디어:

<code>浏览器缓存-》本地文件缓存-》内存缓存（Redis）-》Db
</code>

사용자가 웹 애플리케이션에 액세스한 후 해당 웹 애플리케이션에 대한 브라우저 캐시를 설정한 다음 로컬 파일 캐시와 메모리 캐시를 설정합니다.
다른 유저들이 방문한 후, 다음 단계인 것 같아요.

1. 브라우저 캐시가 있는지 확인

2. 로컬 머신에 파일 캐시가 있는지 검색

3. 메모리 캐시

4. DB

내 질문은:

그런데 특정 단계에서 뭔가 빠진 느낌이 들거나 (다단계) 캐시 만료 시간을 선택하기 어렵다고 느껴집니다.

그리고 메모리 캐시(Redis)로 직접 점프하는 단일 연결에 비해 로컬 파일 캐시{만료 시간 확인, 파일 읽기(삭제, 생성)}가 가치가 있나요?

그래서 제가 가지고 있는 기본 캐싱 메커니즘이 적합한지, 아니면 개선할 수 있는 단점이 있는지 여쭤보고 싶습니다. 감사합니다!

답글 내용:

최근에 저는 우리 시스템을 위한 1단계 캐싱 메커니즘을 구축하고 싶습니다. 하지만 늘 뭔가 부족한 느낌이 듭니다.

환경:
로드 밸런싱, 마스터-슬레이브 분리, Redis 독립형(향후 여러 머신 사용 가능)

현재 예비 아이디어:

<code>浏览器缓存-》本地文件缓存-》内存缓存（Redis）-》Db
</code>

사용자가 웹 애플리케이션에 액세스한 후 해당 웹 애플리케이션에 대한 브라우저 캐시를 설정한 다음 로컬 파일 캐시와 메모리 캐시를 설정합니다.
다른 유저들이 방문한 후, 다음 단계인 것 같아요.

1. 브라우저 캐시가 있는지 확인

2. 로컬 머신에 파일 캐시가 있는지 검색

3. 메모리 캐시

4. DB

내 질문은:

그런데 특정 단계에서 뭔가 부족한 느낌이 들거나 (다단계) 캐시 만료 시간을 선택하기 어렵다고 느껴집니다.

그리고 메모리 캐시(Redis)로 직접 점프하는 단일 연결에 비해 로컬 파일 캐시{만료 시간 확인, 파일 읽기(삭제, 생성)}가 가치가 있나요?

그래서 제가 가지고 있는 기본 캐싱 메커니즘이 적합한지, 아니면 개선할 수 있는 단점이 있는지 여쭤보고 싶습니다. 감사합니다!

1. 다중 레벨 캐시는 시스템에 대한 부담을 줄이고 RT를 크게 줄일 수 있습니다. 그러나 고려해야 할 한 가지 측면은 다중 레벨 캐시의 관리입니다. 이는 기사에서도 언급되었습니다. . 이는 다중 캐시를 사용하는 경우 레벨 캐싱이 피할 수 없는 문제입니다. 다중 레벨 캐시를 무효화하는 방법은 로컬 타이머를 사용하여 일정 간격으로 캐시를 새로 고칠 수 있습니다.

2. 실제로 파일 캐시를 로컬 메모리 캐시로 대체할 수도 있지만 파일 캐시로 설계하는 것도 가능하지만 로컬 디스크 I/O 양이 많으면 감당할 수 없을까 봐 걱정됩니다. 네트워크 오버헤드와 어느 쪽이 더 효율적일까요? 실제 상황에 맞춰 스트레스 테스트를 진행해야 할까요?

3. 다중 레벨 캐싱은 캐시 침투 및 프로그램 견고성에 관한 것입니다. 중앙 집중식 캐시에 문제가 있는 경우 일부 핫 데이터가 메모리 캐시로 계속 실행될 수 있습니다. 필요 중앙 집중식 캐시에 액세스하면 중앙 집중식 캐시에 대한 부담을 줄일 수 있습니다. 따라서 이러한 측면에서는 Redis의 중앙 집중식 캐싱보다 파일 캐싱이 더 좋습니다