캐싱은 모든 웹사이트와 서비스의 표준 기능으로 간주됩니다. 실제 요구 사항을 충족하는 캐싱 솔루션을 어떻게 설계할 수 있을까요? 캐싱에 노출된 모든 코더는 마음 속에 자신만의 답을 갖고 있을 것입니다.
** 캐시 모듈을 처음부터 어떻게 설계하나요?
어떤 요소를 고려해야 합니까?
디자인이 어떻게 부족한가요?
오버디자인을 방지하려면?
실제 요구 사항을 충족하는 방법은 무엇입니까?
실시 계획을 점진적으로 개선하려면 어떤 문제를 명확히 해야 합니까? **
나의 재능이 적고 지식도 부족한데 누군가 조언을 해주셨으면 좋겠습니다. 정말 감사하겠습니다.
================ 다 타버렸는데 왜 자르지 않죠 =====================
나의 요구사항:
빠르고 일부 기록은 변경되지 않지만(거의 변경되지 않음) 정보가 매번 사용되며 매번 DB를 읽는 오버헤드가 너무 높습니다.
(Redis의 숙달 수준은 초급 수준이므로 나중에 보충하겠습니다.)
직접 디자인:
0을 고려하세요. 필요에 따라 캐시 시간 초과 및 적중률을 단계적으로 높입니다.
1. (레벨 1 캐시) 첫 번째 단계에서는 로컬 메모리 레벨 캐시를 만들고 그렇지 않은 경우 메모리에서 직접 읽습니다. 동시에 DB를 업데이트합니다. (DB에서는 쿼리 속도를 높이기 위해 View를 사용합니다.)
2. (2단계 캐시) 2단계, 나중에 RQ가 일정 수준 이상 증가하면 로드합니다. 요구될 것이다 Balance에서는 현재 Redis 또는 Memcache 솔루션이 2차 캐시로 간주됩니다. 1차 캐시가 누락되면 2차 캐시를 읽고, 누락되면 데이터베이스에 쿼리합니다(모두 기존 데이터는 역순으로 업데이트됩니다)
문제점:
1. DB에 기록되는 경우 구성 매개변수가 단순한 키-값 형식이 아니며 쿼리 및 매칭 작업도 필요하며 비즈니스 복잡성이 증가함에 따라 다른 데이터를 캐시해야 합니다.
2. Redis 등 NoSQL/Redis에 기록된 경우 해당 데이터 저장소를 '재난 복구'용으로만 사용할 수 있나요? 아니면 Redis 데이터 저장소를 DB 대신 사용할 수 있나요?
3. 스토리지에 직접 기록되나요? 캐시해야 하는 일부 데이터를 수동으로 입력해야 하기 때문입니다.
우려사항:
두 번째 단계에서는 1단계 캐시와 2단계 캐시를 설계하는 것이 중복되나요? 주된 이유는 Redis에서 캐시 정보를 읽으면 네트워크 전송이 수반된다는 점을 고려하기 위함입니다
방식:
A. 1차 캐시 솔루션과 2차 캐시 솔루션을 사용하지만, 분산 배포 후에는 1차 캐시의 데이터가 타임아웃되었는지 정확하게 판단할 수 없습니다.
B. 1단계 캐시를 포기하고 Redis에서 직접 읽어보세요. (어느쪽이 높은지 Redis를 읽는 비용인지 메모리를 직접 읽는 비용인지 잘 모르겠습니다. 게다가 1단계에 안맞으면 다음으로 갑니다. 두 번째 수준으로 읽어야 하지만 더 나아갈 것입니다)
자문과 답변:
플랜 A를 포기하세요. 로컬 메모리를 직접 읽는 것이 효율적이지만 적중률을 말하기 어렵기 때문입니다.
플랜 B를 사용하세요. 네트워크 전송 손실이 있지만, 이어지는 3단계와 4단계. . Redis를 마스터-슬레이브로 구성하거나 샤딩으로 구성해야 할 수도 있습니다. 이때 이전에 걱정했던 네트워크 손실은 전혀 없습니다.
위는 제 생각인데, 실현 가능한지, 또 고려하지 않은 점은 잘 모르겠습니다. 첫 번째 단계와 두 번째 단계 사이의 시간이 너무 길지 않을 수 있으므로 초기 디자인에서는 좀 더 신중하게 생각하는 것이 가장 좋습니다.
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
1. 적절한 캐싱만 수행하세요
2. 기술만을 목적으로 사용하지 마세요
Redis 사용에 대해 이야기하겠습니다.
먼저 Redis를 사용하여 정적 데이터(즉, 변경되지 않았거나 거의 변경되지 않음)를 다시 삽입할 필요가 없습니다. 첫 번째 수준 캐시는 캐시 쿼리를 복잡하게 만듭니다.
2. 문제는 Redis를 사용하여 변수 데이터, 즉 수정이 필요한 데이터를 캐시하는 것은 현재로서는 매우 번거롭다는 것입니다. 왜냐하면 현재 Redis는 DB의 저장 기능, 즉 데이터를 완전히 대체할 수 없기 때문입니다. 지속성을 위해서는 최종 데이터를 DB에 입력해야 합니다. 여기에는 redis와 db 간의 동기화 문제가 포함됩니다. 프로젝트의 내 솔루션은 먼저 Redis를 수정한 다음 DB를 비동기식으로 수정하고 마지막으로 DB를 Redis에 동기화하는 것입니다. 캐시된 데이터 일관성 요구 사항이 매우 엄격하기 때문입니다.
3. 프로젝트에서는 키를 기반으로 해시 데이터를 쿼리하지만 요청은 각 요청에 대해 Redis에서 동일한 키를 여러 번 얻기 위해 해시의 키 데이터 일부를 별도로 요청합니다. 질문에서 언급한 첫 번째 수준 캐시인 JVM 메모리 캐시가 도입된 이유는 Redis에 대한 액세스 횟수를 줄이는 것이지만 이 첫 번째 수준 캐시의 주요 목적은 동일한 키에 대한 여러 요청을 병합하는 것입니다. 최종 캐시는 여전히 Redis를 기반으로 해야 하기 때문에 JVM 메모리는 매우 제한적입니다.
1. 메모리에 직접 캐시하지 말고 memcache나 redis를 직접 사용하세요.
CPU에는 여러 개의 코어가 있습니다. 일반적으로 하나의 코어에는 하나의 작업자가 있으며 메모리는 공유되지 않습니다. 8개의 코어가 있고 애플리케이션에 캐시하면 8개의 캐시가 있는 것과 같습니다. 물론 공유 메모리를 사용할 수 있지만 여러 작업자 상호 작용을 처리해야 합니다. 그러니 Memcache와 Redis가 그렇게 하도록 놔두세요.
2. 네트워크 지연은 매우 작으며 http 응답 시간은 일반적으로 0.1ms 미만으로 무시할 수 있습니다.
3. 다중 레벨 캐시를 사용하지 마세요. 충분하지 않으면 Memcache 메모리를 늘리세요.
4. 캐시만, 즉 쓰기 시에만 데이터베이스에 쓰고 해당 Memcache 캐시를 삭제합니다. 읽을 때 먼저 Memcache로 이동하고 실패하면 데이터베이스로 이동한 다음 Memcache에 씁니다.