이 기사에서는 Redis에서 자주 발생하는 인터뷰 질문 몇 가지를 공유하겠습니다. 도움이 필요한 친구들이 모두 참고할 수 있기를 바랍니다.
Redis(원격 사전 서버)는 C 언어로 작성된 오픈 소스(BSD 라이선스) 고성능 비관계형(NoSQL) 키-값 데이터베이스입니다.
Redis는 키와 다섯 가지 유형의 값 사이의 매핑을 저장할 수 있습니다. 키 유형은 문자열만 가능하며 값은 문자열, 목록, 집합, 해시 테이블, 순서 집합의 5가지 데이터 유형을 지원합니다.
기존 데이터베이스와 달리 Redis 데이터는 메모리에 저장되므로 읽기 및 쓰기 속도가 매우 빠릅니다. 따라서 Redis는 캐시 방향으로 널리 사용되며 초당 100,000회 이상의 읽기 및 쓰기 작업을 처리할 수 있습니다. 알려진 최고 성능의 빠른 키-값 DB. 또한 Redis는 분산 잠금에도 자주 사용됩니다. 또한 Redis는 트랜잭션, 지속성, LUA 스크립트, LRU 기반 이벤트 및 다양한 클러스터 솔루션을 지원합니다.
장점
Redis는 읽기 및 쓰기 성능이 110,000회/초, 81,000회/초의 속도로 쓸 수 있습니다.
데이터 지속성을 지원하고 AOF와 RDB의 두 가지 지속성 방법을 지원합니다.
트랜잭션을 지원합니다. 동시에 Redis는 여러 작업을 병합한 후 원자 실행도 지원합니다.
풍부한 데이터 구조는 문자열 유형 값을 지원하는 것 외에도 해시, 세트, zset, 목록 및 기타 데이터 구조도 지원합니다.
마스터-슬레이브 복제를 지원하며 호스트는 자동으로 데이터를 슬레이브에 동기화하며 읽기와 쓰기를 분리할 수 있습니다.
단점
데이터베이스 용량은 물리적 메모리에 의해 제한되며 대용량 데이터의 고성능 읽기 및 쓰기에 사용할 수 없습니다. 따라서 Redis에 적합한 시나리오는 주로 고성능 작업 및 적은 양의 계산으로 제한됩니다. 데이터.
Redis에는 자동 내결함성 및 복구 기능이 없습니다. 호스트 및 슬레이브 머신의 가동 중지 시간으로 인해 일부 프런트엔드 읽기 및 쓰기 요청이 실패할 수 있습니다. 머신이 다시 시작될 때까지 기다리거나 프런트엔드를 수동으로 전환해야 합니다. 복구할 IP를 종료합니다.
호스트가 다운되었습니다. IP 전환 후 일부 데이터를 슬레이브에 동기화할 수 없어 시스템 가용성이 저하됩니다.
Redis는 온라인 확장을 지원하기 어렵습니다. 클러스터 용량이 상한에 도달하면 온라인 확장이 매우 복잡해집니다. 이 문제를 방지하려면 운영 및 유지 관리 담당자는 시스템이 온라인 상태가 될 때 충분한 공간이 있는지 확인해야 하며 이는 막대한 자원 낭비를 초래합니다.
우리는 이 문제를 주로 "고성능"과 "고동시성"이라는 두 가지 측면에서 살펴봅니다.
고성능:
사용자가 처음으로 데이터베이스의 일부 데이터에 액세스한다고 가정합니다. 이 프로세스는 하드 디스크에서 읽기 때문에 속도가 느려집니다. 사용자가 접근한 데이터를 데이터 캐시에 저장하여 다음에 데이터에 접근할 때 캐시에서 직접 가져올 수 있도록 합니다. 캐시를 동작시키는 것은 메모리를 직접 동작시키는 것이기 때문에 속도가 상당히 빠릅니다. 데이터베이스의 해당 데이터가 변경되면 캐시의 해당 데이터를 동기적으로 변경하면 됩니다!
높은 동시성:
캐시가 직접 견딜 수 있는 요청이 데이터베이스에 직접 액세스하는 요청보다 훨씬 크기 때문에 데이터베이스의 일부 데이터를 캐시로 전송하는 것을 고려할 수 있습니다. 사용자의 요청은 데이터베이스를 거치지 않고 캐시로 직접 이동됩니다.
캐시는 로컬 캐시와 분산 캐시로 구분됩니다. Java를 예로 들면, 내장된 맵이나 구아바를 사용하여 로컬 캐싱을 구현합니다. 주요 기능은 jvm이 소멸되는 것으로 수명 주기가 끝나며, 여러 인스턴스의 경우 각 인스턴스가 캐시됩니다. 저장해야 하는데 캐시가 일관성이 없습니다.
redis 또는 memcached를 사용하는 것을 분산 캐시라고 합니다. 여러 인스턴스의 경우 각 인스턴스는 데이터 캐시를 공유하며 캐시는 일관성이 있습니다. 단점은 redis 또는 memcached 서비스의 가용성을 높게 유지해야 하며 전체 프로그램 아키텍처가 상대적으로 복잡하다는 것입니다.
4. 다중 채널 I/O 다중화 모델, 비차단 IO 사용
5. Redis가 자체적으로 구축한 클라이언트와의 통신을 위한 기본 구현 방법 및 애플리케이션 프로토콜이 다릅니다. 메커니즘은 일반적인 시스템이 시스템 기능을 호출하기 때문에 이동 및 요청에 일정 시간을 낭비하게 됩니다.
Redis에는 주로 String, List, Set, Zset, Hash는 대부분의 사용 요구 사항을 충족합니다.
요약 1
1. Counter
는 카운터 기능을 구현하기 위해 문자열에 대한 증가 및 감소 작업을 수행할 수 있습니다. 인메모리 데이터베이스인 Redis는 읽기 및 쓰기 성능이 매우 높으며 자주 읽고 쓰는 횟수를 저장하는 데 매우 적합합니다.
2. 캐시
핫 데이터를 메모리에 넣고 캐시 적중률을 보장하기 위해 최대 메모리 사용량 및 제거 전략을 설정합니다.
3. 세션 캐시
Redis를 사용하면 여러 애플리케이션 서버의 세션 정보를 균일하게 저장할 수 있습니다. 애플리케이션 서버가 더 이상 사용자의 세션 정보를 저장하지 않으면 더 이상 상태가 없으므로 사용자는 애플리케이션 서버를 요청할 수 있으므로 고가용성과 확장성을 더 쉽게 얻을 수 있습니다.
4. 전체 페이지 캐시(FPC)
Redis는 기본 세션 토큰 외에도 매우 간단한 FPC 플랫폼도 제공합니다. Magento를 예로 들면, Magento는 Redis를 전체 페이지 캐시 백엔드로 사용할 수 있는 플러그인을 제공합니다. 또한 WordPress 사용자를 위해 Pantheon에는 매우 유용한 플러그인 wp-redis가 있어 탐색한 페이지를 최대한 빨리 로드하는 데 도움이 됩니다.
5. 조회 테이블
예를 들어 DNS 레코드는 Redis를 사용한 저장에 매우 적합합니다. 조회 테이블은 캐시와 유사하며 Redis의 빠른 조회 기능도 활용합니다. 그러나 캐시는 신뢰할 수 있는 데이터 소스 역할을 하지 않기 때문에 조회 테이블의 내용은 무효화될 수 없지만 캐시의 내용은 무효화될 수 있습니다.
6. 메시지 큐(게시/구독 기능)
List는 lpush와 rpop을 통해 메시지를 쓰고 읽을 수 있는 양방향 연결 목록입니다. 그러나 Kafka 및 RabbitMQ와 같은 메시징 미들웨어를 사용하는 것이 가장 좋습니다.
7. 분산 잠금 구현
분산 시나리오에서는 독립형 환경의 잠금을 사용하여 여러 노드의 프로세스를 동기화할 수 없습니다. Redis와 함께 제공되는 SETNX 명령을 사용하여 분산 잠금을 구현할 수도 있습니다. 또한 공식적으로 제공되는 RedLock 분산 잠금 구현을 사용할 수도 있습니다.
8. 기타
Set은 교차, 합집합 등의 연산을 구현하여 상호 친구 등의 기능을 구현할 수 있습니다. ZSet은 순위 지정과 같은 기능을 달성하기 위해 순서가 지정된 작업을 구현할 수 있습니다.
요약 2
다른 캐시에 비해 Redis는 매우 큰 장점이 있습니다. 즉, 다양한 데이터 유형을 지원한다는 것입니다.
데이터 유형 설명 문자열 문자열, 가장 간단한 k-v 저장소 해시 해시 형식, 값은 필드 및 값이며 ID-세부 사항과 같은 시나리오에 적합합니다. 리스트는 단순 리스트, 순차 리스트, 세트의 첫 번째 또는 끝에 데이터 삽입 지원, 순서가 지정되지 않은 리스트, 빠른 검색 속도, 교차, 합집합 및 차이 세트 처리에 적합 정렬된 세트 순서 세트
실제로는 위 데이터 유형의 특성에 따라 기본적으로 적합한 응용 시나리오를 생각할 수 있습니다.
string——memcached 저장소 구조, SMS 확인 코드, 구성 정보 등과 유사한 가장 간단한 k-v 저장소에 적합하며 이 유형을 사용하여 저장합니다.
hash——일반적으로 키는 ID 또는 고유 식별자이며 값은 세부 사항에 해당합니다. 상품상세정보, 개인정보상세정보, 뉴스상세정보 등
list——목록은 순서가 지정되어 있기 때문에 순서가 있고 상대적으로 고정된 일부 데이터를 저장하는 데 더 적합합니다. 지방 및 도시 테이블, 사전 테이블 등 목록이 정렬되어 있기 때문에 최신 핫뉴스, 메시지 큐 등 작성 시간에 따라 정렬하는 것이 적합합니다.
set——Weibo에 어떤 친구가 있는지 간단히 알 수 있는 ID-List 모델로 이해할 수 있습니다. 집합의 가장 좋은 점은 두 집합에 대한 교집합, 합집합, 차이 연산을 제공할 수 있다는 것입니다. 예: 두 사람 사이의 공통 친구 찾기 등.
Sorted Set- 점수 매개변수를 추가하여 점수 값에 따라 자동으로 정렬되는 향상된 버전의 세트입니다. 삽입 시간에 따라 정렬되지 않은 상위 10개 등의 데이터에 더 적합합니다.
위에서 언급했듯이 Redis는 관계형 데이터베이스만큼 데이터 구조가 복잡하지는 않지만 일반적인 캐시 데이터 구조 이상의 것을 포함하여 많은 시나리오에 적합할 수도 있습니다. 각 데이터 구조에 적합한 비즈니스 시나리오를 이해하면 개발 효율성 향상에 도움이 될 뿐만 아니라 Redis의 성능을 효과적으로 활용하는 데 도움이 됩니다.
지속성은 서비스가 다운될 때 메모리 데이터가 손실되는 것을 방지하기 위해 메모리 데이터를 디스크에 쓰는 것입니다.
Redis는 RDB(기본값)와 AOF 메커니즘 두 가지를 제공합니다.
RDB: Redis DataBase의 약어입니다.
RDB는 Redis의 기본 지속성 방법입니다. 메모리 데이터는 일정 기간에 따라 스냅샷 형태로 하드디스크에 저장되며, 생성된 해당 데이터 파일은 dump.rdb입니다. 스냅샷 기간은 구성 파일의 save 매개변수를 통해 정의됩니다.
장점:
1 dump.rdb 파일이 하나만 있어 지속성이 편리합니다.
2. 재해에 강하고 안전한 디스크에 파일을 저장할 수 있습니다.
3. 성능을 최대화하려면 하위 프로세스를 분기하여 쓰기 작업을 완료하고 기본 프로세스가 계속 명령을 처리하도록 하여 IO가 최대화되도록 합니다. 지속성을 위해 별도의 하위 프로세스를 사용하면 기본 프로세스는 IO 작업을 수행하지 않으므로 Redis의 고성능이 보장됩니다.
4. 데이터 세트가 크면 시작 효율성이 AOF보다 높습니다.
단점:
1. 낮은 데이터 보안. RDB는 일정 간격으로 유지됩니다. 지속성 사이에 redis가 실패하면 데이터 손실이 발생합니다. 따라서 이 방법은 데이터 요구 사항이 엄격하지 않은 경우에 더 적합합니다.)
2. AOF(Append-only file) 지속성 방법: 모든 명령줄 레코드가 redis 명령 요청 프로토콜 형식으로 완전히 영구적으로 저장되는 것을 말합니다. aof 문서로 저장되었습니다.
AOF 지속성(즉, Append Only File 지속성)은 Redis가 실행한 각 쓰기 명령을 별도의 로그 파일에 기록합니다. Redis가 다시 시작되면 파일 복구 데이터가 로그에 다시 유지됩니다.
두 가지 방법을 동시에 활성화하면 데이터 복구 Redis는 AOF 복구에 우선 순위를 부여합니다.
이점:
1. 데이터 보안, aof 지속성은appendfsync 속성으로 구성할 수 있으며 항상 각 명령 작업이 aof 파일에 기록됩니다.
2. 추가 모드를 통해 파일을 작성합니다. 서버가 중간에 다운되더라도 redis-check-aof 도구를 사용하여 데이터 일관성 문제를 해결할 수 있습니다.
3. AOF 메커니즘의 다시 쓰기 모드. AOF 파일을 다시 작성하기 전에(파일이 너무 크면 명령이 병합되고 다시 작성됨) 일부 명령을 삭제할 수 있습니다(예: 실수로 플러시)
단점:
1. RDB 파일이며 복구 속도가 느립니다.
2. 데이터 세트가 크면 시작 효율성이 rdb보다 낮습니다.
장점과 단점은 무엇인가요?
AOF 파일은 RDB보다 더 자주 업데이트되며, AOF를 사용하여 데이터를 복원하는 것이 우선순위입니다.
AOF가 RDB보다 더 안전하고 큽니다
RDB 성능이 AOF보다 낫습니다
If 둘 다 구성되어 있으며 우선순위가 부여됩니다 Loading AOF
일반적으로 PostgreSQL에 필적하는 데이터 보안을 달성하려면 두 지속성 기능을 동시에 사용해야 합니다. 이 경우 Redis가 다시 시작되면 원본 데이터를 복원하기 위해 AOF 파일이 먼저 로드됩니다. 왜냐하면 정상적인 상황에서는 AOF 파일에 의해 저장된 데이터 세트가 RDB 파일에 의해 저장된 데이터 세트보다 더 완전하기 때문입니다.
데이터에 많은 관심을 갖고 있지만 여전히 몇 분 안에 데이터 손실을 감당할 수 있다면 RDB 지속성을 사용할 수 있습니다.
AOF 지속성만 사용하는 사용자가 많지만 정기적으로 RDB 스냅샷을 생성하는 것이 데이터베이스 백업에 매우 편리하고 RDB가 AOF보다 데이터 세트를 더 빠르게 복원하므로 이 방법은 권장되지 않습니다. 또한 RDB를 사용하면 버그를 피할 수도 있습니다. AOF 프로그램.
서버가 실행될 때만 데이터가 존재하도록 하려면 지속성 방법을 사용할 수도 없습니다.
Redis를 캐시로 사용하는 경우 일관된 해싱을 사용하여 동적 확장 및 축소를 달성합니다.
Redis를 영구 저장소로 사용하는 경우 고정된 키-노드 매핑 관계를 사용해야 하며, 한 번 결정된 노드 수는 변경할 수 없습니다. 그렇지 않은 경우(즉, Redis 노드를 동적으로 변경해야 하는 경우) 런타임 시 데이터 균형을 재조정할 수 있는 시스템을 사용해야 하며 현재는 Redis 클러스터에서만 이를 수행할 수 있습니다.
우리 모두 Redis가 키-값 데이터베이스라는 것을 알고 있으며 Redis에 캐시된 키의 만료 시간을 설정할 수 있습니다. Redis의 만료 정책은 Redis의 캐시된 키가 만료될 때 Redis가 이를 처리하는 방법을 나타냅니다.
보통 세 가지 유형의 만료 전략이 있습니다.
시간 만료: 만료 시간이 있는 각 키는 타이머를 생성해야 하며 만료 시간이 지나면 즉시 삭제됩니다. 이 전략은 만료된 데이터를 즉시 지울 수 있고 메모리 친화적이지만 만료된 데이터를 처리하는 데 많은 양의 CPU 리소스를 차지하므로 캐시 응답 시간과 처리량에 영향을 미칩니다.
지연 만료: 키에 액세스할 때만 키가 만료되었는지 판단하고, 만료되면 삭제됩니다. 이 전략은 CPU 자원을 최대한 절약할 수 있지만 메모리에는 매우 비우호적입니다. 극단적인 경우에는 만료된 많은 수의 키에 다시 액세스할 수 없으므로 삭제되지 않고 많은 양의 메모리를 차지할 수 있습니다.
주기적인 만료: 특정 시간에 특정 수의 데이터베이스 만료 사전에 있는 특정 수의 키가 스캔되고 만료된 키가 지워집니다. 이 전략은 처음 두 가지의 절충안입니다. 예약된 스캔의 시간 간격과 각 스캔의 제한된 시간 소비를 조정함으로써 다양한 상황에서 CPU와 메모리 리소스 간의 최적의 균형을 달성할 수 있습니다.
(만료 사전은 만료 시간이 설정된 모든 키의 만료 시간 데이터를 저장합니다. 여기서 키는 키 공간의 키에 대한 포인터이고 값은 밀리초 정밀도로 키의 UNIX 타임스탬프로 표시되는 만료 시간입니다. . 키 공간은 Redis 클러스터에 저장된 모든 키를 의미합니다. )
Redis는 지연 만료 전략과 주기적 만료 전략을 모두 사용합니다.
EXPIRE 및 PERSIST 명령.
캐시 서버와 함께 제공되는 캐시 무효화 전략 외에도(Redis에는 6가지 전략 중에서 선택할 수 있습니다) 기본적으로 특정 비즈니스 요구에 따라 사용자 정의 캐시 제거를 수행할 수도 있습니다.
1. 만료된 캐시를 정기적으로 정리합니다.
2. 사용된 캐시가 만료되었습니다. 만료된 경우 기본 시스템으로 이동하여 새 데이터를 얻고 캐시를 업데이트하세요.
둘 다 장단점이 있습니다. 첫 번째의 단점은 캐시된 키를 많이 유지하는 것이 더 번거롭다는 것입니다. 두 번째의 단점은 사용자가 요청할 때마다 캐시가 필요하다는 것입니다. 무효라고 판단되어 논리가 비교적 복잡합니다! 구체적으로 사용할 솔루션은 자체 애플리케이션 시나리오에 따라 평가될 수 있습니다.
Redis 메모리 데이터 세트의 크기가 특정 크기로 증가하면 데이터 제거 전략이 구현됩니다.
Redis의 메모리 제거 전략은 Redis에서 캐싱에 사용되는 메모리가 부족할 때 새로 작성해야 하는 데이터를 처리하는 방법을 의미하며, 추가 공간 적용이 필요합니다. .
1. 전역 키 공간 선택적 제거
noeviction: 메모리가 새로 작성된 데이터를 수용하기에 충분하지 않으면 새 쓰기 작업에서 오류가 보고됩니다.
allkeys-lru: 새로 작성된 데이터를 수용할 만큼 메모리가 충분하지 않은 경우 키 공간에서 가장 최근에 사용한 키를 제거합니다. (가장 일반적으로 사용되는 방식입니다.)
allkeys-random: 새로 작성된 데이터를 수용할 만큼 메모리가 충분하지 않은 경우 키 공간에서 키가 무작위로 제거됩니다.
2. 만료 시간이 설정된 키스페이스의 선택적 제거
휘발성-lru: 새로 작성된 데이터를 수용할 만큼 메모리가 부족한 경우 만료 시간이 설정된 키스페이스에서 가장 최근에 사용된 키가 제거됩니다.
휘발성-random: 메모리가 새로 작성된 데이터를 수용하기에 충분하지 않으면 만료 시간이 설정된 키 공간에서 키가 무작위로 제거됩니다.
휘발성-ttl: 새로 작성된 데이터를 수용할 만큼 메모리가 충분하지 않은 경우 만료 시간이 설정된 키 공간에서 만료 시간이 더 빠른 키가 먼저 제거됩니다.
요약
Redis의 메모리 제거 전략 선택은 만료된 키 처리에 영향을 미치지 않습니다. 메모리 제거 정책은 메모리가 부족할 때 추가 공간이 필요한 데이터를 처리하는 데 사용되며 만료 정책은 만료된 캐시 데이터를 처리하는 데 사용됩니다.
메모리.
설정된 상한에 도달하면 Redis 쓰기 명령은 오류 메시지를 반환합니다(그러나 읽기 명령은 여전히 정상적으로 반환될 수 있습니다). 또는 메모리 제거 메커니즘을 구성할 수 있으며 Redis가 메모리 상한에 도달하면 이전 콘텐츠는 플러시됩니다.
일반적으로 작은 Key-Value를 여러 개 더 컴팩트하게 함께 저장할 수 있기 때문에 Hash, list, sorted set, set 등과 같은 컬렉션 유형 데이터를 효과적으로 활용할 수 있습니다. 가능한 한 해시를 사용하십시오. 해시 테이블(해시 테이블에 저장되는 숫자가 작다는 의미)은 매우 작은 메모리를 사용하므로 데이터 모델을 최대한 해시 테이블로 추상화해야 합니다. 예를 들어 웹 시스템에 사용자 개체가 있는 경우 사용자의 이름, 성, 이메일 및 비밀번호에 대해 별도의 키를 설정하지 말고 모든 사용자 정보를 해시 테이블에 저장하세요.
Redis는 Reactor 패턴을 기반으로 하는 네트워크 이벤트 프로세서를 개발했습니다. 이 프로세서를 파일 이벤트 핸들러라고 합니다. 그 구조는 다중 소켓, IO 멀티플렉서, 파일 이벤트 디스패처 및 이벤트 프로세서의 4개 부분으로 구성됩니다. 파일 이벤트 디스패처 큐의 소비가 단일 스레드이기 때문에 Redis는 단일 스레드 모델이라고 합니다.
1. 파일 이벤트 프로세서는 I/O 다중화 프로그램을 사용하여 여러 소켓을 동시에 모니터링하고 소켓에서 현재 수행되는 작업을 기반으로 다양한 이벤트 프로세서를 소켓과 연결합니다.
2. 모니터링되는 소켓이 연결 응답(수락), 읽기(읽기), 쓰기(쓰기), 닫기(닫기) 등의 작업을 수행할 준비가 되면 해당 작업에 해당하는 파일 이벤트가 생성됩니다. , 파일 이벤트 핸들러는 이전에 소켓과 연관된 이벤트 핸들러를 호출하여 이러한 이벤트를 처리합니다.
파일 이벤트 핸들러는 단일 스레드 방식으로 실행되지만 I/O 멀티플렉서를 사용하여 여러 소켓을 수신함으로써 파일 이벤트 핸들러는 고성능 네트워크 통신 모델과 좋은 기능을 모두 구현합니다. 단일 스레드 방식으로 실행되는 Redis 서버의 다른 모듈은 Redis 내에서 단일 스레드 디자인의 단순성을 유지합니다.
트랜잭션은 단일 격리된 작업입니다. 트랜잭션의 모든 명령은 직렬화되어 순서대로 실행됩니다. 트랜잭션이 실행되는 동안 다른 클라이언트가 보낸 명령 요청으로 인해 중단되지 않습니다.
트랜잭션은 원자성 작업입니다. 즉, 트랜잭션의 모든 명령이 실행되거나 아무 것도 실행되지 않습니다.
Redis 트랜잭션의 개념
Redis 트랜잭션의 핵심은 MULTI, EXEC, WATCH와 같은 명령의 집합입니다. 트랜잭션은 한 번에 여러 명령 실행을 지원하며 트랜잭션의 모든 명령은 직렬화됩니다. 트랜잭션 실행 과정에서 큐에 있는 명령은 순서대로 순차적으로 실행되며, 다른 클라이언트가 제출한 명령 요청은 트랜잭션 실행 명령 시퀀스에 삽입되지 않습니다.
요약하자면: Redis 트랜잭션은 대기열에 있는 일련의 명령을 일회성, 순차적, 배타적으로 실행하는 것입니다.
3단계의 Redis 트랜잭션
1. 트랜잭션 시작 MULTI
2. Command enqueue
3. 트랜잭션 실행 중 EXEC, DISCARD, WATCH 이외의 요청을 받으면 MULTI는 대기열에 추가됩니다
Redis 트랜잭션 관련 명령Redis 트랜잭션 기능은 MULTI, EXEC, DISCARD 및 WATCH의 4가지 기본 요소를 통해 구현됩니다.
Redis 트랜잭션의 모든 명령은 직렬화되어 실행됩니다. 순서대로.
1.
, "Redis는 트랜잭션이 실패해도 롤백하지 않고 나머지 명령을 계속 실행합니다." 따라서 Redis의 내부는 간단하고 빠르게 유지될 수 있습니다.2.
3.
WATCH 명령은 Redis 트랜잭션에 CAS(확인 및 설정) 동작을 제공하는 낙관적 잠금입니다. 하나 이상의 키를 모니터링할 수 있습니다. 키 중 하나가 수정(또는 삭제)되면 후속 트랜잭션은 실행되지 않으며 EXEC 명령이 실행될 때까지 모니터링이 계속됩니다.
MULTI 명령은 트랜잭션을 시작하는 데 사용되며 항상 OK를 반환합니다. MULTI가 실행된 후 클라이언트는 원하는 만큼의 명령을 서버에 계속 보낼 수 있습니다. 이러한 명령은 즉시 실행되지 않지만 EXEC 명령이 호출되면 대기열에 있는 모든 명령이 실행됩니다. .
EXEC: 모든 트랜잭션 블록 내에서 명령을 실행합니다. 명령 실행 순서대로 정렬되어 트랜잭션 블록 내의 모든 명령의 반환 값을 반환합니다. 작업이 중단되면 빈 값 nil이 반환됩니다.
DISCARD를 호출하면 클라이언트는 트랜잭션 대기열을 지우고 트랜잭션 실행을 포기할 수 있으며 클라이언트는 트랜잭션 상태에서 종료됩니다.
UNWATCH 명령은 시계의 모든 키 모니터링을 취소할 수 있습니다.
트랜잭션 관리(ACID) 개요
원자성은 트랜잭션이 분할할 수 없는 작업 단위이며 트랜잭션의 작업이 모두 발생하거나 발생하지 않음을 의미합니다.
거래 전후의 데이터 무결성이 일관되어야 합니다.
여러 트랜잭션이 동시에 실행되는 경우 하나의 트랜잭션 실행이 다른 트랜잭션 실행에 영향을 주어서는 안 됩니다.
내구성은 트랜잭션이 커밋되면 데이터베이스의 데이터 변경 사항이 영구적이며 데이터베이스에 오류가 발생하더라도 아무런 영향을 미치지 않아야 함을 의미합니다.
Redis 트랜잭션은 격리를 지원합니까?
센티넬 소개
센티넬, 중국 이름은 센티넬입니다. Sentinel은 Redis 클러스터 조직에서 매우 중요한 구성 요소로 주로 다음과 같은 기능을 가지고 있습니다.
Cluster Monitoring: Redis 마스터 및 슬레이브 프로세스가 정상적으로 작동하는지 모니터링하는 역할을 담당합니다.
메시지 알림: Redis 인스턴스가 실패하면 Sentinel은 관리자에게 경보 알림 메시지를 보낼 책임이 있습니다.
Failover: 마스터 노드가 정지되면 자동으로 슬레이브 노드로 전환됩니다.
구성 센터: 장애 조치가 발생하면 클라이언트에 새 마스터 주소를 알립니다.
Sentinel은 Redis 클러스터의 고가용성을 달성하는 데 사용됩니다. 또한 분산되어 있으며 Sentinel 클러스터로 실행되며 서로 작동합니다.
1. 장애 조치 중 마스터 노드가 다운되었는지 확인하려면 대부분의 센티널의 동의가 필요하며 이는 분산 선택 문제와 관련됩니다.
2. 일부 센티넬 노드가 죽어도 센티넬 클러스터는 정상적으로 작동할 수 있는데, 고가용성 메커니즘의 중요한 부분인 페일오버 시스템 자체가 단일 지점이라면 매우 답답할 것이기 때문입니다.
Sentinel의 핵심 지식
1. Sentinel의 견고성을 보장하려면 최소 3개의 인스턴스가 필요합니다.
2. Sentinel + redis 마스터-슬레이브 배포 아키텍처는 데이터 손실 없음을 보장하지 않지만 redis 클러스터의 고가용성만 보장할 수 있습니다.
3. Sentinel + redis 마스터-슬레이브의 복잡한 배포 아키텍처의 경우 테스트 환경과 프로덕션 환경 모두에서 충분한 테스트와 훈련을 수행해 보십시오.
Redis 클러스터 모드의 작동 원리를 설명해 주실 수 있나요? 클러스터 모드에서 redis의 키는 어떻게 처리됩니까? 분산 주소 지정 알고리즘은 무엇입니까? 일관된 해시 알고리즘을 알고 있나요?
소개
Redis Cluster는 서버 측 샤딩 기술로, 버전 3.0에서 공식적으로 사용 가능합니다. Redis 클러스터는 일관된 해싱을 사용하지 않고, 총 16384개의 슬롯으로 나누어지는 슬롯 개념을 사용합니다. 임의의 노드에 요청을 보내면, 요청을 받은 노드는 실행을 위해 올바른 노드에 쿼리 요청을 보냅니다
프로젝트 설명
1. 데이터를 해싱을 통해 분할하고 각 노드에 균등하게 저장합니다. 특정 해시 슬롯(해시 값) 범위에는 기본적으로 16384개의 슬롯이 할당됩니다
2. 각 데이터 조각은 상호 마스터이자 슬레이브인 여러 노드에 저장됩니다
3. 데이터는 먼저 마스터 노드에 기록된 후 동기화됩니다. 슬레이브 노드에 (동기화 차단 구성 지원)
4. 동일한 샤드에 있는 여러 노드 간의 데이터 일관성이 유지되지 않습니다
5. 데이터를 읽을 때 클라이언트가 조작하는 키가 할당되지 않습니다. 이 노드에 있을 때 redis 조정 명령을 반환하고 올바른 노드를 가리킵니다
6. 용량을 확장할 때 이전 노드의 데이터 중 일부를 새 노드로 마이그레이션해야 합니다
redis 클러스터 아키텍처에서 각 redis는 두 가지를 릴리스해야 합니다. 예를 들어 포트 번호 중 하나는 6379이고, 다른 하나는 포트 번호에 1w를 더한 것입니다(예: 16379).
16379 포트 번호는 노드 간 통신, 즉 클러스터 버스 통신, 클러스터 버스 통신에 사용되며 오류 감지, 구성 업데이트 및 장애 조치 권한 부여에 사용됩니다. 클러스터 버스는 노드 간 효율적인 데이터 교환을 위해 또 다른 바이너리 프로토콜인gossip프로토콜을 사용하여 네트워크 대역폭과 처리 시간을 덜 차지합니다.
노드 간 내부 통신 메커니즘
기본 통신 원칙
클러스터 메타데이터를 유지하는 방법에는 중앙 집중식 프로토콜과 가십 프로토콜의 두 가지가 있습니다. 가십 프로토콜은 Redis 클러스터 노드 간 통신에 사용됩니다.
분산 주소 지정 알고리즘
해시 알고리즘(대량 캐시 재구성)
일관된 해시 알고리즘(자동 캐시 마이그레이션) + 가상 노드(자동 로드 밸런싱)
redis 클러스터의 해시 슬롯 알고리즘
장점
1. 동적 확장을 지원하며 비즈니스에 투명합니다.
2. Sentinel 모니터링 및 자동 장애 조치 기능이 있습니다
3. 클라이언트가 모든 클러스터 노드에 연결할 필요가 없습니다. 클러스터 내 사용 가능한 모든 노드에
4. 고성능, 클라이언트가 Redis 서비스에 직접 연결되므로 프록시 에이전트 손실이 없습니다
단점
1. 마이그레이션이 필요합니다
2. 0번 데이터베이스만 사용할 수 있습니다
3. 배치 작업(파이프라인 작업)은 지원되지 않습니다
4. 분산 로직 및 스토리지 모듈 결합 등
소개
Redis Sharding은 Redis Cluster가 나오기 전에 업계에서 일반적으로 사용되었던 다중 Redis 인스턴스 클러스터링 방법입니다. 주요 아이디어는 해시 알고리즘을 사용하여 Redis 데이터의 키를 해시하는 것입니다. 해시 함수를 통해 특정 키가 특정 Redis 노드에 매핑됩니다. Java Redis 클라이언트는 jedis를 구동하고 Redis Sharding 기능, 즉 캐시 풀과 결합된 ShardedJedis 및 ShardedJedisPool을 지원합니다
Advantages
장점은 서버의 Redis 인스턴스가 매우 간단하다는 것입니다. 각 Redis 인스턴스는 단일 서버와 동일하게 실행되며 선형 확장이 매우 쉽습니다. 단점: 1. 샤딩 처리가 클라이언트에 배치되므로 더욱 그렇습니다. 규모가 확장되면 운영 및 유지 관리에 어려움이 따릅니다.
2. 클라이언트 측 샤딩은 노드의 동적 추가 및 삭제를 지원하지 않습니다. 서버의 Redis 인스턴스 그룹의 토폴로지가 변경되면 각 클라이언트를 업데이트하고 조정해야 합니다. 연결을 공유할 수 없습니다. 애플리케이션 규모가 증가하면 프록시 서버 샤딩을 기반으로 리소스 낭비가 제한되고 최적화됩니다. 요청을 올바른 노드로 전달하고 최종적으로 클라이언트에 결과를 응답합니다. 액세스, 비즈니스 프로그램은 백엔드 Redis 인스턴스에 신경 쓸 필요가 없으며 전환 비용이 낮습니다
3. 성능이 저하됩니다
2, Wandoujia의 오픈 소스 Codis
Redis 마스터-슬레이브 아키텍처
단일 머신 Redis는 QPS 범위를 전달할 수 있습니다. 수만에서 수만까지. 캐시의 경우 일반적으로 높은 읽기 동시성을 지원하는 데 사용됩니다. 따라서 아키텍처는 하나의 마스터와 여러 개의 슬레이브로 구성된 마스터-슬레이브 아키텍처로 이루어집니다. 마스터는 다른 슬레이브 노드에 데이터를 쓰고 복사하는 역할을 담당하고, 슬레이브 노드는 읽는 역할을 담당합니다. 모든 읽기 요청은 슬레이브 노드로 이동합니다. 이는 또한 쉽게 수평 확장을 달성하고 높은 읽기 동시성을 지원할 수 있습니다.
redis 복제 -> 마스터-슬레이브 아키텍처 -> 읽기 및 쓰기 분리 -> 높은 읽기 동시성을 지원하는 수평 확장
1. 데이터를 슬레이브 노드에 복사하지만, redis2.8부터는 슬레이브 노드가 매번 복사하는 데이터의 양을 주기적으로 확인합니다.2. 하나의 마스터 노드를 여러 슬레이브 노드로 구성할 수 있습니다.
4. 슬레이브 노드가 복제되는 동안에는 마스터 노드의 정상적인 작업이 차단되지 않습니다.
5. 슬레이브 노드가 복제되는 동안 자체 쿼리 작업이 차단되지 않습니다. . 기존 데이터 세트를 사용하여 서비스를 제공하지만, 복사가 완료되면 기존 데이터 세트를 삭제해야 하며 이때 외부 서비스는 중단됩니다.
슬레이브 노드와 마스터 노드 사이에 네트워크 장애가 발생하여 연결이 끊어지면 자동으로 다시 연결됩니다. 연결 후 마스터 노드는 누락된 데이터만 슬레이브에 복사합니다.
1. 슬레이브 라이브러리와 메인 라이브러리 간의 MS 관계가 설정되면 SYNC 명령이 메인 데이터베이스로 전송됩니다.
2. SYNC 명령을 받은 후 메인 라이브러리는 백그라운드에서 스냅샷 저장을 시작합니다. RDB 지속성 프로세스) 및 쓰기 명령이 캐시됩니다
3. 스냅샷이 완료되면 마스터 Redis는 스냅샷 파일과 캐시된 모든 쓰기 명령을 Redis로부터 받은 후 슬레이브 Redis로 보냅니다. 스냅샷 파일을 로드하고 수신된 캐시된 명령을 실행합니다
5. 이후 마스터 Redis가 쓰기 명령을 받을 때마다 해당 명령을 슬레이브 Redis로 보내 데이터 일관성을 보장합니다
모든 슬레이브 노드 데이터 복제 및 동기화는 마스터 노드 처리에 의해 수행되므로 마스터 노드에 너무 많은 부담이 발생합니다. 이를 해결하려면 마스터-슬레이브 구조를 사용하세요
Redis 클러스터의 마스터-슬레이브 복제 모델은 무엇인가요?일부 노드가 실패하거나 대부분의 노드가 통신할 수 없는 경우에도 클러스터를 계속 사용할 수 있도록 하기 위해 클러스터는 마스터-슬레이브 복제 모델을 사용하며 각 노드는 N-1 복제본을 갖게 됩니다.
Redis는 프로덕션 환경에서 어떻게 작동합니까? 배포됐나요?
기계 구성은 어떻게 되나요? 32G 메모리 + 8코어 CPU + 1T 디스크인데, Redis 프로세스에 할당되는 메모리는 10g입니다. 일반적인 온라인 프로덕션 환경에서는 Redis의 메모리가 10g을 초과하면 문제가 발생할 수 있습니다.
5대의 머신은 총 50g의 메모리로 외부 읽기 및 쓰기 기능을 제공합니다.
각 마스터 인스턴스에는 슬레이브 인스턴스가 있으므로 가용성이 높습니다. 마스터 인스턴스가 다운되면 자동으로 장애 조치가 수행되고 Redis 슬레이브 인스턴스는 자동으로 마스터 인스턴스가 되어 읽기 및 쓰기 서비스를 계속 제공합니다.
메모리에 어떤 데이터를 쓰고 있나요? 각 데이터 조각의 크기는 얼마입니까? 제품 데이터, 각 데이터는 10kb입니다. 데이터 100개가 1MB이고, 데이터 100,000개가 1g입니다. 메모리에는 200만 개의 제품 데이터가 상주하고 있으며, 점유된 메모리는 20g으로 전체 메모리의 50%에도 미치지 못합니다. 현재 피크 기간은 초당 약 3,500건의 요청입니다.
실제로 대기업에는 캐시 클러스터의 운영 및 유지 관리를 담당하는 인프라 팀이 있습니다.
2. 에이전트 파티셔닝은 클라이언트가 에이전트에 요청을 보낸 다음 에이전트가 데이터를 쓰거나 읽을 노드를 결정하는 것을 의미합니다. 에이전트는 파티션 규칙에 따라 요청할 Redis 인스턴스를 결정한 다음 Redis 응답 결과에 따라 이를 클라이언트에 반환합니다. redis 및 memcached에 대한 프록시 구현은 Twemproxy입니다.
3. 쿼리 라우팅은 클라이언트가 임의의 Redis 인스턴스를 무작위로 요청한 다음 Redis가 해당 요청을 올바른 Redis 노드로 전달하는 것을 의미합니다. Redis 클러스터는 하이브리드 형태의 쿼리 라우팅을 구현하지만 한 Redis 노드에서 다른 Redis 노드로 요청을 직접 전달하는 대신 클라이언트의 도움을 받아 올바른 Redis 노드로 직접 리디렉션합니다.
1. 여러 키를 사용하는 작업은 일반적으로 지원되지 않습니다. 예를 들어 두 컬렉션은 서로 다른 Redis 인스턴스에 저장될 수 있으므로 교차할 수 없습니다(실제로 이러한 상황에 대한 방법이 있지만 Intersection 명령을 직접 사용할 수는 없습니다).
2. 여러 키를 동시에 조작하는 경우 Redis 트랜잭션을 사용할 수 없습니다.
3. 분할 세분성이 핵심이므로 매우 큰 정렬 세트처럼 하나의 거대한 키로 데이터세트를 분할할 수 없습니다.)
4. 파티션을 사용하면 데이터 처리가 매우 복잡해집니다. 백업을 위해서는 여러 Redis 인스턴스 및 호스트에서 동시에 RDB/AOF 파일을 수집해야 합니다.
5. 파티셔닝 중 동적 확장 또는 축소는 매우 복잡할 수 있습니다. Redis 클러스터는 런타임에 Redis 노드를 추가하거나 삭제하여 사용자에게 최대한 투명한 데이터 재조정을 달성할 수 있습니다. 그러나 일부 다른 클라이언트 분할 또는 프록시 분할 방법은 이 기능을 지원하지 않습니다. 하지만 이 문제를 더 잘 해결할 수 있는 사전 샤딩 기술도 있습니다.
Redis는 단일 프로세스 단일 스레드 모드로 동시 액세스를 직렬 액세스로 전환하며 SETNX에 대한 여러 클라이언트 연결 간에 경쟁이 없습니다. Redis 명령에서 분산 잠금을 구현하는 데 사용됩니다.
키가 존재하지 않는 경우에만 키 값을 value로 설정하세요. 주어진 키가 이미 존재하면 SETNX는 아무런 조치도 취하지 않습니다.
SETNX는 "SET if Not eXists"(존재하지 않으면 SET)의 약어입니다.
반환 값: 성공적으로 설정되면 1을 반환합니다. 설치가 실패하고 0을 반환합니다.
SETNX를 사용하여 동기화 잠금을 완료하는 과정과 사항은 다음과 같습니다.
SETNX 명령을 사용하여 잠금을 획득합니다. 0이 반환되면(키가 이미 존재, 잠금이 이미 존재함) 획득이 실패합니다.
잠금을 획득한 후 프로그램 예외를 방지하려면 SETNX 명령을 호출하고 교착 상태에 들어갈 때 다른 스레드/프로세스가 항상 0을 반환하도록 하려면 "합리적인" 만료 시간을 설정해야 합니다. key
잠금을 해제하고 DEL 명령을 사용하여 잠금 데이터를 삭제합니다
Redis에서 키 동시 경쟁 문제는 여러 시스템이 동시에 키를 조작하지만 최종 실행 순서가 예상한 순서와 달라 결과가 달라집니다!
해결책 추천: 분산 잠금(Zookeeper와 Redis 모두 분산 잠금을 구현할 수 있음) (Redis에서 Key에 대한 동시 경쟁이 없는 경우 분산 잠금을 사용하지 마십시오. 성능에 영향을 미칠 수 있습니다.)
주키퍼의 임시 주문 노드를 기반으로 하는 분산 잠금입니다. 일반적인 아이디어는 각 클라이언트가 특정 메소드를 잠그면 Zookeeper의 메소드에 해당하는 지정된 노드의 디렉토리에 고유한 순간 순서 노드가 생성된다는 것입니다. 잠금 획득 여부를 결정하는 방법은 매우 간단합니다. 순서가 지정된 노드 중 가장 작은 시퀀스 번호만 결정하면 됩니다. 잠금이 해제되면 임시 노드를 삭제하면 됩니다. 동시에 서비스 가동 중지 시간으로 인해 해제할 수 없는 잠금으로 인해 발생하는 교착 상태 문제를 방지할 수 있습니다. 비즈니스 프로세스 완료 후 해당 하위 노드를 삭제하여 잠금을 해제합니다.
실습에서는 당연히 신뢰성이 최우선입니다. 따라서 Zookeeper를 먼저 권장합니다.
Redis는 매우 가볍기 때문에(단일 인스턴스는 1M 메모리만 사용) 향후 확장을 방지하는 가장 좋은 방법은 처음부터 더 많은 인스턴스를 시작하는 것입니다. 서버가 하나만 있는 경우에도 파티션을 사용하여 동일한 서버에서 여러 인스턴스를 시작하여 Redis를 처음부터 분산 방식으로 실행할 수 있습니다.
처음에는 32개 또는 64개 인스턴스 등 몇 가지 Redis 인스턴스를 더 설정합니다. 이는 대부분의 사용자에게 번거로울 수 있지만 장기적으로는 희생할 가치가 있습니다.
이 경우 데이터가 계속해서 증가하고 더 많은 Redis 서버가 필요할 때 해야 할 일은 Redis 인스턴스를 한 서비스에서 다른 서버로 마이그레이션하기만 하면 됩니다(재파티셔닝 문제를 고려하지 않음). 다른 서버를 추가한 후에는 Redis 인스턴스의 절반을 첫 번째 머신에서 두 번째 머신으로 마이그레이션해야 합니다.
공식 Redis 웹사이트에서는 Redlock이라는 Redis 기반의 분산 잠금을 구현하는 권위 있는 방법을 제안했습니다. 이 방법은 원래의 단일 노드 방법보다 더 안전합니다. 다음 기능을 보장할 수 있습니다:
1. 보안 기능: 상호 배타적 액세스, 즉 항상 하나의 클라이언트만 잠금을 얻을 수 있습니다.
2. 교착 상태를 피하세요. 결국 모든 클라이언트가 잠금을 얻을 수 있습니다. 원래 리소스를 잠근 클라이언트가 충돌하거나 네트워크 파티션이 발생하더라도 교착 상태가 발생하지 않습니다
3. 내결함성: 대부분의 Redis 노드가 생존하는 한 서비스는 정상적으로 제공될 수 있습니다
Cache Avalanche
Cache Avalanche는 동시에 대규모 캐시 오류를 의미합니다. 따라서 후속 요청이 데이터베이스에 떨어지게 되어 데이터베이스가 짧은 기간에 많은 요청을 견딜 수 있게 됩니다. 시간과 붕괴.
Solution
1. 캐시된 데이터의 만료 시간을 무작위로 설정하여 많은 양의 데이터가 동시에 만료되는 것을 방지하세요.
2. 일반적으로 동시성 양이 특별히 크지 않은 경우 가장 일반적으로 사용되는 솔루션은 잠금 및 대기열입니다.
3. 캐시된 각 데이터에 해당 캐시 태그를 추가하고 캐시가 유효하지 않은지 기록합니다. 캐시 태그가 유효하지 않은 경우 데이터 캐시를 업데이트합니다.
캐시 침투
캐시 침투란 캐시에도 데이터베이스에도 없는 데이터를 말하며 모든 요청이 데이터베이스에 떨어지게 하여 데이터베이스가 짧은 시간 내에 많은 수의 요청을 견딜 수 있게 만듭니다. 시간과 붕괴.
Solution
1. 사용자 인증 확인, ID 기본 확인, ID<=0; 직접 가로채기 등 인터페이스 계층에 확인을 추가합니다.
2. 이때 키-값 쌍은 key-null로 기록될 수도 있습니다. 캐시 유효 시간은 30초 등 더 짧게 설정할 수 있습니다. (너무 길게 설정하면 정상적으로 사용할 수 없게 됩니다. 상황). 이렇게 하면 사용자가 동일한 ID를 반복적으로 사용하여 무차별 대입 공격을 하는 것을 방지할 수 있습니다.
3. 블룸 필터를 사용하여 존재해서는 안 되는 데이터를 충분히 큰 비트맵으로 해시합니다. 기본 스토리지 시스템에 대한 쿼리 부담을 피합니다.
추가
비트맵과 블룸필터, 즉 공간 활용도가 극도로 높아졌습니다.
Bitmap: 대표적인 것이 해시 테이블입니다
단점은 Bitmap이 각 요소에 대해 1비트의 정보만 기록할 수 있다는 점입니다. 추가 기능을 완성하려면 더 많은 것을 희생해야만 할 수 있습니다. 공간과 시간.
Bloom 필터(권장)
는 k(k>1)k(k>1) 독립적인 해시 함수를 도입하여 요소가 주어진 공간 내에서 완성되도록 하고 오판율을 판단하는 과정입니다.
일반적인 알고리즘에 비해 공간 효율성과 쿼리 시간이 훨씬 높다는 장점이 있고, 오인식률이 일정하고 삭제가 어렵다는 단점이 있습니다.
블룸 필터 알고리즘의 핵심 아이디어는 여러 가지 해시 함수를 사용하여 "충돌"을 해결하는 것입니다.
해시에는 충돌(충돌) 문제가 있으며, 동일한 해시를 사용하여 얻은 두 URL의 값이 동일할 수 있습니다. 충돌을 줄이기 위해 해시를 여러 개 더 도입할 수 있습니다. 해시 값 중 하나를 통해 요소가 집합에 없다고 결론을 내리면 해당 요소는 확실히 집합에 없습니다. 모든 해시 함수가 해당 요소가 집합에 있음을 알려주는 경우에만 해당 요소가 집합에 존재하는지 확인할 수 있습니다. 이것이 Bloom-Filter의 기본 아이디어입니다.
Bloom-Filter는 일반적으로 대규모 데이터 세트에 요소가 존재하는지 확인하는 데 사용됩니다.
캐시 분해
캐시 분해는 캐시에는 없지만 데이터베이스에 있는 데이터를 말합니다(보통 캐시 시간이 만료된 경우). 이때 동시 사용자 수가 많아 데이터가 동시에 캐시에서 읽혀지지 않고 동시에 데이터를 검색하기 위해 데이터베이스로 이동하므로 데이터베이스에 대한 부담이 순간적으로 증가하여 과도한 부담이 발생합니다. Cache Avalanche는 Cache Avalanche와 달리 동일한 데이터의 동시 쿼리를 의미하며, Cache Avalanche는 다른 데이터가 만료되어 많은 데이터를 찾을 수 없어 데이터베이스를 검색하는 것을 의미합니다.
솔루션
1. 핫스팟 데이터가 만료되지 않도록 설정
2. 뮤텍스 잠금 추가, 뮤텍스 잠금
캐시 예열
캐시 예열은 시스템이 온라인 상태가 된 후 관련 캐시 데이터가 캐시 시스템에 직접 로드됩니다. 이런 방식으로 먼저 데이터베이스를 쿼리한 다음 사용자가 요청할 때 데이터를 캐싱하는 문제를 피할 수 있습니다! 예열된 캐시 데이터를 사용자가 직접 쿼리!
해결 방법
1. 온라인에 접속할 때 캐시 새로 고침 페이지를 직접 작성하고
2. 데이터 양이 많지 않으며 프로젝트 시작 시 자동으로 로드할 수 있습니다. 정기적으로 캐시
캐시 다운그레이드트래픽이 급격히 증가하거나, 서비스 문제가 발생하거나(예: 느린 응답 시간 또는 응답 없음), 비핵심 서비스가 핵심 프로세스의 성능에 영향을 미치는 경우에도 다음을 확인해야 합니다. 서비스에 장애가 발생하더라도 서비스는 계속 제공됩니다. 시스템은 일부 주요 데이터를 기반으로 자동으로 다운그레이드하거나 스위치를 구성하여 수동으로 다운그레이드할 수 있습니다.
캐시 다운그레이드의 궁극적인 목표는 손실이 발생하더라도 핵심 서비스를 사용할 수 있도록 보장하는 것입니다. 그리고 일부 서비스(장바구니에 추가, 결제 등)는 다운그레이드할 수 없습니다.
다운그레이드하기 전에 시스템이 병사를 잃고 지휘관을 유지할 수 있는지 확인하여 죽음까지 보호해야 할 것과 다운그레이드할 수 있는 것을 분류해야 합니다. 예를 들어 로그 수준을 참조할 수 있습니다. 계획 설정:
1. 일반: 예: 일부 서비스는 네트워크 불안정으로 인해 때때로 시간이 초과되거나 서비스가 온라인 상태가 되어 자동으로 다운그레이드될 수 있습니다. 95~100% 사이), 자동으로 다운그레이드되거나 수동으로 다운그레이드될 수 있으며 알람을 보낼 수 있습니다.
3. 오류: 예를 들어, 가용성 비율이 90%보다 낮거나 데이터베이스 연결 풀이 폭발합니다. 방문 횟수가 시스템이 감당할 수 있는 최대 한도까지 갑자기 증가합니다. 이때 상황에 따라 자동으로 다운그레이드될 수도 있습니다.
4. 심각한 오류: 예를 들어 특별한 사유로 인해 데이터가 잘못된 경우 긴급 수동 다운그레이드가 필요합니다.
서비스 다운그레이드의 목적은 Redis 서비스 오류로 인해 데이터베이스에 눈사태 문제가 발생하는 것을 방지하는 것입니다. 따라서 중요하지 않은 캐시 데이터의 경우 서비스 다운그레이드 전략을 채택할 수 있습니다. 예를 들어 Redis에 문제가 있으면 데이터베이스를 쿼리하는 대신 기본값을 사용자에게 직접 반환하는 것이 일반적인 접근 방식입니다.
핫 데이터와 콜드 데이터
핫 데이터, 캐시는 소중합니다
콜드 데이터의 경우 다시 액세스하기 전에 대부분의 데이터가 메모리에서 압착되어 메모리를 차지할 뿐만 아니라, 하지만 가치도 있습니다. 크지는 않습니다. 자주 수정되는 데이터는 상황에 따라 캐시 활용을 고려해 보세요
저희 메신저 제품 중 하나, 생일 인사말 모듈, 오늘의 생일 목록 등 핫 데이터의 경우 캐시를 수십만 번 읽을 수 있습니다. 또 다른 예로 내비게이션 제품에서는 내비게이션 정보를 캐시하고 향후 수백만 번 읽을 수도 있습니다.
캐시는 업데이트하기 전에 데이터를 두 번 이상 읽는 경우에만 의미가 있습니다. 이것이 가장 기본적인 전략입니다. 캐시가 적용되기 전에 실패하면 별 가치가 없습니다.
캐시가 존재하지 않고 수정 빈도가 매우 높지만 캐싱을 고려해야 하는 시나리오는 어떻습니까? 가지다! 예를 들어, 이 읽기 인터페이스는 데이터베이스에 많은 부담을 주지만 동시에 핫 데이터이기도 합니다. 이때 좋아요 수, 컬렉션 수 등 데이터베이스에 대한 부담을 줄이기 위한 캐싱 방법을 고려해야 합니다. 이는 매우 일반적인 핫 데이터이지만 계속 변경됩니다. 이때 데이터는 데이터베이스에 대한 부담을 줄이기 위해 동기식으로 Redis 캐시에 저장되어야 합니다.
캐시 핫스팟 키
캐시 내 키(예: 판촉물)는 특정 시점에 만료되며, 이 시점에서 해당 키에 대한 동시 요청이 많습니다. 요청 찾기 캐시가 만료되면 일반적으로 데이터가 백엔드 DB에서 로드되고 캐시로 재설정됩니다. 이때 대규모 동시 요청이 즉시 백엔드 DB를 압도할 수 있습니다.
Solution
캐시 쿼리를 잠급니다. KEY가 존재하지 않으면 이를 잠근 다음 DB를 캐시로 확인한 다음 잠금을 해제합니다. 다른 프로세스는 잠금을 찾은 다음 데이터를 반환합니다. Query
Redis에서 지원하는 Java 클라이언트는 무엇인가요? 공식적으로 권장되는 것은 무엇입니까?
Redisson, Jedis, 양상추 등 공식적인 권장 사항은 Redisson을 사용하는 것입니다.
Redis와 Redisson은 어떤 관계인가요?
Redisson은 사용자가 분산 환경, Queue, BlockingQueue에서 일부 Java 객체(Bloom filter, BitSet, Set, SetMultimap, ScoredSortedSet, SortedSet, Map, ConcurrentMap, List, ListMultimap)를 쉽게 구현할 수 있도록 도와주는 고급 분산 조정 Redis 클라이언트입니다. , Deque, BlockingDeque, Semaphore, Lock, ReadWriteLock, AtomicLong, CountDownLatch, 게시/구독, HyperLogLog).
Jedis와 Redisson의 장점과 단점은 무엇인가요?
Jedis는 Redis용 Java로 구현된 클라이언트입니다. Redisson은 Jedis에 비해 분산되고 확장 가능한 Java 데이터 구조를 구현하며 문자열 작업을 지원하지 않습니다. 정렬, 트랜잭션, 파이프라인, 파티션과 같은 Redis 기능을 지원하지 않습니다. Redisson의 목적은 Redis에서 사용자의 우려사항을 분리하여 사용자가 비즈니스 로직 처리에 더 집중할 수 있도록 하는 것입니다.
Redis와 Memcached의 차이점
둘 다 비관계형 메모리 키-값 데이터베이스입니다. 요즘 기업에서는 일반적으로 Redis를 사용하여 캐싱을 구현하고 있으며 Redis 자체도 점점 더 강력해지고 있습니다. . Redis와 Memcached의 주요 차이점은 다음과 같습니다.
문자열, 정수 또는 부동 소수점 숫자 |
전체 문자열 또는 문자열의 일부에 대해 작업을 수행합니다. | 정수 및 부동 소수점 숫자에 대해 증가 또는 감소 작업을 수행합니다.간단한 키-값 쌍 캐싱 수행 |
|
List |
양쪽 끝에서 요소를 밀어넣거나 팝합니다. | 범위 내의 요소만 유지하면서 단일 또는 여러 요소를 잘라냅니다.팬 목록, 기사 댓글 목록 및 기타 데이터와 유사한 일부 목록 유형 데이터 구조를 저장합니다. |
|
순서가 지정되지 않은 집합 |
단일 요소 추가, 가져오기 및 제거 | 요소가 집합에 있는지 확인
교집합, 합집합, 차이 계산 집합에서 무작위로 요소 가져오기 교차점과 같은 작업은 두 사람의 팬 목록을 하나의 교차점으로 결합할 수 있습니다. |
HASH |
| Hash |
단일 키-값 쌍을 추가, 가져오기 및 제거 모든 키-값 쌍 가져오기; | 키가 있는지 확인
객체와 같은 구조화된 데이터 |
ZSET |
| 요소 추가, 가져오기, 삭제 점수 범위 또는 멤버 가져오기에 따라 | 순위를 계산합니다. 키
중복 제거되지만 상위 사용자 확보와 같이 정렬 가능 |
redis는 롤백을 지원하지 않습니다트랜잭션의 명령에 오류가 발생하면 모든 명령이 실행되지 않습니다.트랜잭션에서 실행 오류가 발생하면 올바른 명령이 실행됩니다.Redis는 단일 프로세스 프로그램으로 트랜잭션 실행 시 트랜잭션이 중단되지 않고 트랜잭션 대기열의 모든 명령이 실행될 때까지 트랜잭션이 실행될 수 있음을 보장합니다. 따라서 Redis 트랜잭션은 항상 격리됩니다.Redis 트랜잭션은 원자성을 보장하고 롤백을 지원합니까? Redis에서는 단일 명령이 원자적으로 실행되지만 트랜잭션은 원자성을 보장하지 않으며 롤백도 없습니다. 트랜잭션의 명령 중 하나라도 실행이 실패하더라도 나머지 명령은 계속 실행됩니다.Redis 트랜잭션의 다른 구현2. 프록시 로직 및 스토리지 로직이 격리되어 있습니다업계 오픈 소스 솔루션1. Twtter의 오픈 소스 TwemproxyRedis 복제의 핵심 메커니즘이 외에도 마스터를 위한 다양한 백업 계획도 이루어져야 합니다. 로컬 파일이 모두 손실된 경우 백업에서 RDB를 선택하여 마스터를 복원하면 시작 시 데이터가 유지됩니다. 나중에 설명하는 고가용성 메커니즘이 채택되더라도 슬레이브 노드가 자동으로 마스터를 인수할 수 있습니다. 그러나 Sentinel이 마스터 장애를 감지하기 전에 마스터 노드가 자동으로 다시 시작되거나 위의 모든 슬레이브 노드 데이터가 지워질 수도 있습니다.redis 마스터-슬레이브 복제의 핵심 원칙슬레이브 노드가 시작되면 PSYNC 명령을 마스터 노드로 보냅니다.슬레이브 노드가 마스터 노드에 처음 연결되는 경우 전체 재동기화 전체 복사가 실행됩니다. 이때 마스터는 백그라운드 스레드를 시작하고 RDB 스냅샷 파일 생성을 시작합니다. 동시에 클라이언트로부터 새로 수신된 모든 쓰기 명령이 메모리에 캐시됩니다. RDB 파일이 생성된 후 마스터는 RDB를 슬레이브에 보냅니다. 슬레이브는 먼저 이를 로컬 디스크에 쓴 다음 로컬 디스크에서 메모리로 로드합니다. 그런 다음 마스터는 캐시된 쓰기 명령을 보냅니다. 슬레이브에 대한 메모리 이 데이터도 동기화됩니다.프로세스 원리단점redis 클러스터, 10개 머신은 Redis 마스터 인스턴스로 배포되고 나머지 5개 머신은 Redis 슬레이브 인스턴스로 배포되며, 5개 노드는 외부 읽기 및 쓰기 서비스를 제공합니다. 한 노드의 쓰기 최대 qps는 초당 50,000에 도달할 수 있으며, 5개 시스템의 최대 읽기 및 쓰기 요청/초는 250,000입니다.Redis 해시 슬롯의 개념에 대해 이야기해 보세요.Redis 클러스터는 일관된 해싱을 사용하지 않지만 해시 슬롯 개념을 도입합니다. Redis 클러스터에는 16384개의 해시 슬롯이 있습니다. 각 키는 CRC16에 의해 확인되고 모듈로 16384는 클러스터에 배치할 슬롯을 결정합니다. 해시 슬롯의 일부에 대해.Redis 클러스터에서 쓰기 작업이 손실되나요? 왜?Redis는 데이터의 강력한 일관성을 보장하지 않습니다. 즉, 실제로 특정 조건에서는 클러스터의 쓰기 작업이 손실될 수 있습니다.Redis 클러스터는 어떻게 복제되나요?비동기 복제Redis 클러스터의 최대 노드 수는 몇 개입니까?16384Redis 클러스터용 데이터베이스를 선택하는 방법은 무엇입니까?Redis 클러스터는 현재 데이터베이스를 선택할 수 없으며 기본값은 데이터베이스 0입니다.Redis는 단일 스레드인데, 멀티 코어 CPU 활용도를 높이는 방법은 무엇입니까?동일한 서버에 여러 개의 Redis 인스턴스를 배포하여 서로 다른 서버로 사용할 수도 있지만, 어차피 서버 하나로는 부족할 때가 있기 때문에 여러 개의 CPU를 사용하고 싶다면 샤딩을 고려해 볼 수 있습니다.Redis 파티셔닝이 필요한 이유는 무엇인가요?파티션을 사용하면 Redis가 더 큰 메모리를 관리할 수 있으며 Redis는 모든 시스템의 메모리를 사용할 수 있습니다. 파티션이 없으면 최대 한 대의 머신 메모리만 사용할 수 있습니다. 파티셔닝을 사용하면 단순히 컴퓨터를 추가하는 것만으로도 Redis의 컴퓨팅 성능을 두 배로 늘릴 수 있으며, 컴퓨터와 네트워크 카드를 추가하면 Redis의 네트워크 대역폭도 기하급수적으로 증가합니다.어떤 Redis 파티션 구현 솔루션을 사용할 수 있는지 아시나요?1. 클라이언트 측 파티셔닝은 클라이언트가 데이터를 저장하거나 읽을 Redis 노드를 이미 결정했음을 의미합니다. 대부분의 클라이언트는 이미 클라이언트측 파티셔닝을 구현하고 있습니다. |
| 비교 매개변수 |
redis | memcached |
| type | 1. 비관계형 데이터베이스 | 1. 2. 키 값 쌍 형식 3. 캐시 형식 |
| 데이터 저장 유형 | 1. 문자열 2. 목록 3. 집합 4. 해시 5. 정렬 집합 [통칭 ZSet] | 1. 텍스트 유형 2. 바이너리 유형 |
| 쿼리 [작업] ] 유형 | 1. 트랜잭션 지원 3. 유형별로 다른 CRUD | 1. 일반적으로 사용되는 CRUD 2. 소수의 기타 명령 |
| 추가 기능 | 1. 마스터-슬레이브 파티션 3. 직렬화 지원 4. 스크립트 지원 [Lua 스크립트] | 1. 멀티 스레드 서비스 지원 |
| 네트워크 IO 모델 | 싱글 스레드 멀티 채널 IO 재사용 모델 |
1. 스레드, 비차단 IO 모드 |
| 이벤트 라이브러리 |
AeEvent | LibEvent |
| 지속성 지원 |
1. AOF | 지원되지 않음 |
| 클러스터 모드 |
기본적으로 클러스터 모드를 지원하므로 마스터-슬레이브 복제, 읽기-쓰기 분리를 실현할 수 있습니다 |
기본 클러스터 모드가 없으므로 클러스터의 샤드에 데이터를 쓰려면 클라이언트에 의존해야 합니다 |
| 메모리 관리 메커니즘 |
Redis에서는 모든 데이터가 항상 메모리에 저장되는 것은 아니며 오랫동안 사용되지 않은 일부 값은 디스크로 교환될 수 있습니다. Memcached 데이터는 항상 메모리에 저장됩니다. 메모리 조각화 문제를 완전히 해결하기 위해 특정 길이의 블록으로 데이터를 저장합니다. 그러나 이 방법을 사용하면 메모리 사용률이 낮아집니다. 예를 들어 블록 크기가 128바이트이고 100바이트의 데이터만 저장되면 나머지 28바이트가 낭비됩니다. | |
복잡한 데이터 구조, 지속성, 고가용성 요구 사항, 큰 가치의 스토리지 콘텐츠 |
순수한 키-값, 매우 많은 양의 데이터, 매우 큰 동시성 비즈니스 |
(2) redis는 memcached보다 훨씬 빠릅니다.
(3) redis는 데이터를 유지할 수 있습니다.
이중 쓰기 중에 데이터 일관성을 보장하는 방법 캐시와 데이터베이스 사이?캐시를 사용하는 한, 이중 저장과 캐시 및 데이터베이스의 이중 쓰기가 포함될 수 있습니다. 그러면 데이터 일관성 문제가 발생하게 됩니다. 그러면 일관성 문제를 어떻게 해결합니까?
일반적으로 시스템이 캐시 + 데이터베이스 일관성을 엄격하게 요구하지 않는 경우 캐시가 데이터베이스와 약간 불일치할 수 있습니다. 이 솔루션을 사용하지 않는 것이 가장 좋으며 쓰기 요청은 메모리에 직렬화됩니다. 불일치가 없도록 하기 위해 직렬화 후에는 시스템 처리량이 크게 줄어들고 일반적인 상황보다 몇 배 더 많은 시스템이 사용됩니다.
일시적인 불일치가 발생할 수 있는 또 다른 방법이 있지만 발생할 가능성은 매우 적습니다. 즉,
데이터베이스를 먼저 업데이트한 다음 캐시를 삭제하는 것입니다.
Description |
Solution | 먼저 캐시에 쓴 다음 데이터베이스에 쓰고, 캐시 쓰기 성공, 데이터베이스 쓰기 실패 |
| 먼저 데이터베이스에 쓴 다음 캐시에 씁니다. failed | 데이터베이스에 쓰기는 성공했지만 캐시에 쓰기가 실패하면 다음 번에 캐시를 읽습니다(동시 읽기 시). 데이터를 읽을 수 없습니다. | |
| 캐시의 비동기 새로 고침이 필요합니다 | 는 데이터베이스 작업 및 쓰기 캐시를 의미합니다. 예를 들어 분산 시나리오에서는 캐시를 동시에 쓸 수 없거나 비동기식 새로 고침이 필요한 경우(해결 방법), 그러한 시나리오에 적합한 데이터를 결정하고, 경험적 값을 기반으로 합리적인 데이터 불일치 시간을 결정하고, 사용자 데이터 시간 간격을 새로 고치십시오 | |
Redis의 일반적인 성능 문제와 해결 방법은 무엇입니까? 1. 마스터는 메모리 스냅샷 및 AOF 로그 파일을 포함한 지속성 작업을 수행하지 않는 것이 가장 좋습니다. 특히 지속성을 위해 메모리 스냅샷을 활성화하지 마십시오. 2. 데이터가 중요한 경우 슬레이브는 AOF 백업 데이터를 활성화하며 1초에 한 번씩 동기화하는 전략입니다. 3. 마스터-슬레이브 복제 속도와 연결 안정성을 위해서는 슬레이브와 마스터가 동일한 LAN에 있는 것이 가장 좋습니다. 4. 스트레스를 받는 메인 라이브러리에 슬레이브 라이브러리를 추가하지 마세요. 5. 마스터는 AOF 파일을 다시 작성하기 위해 BGREWRITEAOF를 호출하여 재작성 중에 많은 양의 CPU와 메모리 리소스를 차지하게 됩니다. 잠시 서비스가 중단되었습니다. 6. 마스터의 안정성을 위해 마스터-슬레이브 복제에는 그래프 구조를 사용하지 마십시오. 즉, 마스터-슬레이브 관계는 다음과 같습니다. Slave1 Redis는 왜 Windows 버전을 공식적으로 제공하지 않나요? 현재 Linux 버전은 상당히 안정적이고 사용자 수가 많기 때문에 호환성 및 기타 문제가 발생할 수 있는 Windows 버전을 개발할 필요가 없습니다. 문자열형 값이 저장할 수 있는 최대 용량은 얼마인가요? 512M Redis는 어떻게 대용량 데이터를 삽입하나요? Redis 2.6부터 redis-cli는 대량의 데이터 삽입 작업을 수행하기 위해 파이프 모드라는 새로운 모드를 지원합니다. Redis에 1억 개의 키가 있고 그 중 100,000개가 고정된 알려진 접두사로 시작한다고 가정합니다. 키를 모두 찾는 방법은 무엇일까요? key 명령을 사용하여 지정된 패턴의 키 목록을 검색하세요. 그러자 상대방은 이렇게 물었습니다. 이 Redis가 온라인 비즈니스에 서비스를 제공하고 있다면, 키 명령을 사용할 때 어떤 문제가 있나요? 이제 Redis의 핵심 기능인 Redis의 단일 스레딩에 답해야 합니다. 키 명령으로 인해 스레드가 일정 시간 동안 차단되고 명령이 실행될 때까지 온라인 서비스가 일시 중지됩니다. 이때, scan 명령을 사용하면 차단 없이 지정된 모드의 키 목록을 추출할 수 있지만, 클라이언트에서 한 번만 수행하면 어느 정도 중복될 가능성이 있지만, 전체 시간이 소요됩니다. 직접 사용하는 것보다 길어집니다. Redis를 사용하여 비동기 대기열을 구현해 본 적이 있나요? 목록 유형을 사용하여 데이터 정보를 저장하고, rpush는 메시지를 생성하고, lpop은 메시지를 소비합니다. lpop에 메시지가 없으면 잠시 잠자다가 원하지 않는 경우 정보가 있는지 확인하면 됩니다. sleep, 정보가 없으면 blpop을 사용할 수 있습니다. 정보가 도착할 때까지 차단됩니다. Redis는 게시/구독 주제 구독 모델을 통해 하나의 생산자와 여러 소비자를 구현할 수 있습니다. 물론 소비자가 오프라인 상태가 되면 생성된 메시지가 손실됩니다. Redis는 지연 대기열을 어떻게 구현하나요? sortedset를 사용하고, 타임스탬프를 점수로 사용하고, 메시지 내용을 키로 사용하고, zadd를 호출하여 메시지를 생성하고, 소비자는 zrangbyscore를 사용하여 폴링 처리를 위해 n초 전의 데이터를 얻습니다. Redis 재활용 프로세스는 어떻게 진행되나요? 1. 클라이언트가 새 명령을 실행하고 새 데이터를 추가했습니다. 2. Redis는 메모리 사용량을 확인하여 maxmemory 한도를 초과하면 설정된 전략에 따라 재활용됩니다. 3. 새로운 명령이 실행됩니다. 4. 그래서 우리는 지속적으로 경계에 도달한 다음 계속해서 경계 아래로 다시 재활용하여 메모리 한계의 경계를 넘습니다. 명령 결과로 인해 많은 양의 메모리가 사용되는 경우(예: 큰 세트의 교차점을 새 키에 저장) 이 메모리 사용량으로 인해 메모리 제한이 초과되는 데 오래 걸리지 않습니다. . Redis 재활용에는 어떤 알고리즘이 사용되나요? LRU 알고리즘 더 많은 프로그래밍 관련 지식을 보려면프로그래밍 교육을 방문하세요! ! |
위 내용은 Redis 고주파 인터뷰 질문(답변 분석 포함)의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
