Redis 데이터 구조에 대한 간략한 설명
Redis는 5 개의 공통 데이터 구조, 3 개의 특수 데이터 구조 (여기에 설명되지 않음)가
일반적으로 사용되는 데이터 구조 :
STRING :
정수 값과 SDS (단순 동적 문자열)로 구현 된 객체입니다.
애플리케이션 시나리오 :
1 캐시
로 사용 가능 2. 카운터
로 사용 가능 3. 공유 사용자 세션으로 사용 가능
HASH : 압축 된 목록과 사전에 의해 구현 된 해시 객체
응용 시나리오입니다 :
1. 사용자 관련 정보를 저장하기위한 관계형 데이터베이스 저장소로 사용할 수 있습니다.
LIST : 압축 목록과 이중 종단 연결 목록으로 구현 된 목록 객체
응용 프로그램입니다. 시나리오 :
1. left in 및 right out 명령을 통해 차단 대기열을 달성하는 메시지 대기열로
사용할 수 있습니다. 2. 블로그의 사용자 기사 목록과 같은 데이터 페이징으로 사용할 수 있습니다.
SET : 정수 집합과 사전으로 구현 된 수집 객체
응용 시나리오 :
1. 라벨
2. 공통 친구
3. 독립 IP
ZSET : 압축 된 목록, 사전 및 점프 테이블로 구현되는 정렬 된 개체 집합입니다.
응용 프로그램 시나리오 :
1. 특정 필드에 따라 정렬 할 수있는 순위 지정
2. 가중치를 계산하고, 가중치 값을 설정하고, 스레드가 가중치 규칙에 따라 실행되도록합니다.
Redis의 지속성 메커니즘 RDB 및 AOF를 간략하게 설명합니다.
둘 다 redis의 지속성 메커니즘입니다.
RDB는 스냅 샷 수준의 지속성으로 save 명령과 bgsave 명령을 통해 바이너리 스트림 파일 형태로 지속됩니다. 저장 명령이 실행되면 Redis 서버 프로세스가 차단됩니다. RDB 파일이 생성되기 전에 Redis 서버는 다른 명령을 실행하여 작업을 요청할 수 없습니다. bgsave 명령이 실행되면 Redis 서버는 하위 프로세스를 포크하여 RDB 파일 생성을 수행합니다. , 이는 백그라운드에서 실행되는 것과 동일합니다. 현재 Redis 서버는 비 차단 상태입니다. 다른 명령에 의해 요청 된 작업을 수행 할 수 있습니다. Redis는 기본 프로세스를 방지하기 위해 기본 프로세스와 하위 프로세스가 save 또는 bgsave 명령을 동시에 실행하는 것을 허용하지 않습니다. 프로세스와 하위 프로세스는 경쟁 관계를 가지고 있습니다.
AOF는 로그 수준의 지속성입니다. aof 파일 끝에 데이터베이스를 운영하기위한 명령을 추가합니다. 다운 타임이있는 경우 데이터베이스 상태 복구 목적을 달성하기 위해 aof 파일의 명령을로드하고 다시 실행합니다. 세 가지를 제공합니다. 간격 저장 방법에는 두 가지 종류가 있는데, 하나는 명령 작업에서 한 번 쓰는 것, 두 번째는 1 초에 한 번 쓰는 것, 세 번째는 쓰기 간격 처리를 시스템 관리에 전달하는 것입니다. AOF의 기본값은 매번 사용하는 것입니다. 1 초에 한 번 작성하십시오.
Redis의 설정 파일에서 RDB는 기본적으로 켜져 있고, AOF는 기본적으로 꺼져 있습니다 .Redis의 설정 파일에서 기본 저장 명령을 실행하는 방법은 세 가지가 있습니다.
900 저장 1 --------------- 900S에서는 데이터베이스가 한 번 이상 수정되었습니다.
300 저장 10 -------------- 300S에서는 수정 데이터베이스가 10 회 이상 수정되었습니다.
60 10000을 절약하십시오 .------------ 60S 이내에 데이터베이스가 10,000 회 이상 수정되었습니다.
Redis 높은 동시성에서 발생할 수있는 비즈니스 시나리오의 고장, 침투, 눈사태 및 솔루션
고장:
핫키 (예 : Weibo의 핫 검색)에 초당 10,000 개의 요청이 있으면 액세스가 매우 빈번하고 동시성이 높은 상태입니다.이 키의 유효성이 갑자기 무효화되면 현재 초당 10,000 회 요청은 데이터베이스에 직접 전달 될 것입니다. 당연히 데이터베이스는 이러한 높은 빈도의 액세스를 견딜 수 없어 데이터베이스를 죽일 것입니다.
풀다:
핫스팟 데이터가 만료되지 않도록 설정하거나 상호 배제 잠금, 잠금 구현-> 캐시 머신이 처음 액세스 한 데이터를 캐시 할 때까지 대기-> 잠금을 해제하여 동일한 데이터에 대한 후속 높은 동시 액세스가 직접 진행될 수 있도록합니다. 데이터는 캐시에서 검색되어 반환됩니다.
관통 :
초당 10,000 개의 요청이 있고 공격자가 8,000 개의 요청을 보낸다고 가정하면 캐시와 데이터베이스에서 이러한 ID를 찾을 수 없습니다 (ID가 음수라고 가정 할 수 있음).이 경우에도 데이터베이스를 종료합니다.
풀다:
캐시 나 데이터베이스에서 처음 발견되지 않는 키인 경우 해당 값을 null로 설정하고 캐시에 기록하여 이후에 7999 개의 요청이 있어도 매번 대신 null을 직접 반환 할 수 있도록합니다. 데이터베이스에서 검색해야 함
눈사태:
초당 10,000 개의 요청이 있고 캐시 머신이 초당 최대 8,000 개의 요청을 처리 할 수 있다면 당연히 문제는 없지만 캐시 머신이 갑자기 다운되면이 8,000 개의 요청이 직접 추가됩니다. 데이터베이스에서 데이터베이스는 필연적으로 지원할 수 없으며 이론적으로는 경찰에 먼저 전화 한 다음 전화를 끊습니다. 실제로는 직접 끊을 가능성이 높습니다.
풀다:
사전 : Redis는 고 가용성, 읽기-쓰기 분리, 마스터-슬레이브 복제 + 감시 모드, redis 클러스터로 전체 충돌을 방지합니다.
이벤트 : 로컬 ehcache 캐시 + hystrix 전류 제한 및 다운 그레이드하여 MySQL이 종료되는 것을 방지합니다.
이벤트 후 : Redis가 지속됩니다. 다시 시작되면 데이터가 디스크에서 자동으로로드되어 캐시 된 데이터를 빠르게 복원합니다.
Redis 트랜잭션
오픈 트랜잭션
다중
실행 명령
exec 명령 대기열
닫기 트랜잭션
폐기
모니터링 잠금 감시 키
모니터링 취소 감시 해제