Redis 캐시 무효화 메커니즘 소개

Redis 캐시 실패 이야기는 EXPIRE 명령으로 시작됩니다. EXPIRE를 사용하면 이 시간이 초과되면 키에 해당하는 값이 지워집니다. Redis 소스 코드 Redis 디자이너의 관점에서 Redis 캐시 오류와 관련된 문제를 생각해 보세요.

Redis 캐시 무효화 메커니즘

Redis 캐시 무효화 메커니즘은 애플리케이션 캐싱의 매우 일반적인 시나리오를 처리하도록 설계되었습니다. 시나리오에 대해 이야기해 보겠습니다.

우리는 부담을 줄여서 매우 기쁩니다. Redis 서비스의 도움으로 자주 변경되지 않는 데이터를 DB에서 로드하여 캐시에 넣기 때문에 일정 기간 동안은 캐시에서 직접 데이터를 가져올 수 있기를 바랍니다. 일정 시간이 지나면 캐시에서 데이터를 다시 로드할 수 있습니다. DB는 현재 데이터를 캐시에 로드합니다.

질문이 제기되었습니다. 이 문제를 해결하는 방법은 무엇입니까? 글쎄, 우리는 사용 가능한 언어 도구에 매우 익숙하며 이러한 논리를 신속하게 작성할 수 있다고 굳게 믿습니다. 우리는 db에서 데이터를 마지막으로 로드한 시간을 기록한 다음 매번 시간이 만료되었는지 확인합니다. 서비스에 응답합니다. DB에서 다시 로드하시겠습니까...? 물론 이 방법도 가능합니다. 그러나 Redis 명령 문서를 확인했을 때 Redis 자체에서 제공하는 메커니즘을 사용하면 쉽게 수행할 수 있는 작업을 수행한 것으로 나타났습니다. EXPIRE 명령:

EXPIRE key 30

위 명령은 키의 만료 시간을 30초로 설정합니다. 이 시간이 지나면 이 값에 액세스할 수 없어야 합니다. 이 시점에서 캐시 무효화 메커니즘과 일부 응용 프로그램을 대략적으로 이해합니다. 캐시 무효화 메커니즘의 시나리오 다음으로 Redis 캐시 무효화 메커니즘이 어떻게 구현되는지 계속해서 살펴보겠습니다.

지연된 만료 메커니즘

지연된 만료 메커니즘은 클라이언트가 특정 키 작동을 요청하면 Redis가 클라이언트가 요청한 키의 유효 기간을 확인하고 키가 만료되면 해당 처리가 수행된다는 의미입니다. 지연된 만료 메커니즘은 부정적인 실패 메커니즘이라고도 합니다. t_string 구성 요소 아래에서 가져오기 요청 처리를 위한 서버 측 실행 스택을 살펴보겠습니다.

getCommand 
     -> getGenericCommand 
            -> lookupKeyReadOrReply 
                   -> lookupKeyRead 
                         -> expireIfNeeded

핵심은expirationIfNeed입니다. Redis는 키에 대한 가져오기 작업 전에 키와 연결된 값이 유효하지 않은지 여부를 확인합니다. , 작은 에피소드를 삽입하여 Redis에서 실제로 값이 저장되는 위치를 살펴보겠습니다.

typedef struct redisDb {
    dict *dict;                 /* The keyspace for this DB */
    dict *expires;              /* Timeout of keys with a timeout set */
    dict *blocking_keys;        /* Keys with clients waiting for data (BLPOP) */
    dict *ready_keys;           /* Blocked keys that received a PUSH */
    dict *watched_keys;         /* WATCHED keys for MULTI/EXEC CAS */
    int id;    long long avg_ttl;          /* Average TTL, just for stats */} redisDb;

위는 Redis에서 정의된 구조입니다. dict는 Redis에서 구현한 사전입니다. 즉, 각 DB에는 다음이 포함됩니다. 위의 5개 필드 중 하나는 dict이고 다른 하나는 만료됩니다.

dict는 일반 데이터를 저장하는 데 사용됩니다. 예를 들어 set key "hahaha"를 실행하면 이 데이터는 dict에 저장됩니다.

expires는 만료 시간과 관련된 키를 저장하는 데 사용됩니다. 예를 들어 위의 내용을 기반으로 만료 키 1을 실행하면 이때 만료에 대한 레코드가 추가됩니다.

expiredIfNeeded 과정을 다시 살펴보면 대략 다음과 같습니다.

expired에서 키의 만료 시간을 찾습니다. 존재하지 않으면 해당 키에 만료 시간이 설정되어 있지 않고 직접 반환된다는 의미입니다.

슬레이브 머신인 경우 데이터 일관성과 간단한 구현을 보장하기 위해 Redis는 캐시 무효화의 주도권을 마스터 머신에 부여하고 슬레이브 머신에는 캐시 무효화 권한이 없기 때문에 직접 반환됩니다. 열쇠.

현재 마스터 머신이고 키가 만료된 경우 마스터는 두 가지 중요한 작업을 수행합니다. 1) AOF 파일에 삭제 명령을 씁니다. 2) 현재 키가 유효하지 않으며 삭제할 수 있음을 슬레이브에 알립니다.

마스터는 로컬 사전에서 키 값을 삭제합니다.

활성 무효화 메커니즘

활성 무효화 메커니즘은 활성 무효화 메커니즘이라고도 합니다. 즉, 서버는 잘못된 캐시를 정기적으로 확인하고 실패할 경우 해당 작업을 수행합니다.

우리 모두는 Redis가 단일 스레드이고 이벤트 중심이라는 것을 알고 있습니다. EventLoop는 두 가지 유형의 이벤트를 처리합니다.

한 가지 유형은 하위 계층에서 분리되어 다중화되는 IO 이벤트입니다. 장치에서.

첫 번째 유형은 예약된 이벤트로, 주로 특정 작업의 예약된 실행에 사용됩니다.

Redis의 EventLoop 기능은 Netty 및 JavaScript의 EventLoop 기능과 대략 유사한 것 같습니다. 한편으로는 네트워크 I/O 이벤트를 처리하고 다른 한편으로는 몇 가지 작은 작업도 수행할 수 있습니다.

Redis의 단일 스레드 모델에 대해 이야기하는 이유는 Redis의 활성 실패 메커니즘 논리가 예약된 작업으로 처리되고 메인 스레드에 의해 실행되기 때문입니다. 관련 코드는 다음과 같습니다.

if(aeCreateTimeEvent(server.el, 1, serverCron, NULL, NULL) == AE_ERR) {
        redisPanic("Can't create the serverCron time event.");        
       exit(1);
    }

serverCron은 함수입니다. 이 예약된 작업의 포인터는 serverCron입니다. 작업은 EventLoop에 등록되며 초기 실행 시간은 1밀리초 이후로 설정됩니다. 다음으로 우리가 알고 싶은 모든 것은 serverCron에 있습니다. serverCron은 많은 일을 합니다. 이 기사와 관련된 부분, 즉 캐시 무효화가 어떻게 구현되는지에만 관심이 있습니다. 제 생각에 호출 스택은 코드가 수행하는 작업을 비교적 직관적으로 볼 수 있습니다.

aeProcessEvents
    ->processTimeEvents
        ->serverCron 
             -> databasesCron 
                   -> activeExpireCycle 
                           -> activeExpireCycleTryExpire

EventLoop는 예약된 작업을 사용합니다. 처리는 serverCron 로직의 실행을 트리거하고 마지막으로 키 만료 처리 로직을 실행합니다. activeExpireCycle 로직은 마스터에 의해서만 수행될 수 있다는 점은 언급할 가치가 있습니다.

더 많은 Redis 지식을 알고 싶다면 redis 입문 튜토리얼 칼럼을 주목해 주세요.

위 내용은 Redis 캐시 무효화 메커니즘 소개의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!