프로그래밍 기술 캐시 작성 방법(2)

지난 시간에는 캐시 읽기 및 쓰기의 다양한 코드 구현에 대해 주로 논의했습니다. 이 기사에서는 마지막 질문에 이어 수년에 걸쳐 다양한 캐시 사용을 계속해서 살펴봅니다.

1: 캐시 워밍업

지난번에 반 친구가 물어봤습니다. 처음 로드할 때 캐시가 비어 있는 경우 이를 워밍업하는 방법.

독립형 웹 상황에서는 일반적으로 RunTimeCache를 사용합니다. 이 상황과 비교하면:

1: 시작 이벤트에서 새로 고칠 수 있습니다.

void Application_Start(object sender, EventArgs e)
{
       //刷新
}

2: 단일 새로 고침 캐시 페이지를 작성하고, 온라인에 접속한 후 수동으로 새로 고치거나, 호출 게시 시 자동으로 새로 고칩니다. 새로 고치거나 사용자가 간단히 트리거할 수 있습니다.

분산 캐시(Redis, memcached)의 경우:

예: 수십 대의 서버 캐싱이 있는 경우 캐시를 채우는 데 꽤 오랜 시간이 걸립니다.

이런 종류의 예열은 좀 더 복잡합니다. 일부는 이를 실행하기 위해 단일 애플리케이션을 작성하는 반면 다른 일부는 이를 처리하기 위해 단일 프레임워크 메커니즘을 작성합니다(보다 지능적).

목적은 온라인에 접속하기 전입니다. 모든 캐시가 사전 로드되어 있습니다.

2: 다중 레벨 캐시

2.1 소개

우리는 일반적으로 CPU와 메모리 사이에 1단계 캐시와 2단계 캐시가 있어 교환을 증가시키는 것으로 알고 있습니다. 속도.

이렇게 하면 CPU가 대량의 데이터를 호출할 때 메모리를 피하고 CPU 캐시에서 직접 호출하여 읽기 속도를 높일 수 있습니다.

다중 레벨 캐시의 특성은 CPU 캐시를 기준으로 파악됩니다.

1: 각 캐시 레벨은 다음 레벨 캐시의 일부를 저장합니다.

2: 레벨에 따라 읽기 속도가 감소하고, 비용도 감소하며, 용량은 증가합니다.

3: 현재 레벨이 누락되면 다음 레벨로 이동하여 검색합니다.

엔터프라이즈 애플리케이션 수준 개발에서 다중 레벨 캐시를 사용하는 것은 목적과 디자인은 동일하지만 세분성이 더 거칠고 유연합니다.

속도에 따라 배열된 lv1-lv6의 캐시 유형 다이어그램:

레벨 3 캐시 적중 흐름도의 예:

2.2 스레드 캐싱

웹 애플리케이션은 본질적으로 다중 스레드입니다. 일부 공용 리소스의 경우 스레드 안전성을 고려해야 하며 지금까지는 데이터의 무결성과 정확성을 보장하기 위해 잠금을 사용해야 합니다.

실제로 웹 서버는 최소한 수백, 수천 개의 요청을 처리해야 합니다. 생각해 보세요. 복잡한 비즈니스 프로세스에서는 함수가 호출될 때마다 잠가야 합니다.

서버 낭비도 큽니다. 스레드 캐싱을 통해 현재 사용자 요청을 처리하는 스레드는 필요한 것만 얻을 수 있습니다.

public static ThreadLocal<UserScore> localUserInfo = new ThreadLocal<UserScore>();

Net에서 제공하는 스레드 로컬 변수를 사용하면 요청 항목에서 현재 사용자의 데이터를 가져올 수 있습니다.

스레드의 전체 수명 주기 동안 우리 비즈니스 로직은 이 데이터를 걱정 없이 사용할 수 있으며 스레드 안전성을 고려할 필요가 없습니다.

그리고 새로운 데이터를 얻을 필요도 없기 때문에 데이터 찢김을 걱정할 필요도 없습니다.

현재 스레드 주기의 데이터는 완전하고 정확하기 때문에 사용자가 두 번째로 요청을 시작할 때만 새 데이터가 검색됩니다.

이렇게 하면 서버 처리량이 크게 향상될 수 있습니다. 스레드 종료 시 데이터가 삭제되도록 주의하세요.

2.3 메모리 캐시

원격 데이터베이스 읽기인지, 캐시 서버 읽기인지. 프로세스, 네트워크, 때로는 컴퓨터실 전반에 걸쳐 통신하는 것은 불가피합니다.

어플리케이션을 자주 읽고 쓰다 보면 웹 서버와 DB 서버에 많은 돈이 소모되고, 속도도 메모리에 비해 훨씬 느리다.

코드에 잠금, 비동기를 추가하거나 서버를 추가하는 것은 좋은 생각이 아닙니다. 로딩 속도는 사용자 경험에 매우 중요하기 때문입니다.

그래서 로컬 메모리가 필요한 프로젝트에서는 로컬 메모리를 2차 캐시로 사용하는 것이 매우 필요합니다. 목적은 1: 동시성 방지, 2: 읽기 속도 향상입니다.

캐시 5분 규칙으로 유명한데, 이는 데이터에 자주 액세스하는 경우 메모리에 저장해야 한다는 의미입니다.

예: 동시 요청이 100개 있는 경우 잠금으로 인해 99개의 프런트 엔드 스레드가 대기하게 됩니다. 대기 중인 이 99개의 스레드는 실제로 웹 서버 리소스를 소비하고 있습니다. 추가하지 않으면 캐시 사태가 발생합니다.

1분마다 캐시를 ​​가져와 메모리에 캐시하면 99개 스레드의 대기 시간이 크게 단축됩니다.

2.4 파일 캐시

하드디스크는 메모리에 비해 용량이 크고 네트워크보다 속도가 빠르다.

그래서 자주 변경되지 않고 메모리가 낭비되는 일부 데이터를 로컬 하드 디스크에 캐시할 수 있습니다.

예를 들어 일부 파일 데이터베이스에 sqlite를 사용하면 쉽게 할 수 있습니다.

2.5 분산 캐시

Redis, memcached 등 메모리 캐시 기반.

nosql 파일을 기반으로 Casssandra, mongodb 등을 사용합니다.

Redis와 memcached는 주류 분산 메모리 캐시이며 애플리케이션과 DB 사이의 가장 큰 캐시 계층입니다.

Nosql은 실제로 캐싱에만 사용되는 것이 아니라 일부 비핵심 사업의 DB 레이어에도 사용됩니다.

2.6 DB 캐시

이 DB 계층은 주로 원본 데이터에서 계산된 결과를 캐시합니다. 그리고 SQL을 통해 웹 프로그램에서 직접 계산하거나 사용하는 것을 피하십시오.

물론 캐싱을 위해 계산된 데이터를 Redis에 저장할 수도 있습니다.

3: Multi-layer Cache

Multi-layer Cache의 개념은 여러 곳에서 활용되어 왔습니다.

1: What 위에서 말했듯이 멀티 레벨 캐시는 읽기 빈도 레벨에 따라 콘텐츠를 다른 레벨로 저장하는 일종의 캐시입니다.

2: 또 다른 다중 계층 접근 방식은 B-트리 검색과 유사하게 인덱스를 캐시하는 것인데, 이는 검색 효율성을 향상시킬 수 있습니다.

3: 구조적으로 말하면 클라이언트 캐싱, CDN 캐싱, 역방향 프록시 캐싱, 서버 캐싱도 다중 계층 캐싱입니다.

넷:요약

사용면에서는 실제 시나리오를 바탕으로 누구나 다양한 조합을 할 수 있습니다. 이 기사는 더 이론적인 내용이므로 많은 세부 사항을 자세히 설명하지 않습니다.

예를 들어 분산 캐시 사용, 캐시 교체 전략 및 알고리즘, 캐시 만료 메커니즘 등이 있습니다. 나중에 계속해서 추가하겠습니다.