Redis가 매우 유용하다고 말하는 이유는 무엇입니까?-Redis-php.cn

Redis가 매우 유용하다고 말하는 이유는 무엇입니까?

머리말:

저는 대부분의 프로그래머에게 redis 미들웨어는 모든 사람에게 매우 친숙해야 한다고 믿습니다. 하지만 직장에서 비즈니스 코드를 자주 작성하는 프로그래머의 경우, 실제 업무에서 설정된 값만 사용하고 값을 가져오고 기타 작업을 수행하므로 Redis에 대한 전반적인 이해가 부족할 수 있습니다. 이제 Redis를 자세히 소개하겠습니다.

Redis란 무엇인가요?

Redis는 C 언어로 작성된 오픈 소스 키-값 저장소 데이터베이스입니다. 캐싱, 이벤트 게시 및 구독, 고속 큐와 같은 시나리오에서 사용할 수 있습니다. 그리고 문자열(string), 해시(hash), 목록(list), set(정렬되지 않은 집합), zset(정렬된 집합: 정렬된 집합) 등 다양한 데이터 유형을 지원합니다.

프로젝트에서 Redis의 응용 시나리오

가장 일반적으로 사용되는 데이터로 자주 쿼리해야 하고 자주 변경되지 않는 데이터를 핫 데이터라고 합니다.

2. 메시지 대기열

은 ActiveMQ 및 RocketMQ와 같은 메시지 구독 시스템과 동일합니다. 데이터에 대해 더 높은 일관성 요구 사항이 있는 경우에도 MQ를 사용하는 것이 좋습니다. information

대형 전자상거래 플랫폼은 페이지 데이터 캐시를 초기화합니다. 예를 들어, Qunar.com에서 티켓을 구매할 때 홈페이지에 표시된 가격은 클릭한 가격과 다릅니다.

5. 핫스팟 데이터

예: 뉴스 웹사이트의 실시간 핫스팟, 웨이보의 인기 검색어 등 자주 업데이트해야 합니다. 총 데이터 양이 비교적 큰 경우 데이터베이스에서 직접 쿼리하면 성능에 영향을 미칩니다

사랑할 이유를 주세요

우리는 일반적으로 단일 노드 서버에서 이 작업을 수행합니다

기업과 사업 확장. 대용량 데이터 앞에서 MySql을 직접 사용하면 성능 저하가 발생하고 데이터 읽기 및 쓰기 속도도 매우 느려집니다. 따라서 캐싱을 사용하여 대규모 데이터를 처리할 수 있습니다.

이제 우리는 이렇습니다.

Redis가 매우 유용하다고 말하는 이유는 무엇입니까?

위 그림에서는 캐시의 역할을 간략하게 설명했을 뿐입니다. 데이터가 계속 증가할 때 읽기-쓰기 분리를 위해서는 마스터-슬레이브 복제 기술을 사용해야 합니다.

The 데이터베이스 계층은 캐시와 직접 상호 작용합니다. 캐시에 데이터가 있으면 클라이언트에 직접 반환되고, 그렇지 않으면 MySql에서 쿼리됩니다. 이렇게 하면 데이터베이스에 대한 부담이 줄어들고 효율성이 향상됩니다.

Redis가 매우 유용하다고 말하는 이유는 무엇입니까? 보통 새 휴대폰이 출시되면 급매물이 나오죠. 같은 기간 동안 서버는 많은 주문 요청을 받게 됩니다.

이 "단일 스레드"를 달성하려면 redis의 원자적 작업을 사용해야 합니다. 먼저 인벤토리에 10개의 항목이 있다고 가정하면 10개의 숫자를 목록에 입력합니다. 이 숫자는 실제 의미가 없으며 인벤토리의 10개 항목만 나타냅니다. 긴급 구매가 시작된 후 사용자가 도착할 때마다 목록에 숫자가 표시되어 사용자의 긴급 구매가 성공했음을 나타냅니다. 목록이 비어 있으면 해당 항목이 삭제되었음을 의미합니다. 목록의 팝 작업은 원자적이므로 많은 사용자가 동시에 도착하더라도 순차적으로 실행됩니다.

주제 외: 일부 긴급 구매는 프런트 엔드 페이지의 요청을 직접 제한합니다. 이러한 요청은 직접 차단됩니다.

Redis가 왜 그렇게 빠른가요?

1. Redis는 필요할 때 수동으로 하드 디스크에 유지해야 합니다.

2. Redis는 단일 스레드이므로 다중 스레드에서 빈번한 컨텍스트 전환 작업을 피합니다.

3. Redis의 데이터 구조는 간단하고, 데이터의 작동은 비교적 간단합니다. 4. 기본 모델이 다르며, 클라이언트와 통신하기 위한 기본 구현 방법 및 애플리케이션 프로토콜이 다릅니다. VM 메커니즘, 일반 시스템이 시스템 기능을 호출하면 이동 및 요청에 일정 시간이 낭비되기 때문입니다.

5. 다중 채널 I/O 다중화 모델, 비차단 I/O

다중 채널 I 사용 /O 멀티플렉싱: I/O 멀티플렉싱 기술은 특정 I/O 시스템 호출을 차단하는 프로세스나 스레드의 문제를 해결하는 것으로 보이는 기술입니다. 특정 디스크립터가 준비되면(일반적으로 읽기 준비 또는 쓰기 준비가 완료됨) it 이 파일 설명자가 읽기 및 쓰기 작업을 수행하기 전에 해당 읽기 및 쓰기 작업을 수행하도록 프로그램에 알릴 수 있습니다

(동영상 공유 학습:

redis 비디오 튜토리얼

)

Redis 데이터 유형의 응용 시나리오

앞서 언급한 바와 같이 , Redis는 5가지 유형의 풍부한 데이터 유형을 지원합니다. 그렇다면 다양한 시나리오에서 어떻게 선택해야 할까요?

StringString은 가장 일반적으로 사용되는 데이터 유형으로 바이너리, JSON화된 객체, 심지어 base64로 인코딩된 이미지를 포함한 모든 유형의 문자열을 저장할 수 있습니다. Redis에서 문자열의 최대 용량은 512MB로 만능이라고 할 수 있습니다.

해시

구조화된 데이터를 저장하는 데 일반적으로 사용됩니다. 예를 들어 포럼 시스템에서는 사용자 ID, 닉네임, 아바타, 포인트 및 기타 정보를 저장하는 데 사용할 수 있습니다. 정보를 수정해야 하는 경우 Key를 통해 Value를 꺼내서 deserialize하고 항목의 값을 수정한 다음 Redis에 직렬화하여 저장하면 됩니다. Hash 구조가 저장되기 때문입니다. 단일 해시 요소가 특정 숫자보다 작을 때 수정되므로 많은 메모리를 절약할 수 있습니다. 이는 문자열 구조에 존재하지 않습니다.

List

List는 역방향 검색과 순회를 지원할 수 있는 양방향 연결 목록으로 구현되어 작동이 더 편리합니다. 그러나 전송 버퍼 큐를 포함하여 Redis 내에서 많은 구현이 발생합니다. 등. 이 데이터 구조가 사용됩니다. 또한 lrange 명령을 사용하여 뛰어난 성능과 우수한 사용자 경험을 제공하는 Redis 기반 페이징 기능을 구현할 수 있습니다.

Set

세트에서 제공하는 외부 기능은 목록 기능과 유사합니다. 특별한 점은 목록 데이터를 저장해야 하고 중복된 데이터가 표시되는 것을 원하지 않는 경우 이번에는 다음을 선택할 수 있다는 것입니다. 세트를 사용하세요.

Sort Set

은 특정 조건의 가중치에 따라 정렬할 수 있습니다. 예를 들어 클릭 수를 기준으로 순위 데이터 애플리케이션을 만들 수 있습니다.

Redis 캐시의 데이터 일관성

진정한 의미에서 데이터베이스 데이터와 캐시된 데이터의 일관성은 불가능합니다. 데이터는 최종 일관성과 강력한 일관성이라는 두 가지 범주로 나뉩니다. 비즈니스의 데이터에 대한 요구 사항이 강력해야 하는 경우 캐싱을 사용할 수 없습니다. 캐시가 할 수 있는 일은 데이터의 최종 일관성을 보장하는 것뿐입니다.

우리가 할 수 있는 일은 데이터 일관성을 최대한 보장하는 것뿐입니다. 데이터베이스를 먼저 삭제한 후 캐시를 삭제하거나, 캐시를 먼저 삭제한 후 데이터베이스를 삭제하더라도 읽기 및 쓰기 작업이 동시에 수행되므로 데이터 불일치가 발생할 수 있습니다. 구체적인 대응 전략은 여전히 비즈니스 요구에 따라 결정되어야 하므로 여기서는 자세히 다루지 않겠습니다.

Redis 만료 및 메모리 제거

Redis가 데이터를 저장할 때 만료 시간을 설정할 수 있습니다. 그런데 이 키는 어떻게 삭제되나요?

처음에는 예약된 삭제인 줄 알았는데, 나중에 알고 보니 삭제 예정인 경우에는 메모리가 해제되더라도 키를 지속적으로 모니터링하기 위해 타이머가 필요하기 때문입니다. CPU 리소스를 많이 소모합니다.

Redis 만료 삭제는 기본적으로 100ms마다 감지하는 것입니다. 만료된 키가 발견되면 삭제됩니다. 여기서 감지는 순차적 감지가 아니라 무작위 감지입니다. 그물을 통과하는 물고기가 있을까요? 분명히 Redis는 이 점을 고려했습니다. 만료된 키를 읽고 쓸 때 Redis의 지연 삭제 전략이 실행되고 만료된 키가 직접 삭제됩니다. 즉, 사용자가 저장한 키의 일부를 사용할 수 있습니다. Redis. 캐시에서 데이터를 찾을 수 없도록 자동으로 삭제합니다. 당사 서버의 메모리는 2G인데, 사업이 발전하면서 캐시된 데이터가 2G를 초과하게 되었습니다. 그러나 이는 운영 체제의 가시적 메모리가 물리적 메모리에 의해 제한되지 않기 때문에 프로그램 실행에 영향을 미치지 않습니다. 실제 메모리가 충분하지 않아도 컴퓨터는 하드 디스크의 공간을 가상 메모리로 할당합니다. 이는 캐시와 영구 저장소

캐시 분석

이라는 두 가지 애플리케이션 시나리오를 설계하려는 Redis의 원래 의도입니다. 캐시는 필요한 데이터를 캐시에서 쿼리할 수 없을 때 데이터베이스에 대한 부담을 완화하기 위해 추가된 보호 계층일 뿐입니다. , 데이터베이스에서 쿼리를 받아야 합니다. 해커가 이를 이용해 캐시에 없는 데이터에 자주 접근하게 되면 캐시는 그 의미를 잃게 되고, 모든 요청에 대한 압박이 순식간에 데이터베이스에 가해져 데이터베이스 연결 이상이 발생하게 된다.

해결책:

1. 캐시된 데이터를 적극적으로 업데이트하려면 백그라운드에서 예약된 작업을 설정하세요. 이 솔루션은 이해하기 쉽지만 키가 분산되면 작업이 여전히 상대적으로 복잡합니다. 2. 계층적 캐싱. 예를 들어 두 개의 캐시 보호 계층을 설정하면 레벨 1 캐시는 만료 시간이 짧고 레벨 2 캐시는 만료 시간이 깁니다. 요청이 들어오면 먼저 레벨 1 캐시에서 해당 데이터를 검색하고, 레벨 1 캐시에 해당 데이터가 없으면 이 스레드는 데이터베이스에서 데이터를 가져와서 레벨 1로 업데이트합니다. 레벨 2 캐시. 다른 스레드는 레벨 2 스레드에서 직접 얻습니다. 3. 차단 메커니즘을 제공하고 내부적으로 일련의 합법적인 키 값을 유지합니다. 요청한 키가 유효하지 않은 경우 직접 반환됩니다.

Cache Avalanche

Cache Avalanche는 몇 가지 이유(예: 가동 중지 시간, 캐시 서비스 정지 또는 응답 없음)로 인해 캐시가 충돌하여 백엔드 데이터베이스에 많은 요청이 도달하여 데이터베이스가 충돌하고 전체 시스템이 붕괴되는 재해가 발생하며, 위에서 언급한 캐시 붕괴가 발생합니다.

눈사태를 피하는 방법:

1. 캐시에 특정 범위 내에서 임의의 유효 시간을 추가하고 동시에 집단적 실패를 방지하기 위해 서로 다른 키에 대해 서로 다른 만료 시간을 설정합니다.

Redis가 매우 유용하다고 말하는 이유는 무엇입니까? 2. 캐시 분석 솔루션과 유사하게 보조 캐시를 생성하고 원본 캐시가 실패하면 복사 캐시에서 데이터를 읽습니다.