2023년 최신 버전 Redis 면접 질문 68개(모음)

글이 너무 길어요. 먼저 저장하고 천천히 읽어보시는 걸 추천드려요!

Redis(원격 사전 서버)는 C 언어로 작성된 오픈 소스(BSD 라이선스) 고성능 비관계형(NoSQL) 키-값 데이터베이스입니다.

Redis는 키와 다섯 가지 유형의 값 사이의 매핑을 저장할 수 있습니다. 키 유형은 문자열만 가능하며 문자열, 목록, 집합, 해시 테이블, 순서 집합의 5가지 데이터 유형만 지원됩니다.

기존 데이터베이스와 달리 Redis 데이터는 메모리에 저장되므로 읽기 및 쓰기 속도가 매우 빠릅니다. 따라서 Redis는 캐시 방향으로 널리 사용되며 초당 100,000회 이상의 읽기 및 쓰기 작업을 처리할 수 있습니다. 알려진 성능 가장 빠른 Key-Value DB. 또한 Redis는 분산 잠금에도 자주 사용됩니다. 또한 Redis는 트랜잭션, 지속성, LUA 스크립트, LRU 기반 이벤트 및 다양한 클러스터 솔루션을 지원합니다.

오늘은 퇴근 후 면접 준비를 위한

Redis 면접 질문에 대해 이야기해보겠습니다.

1. 개요

1. Redis의 장점과 단점은 무엇입니까

장점

Redis는 110,000회/초의 속도로 읽고 쓸 수 있습니다. 회/초.

데이터 지속성을 지원하고 AOF와 RDB의 두 가지 지속성 방법을 지원합니다.

트랜잭션을 지원합니다. 동시에 Redis는 여러 작업을 병합한 후 원자 실행도 지원합니다.

풍부한 데이터 구조는 문자열 유형 값을 지원하는 것 외에도 hash, set, zset, list 및 기타 데이터 구조도 지원합니다.

마스터-슬레이브 복제를 지원하며 호스트는 자동으로 데이터를 슬레이브에 동기화하고 읽기 및 쓰기 분리를 수행할 수 있습니다.

단점

데이터베이스 용량은 물리적 메모리에 의해 제한되며 대용량 데이터의 고성능 읽기 및 쓰기에 사용할 수 없습니다. 따라서 Redis에 적합한 시나리오는 주로 고성능 작업 및 적은 양의 계산으로 제한됩니다. 데이터.

Redis에는 자동 내결함성 및 복구 기능이 없습니다. 호스트 및 슬레이브 머신의 가동 중지 시간으로 인해 일부 프런트엔드 읽기 및 쓰기 요청이 실패할 수 있습니다. 머신이 다시 시작될 때까지 기다리거나 프런트엔드를 수동으로 전환해야 합니다. 복구할 IP입니다.

호스트가 다운되었습니다. IP 전환 후 일부 데이터를 슬레이브에 동기화할 수 없어 시스템 가용성이 저하됩니다.

Redis는 온라인 확장을 지원하기 어렵습니다. 클러스터 용량이 상한에 도달하면 온라인 확장이 매우 복잡해집니다. 이 문제를 방지하려면 운영 및 유지 관리 담당자는 시스템이 온라인 상태가 될 때 충분한 공간이 있는지 확인해야 하며 이는 막대한 자원 낭비를 초래합니다.

2. Redis를 사용하는 이유/캐시를 사용하는 이유

우리는 이 문제를 주로 "고성능"과 "높은 동시성"이라는 두 가지 측면에서 살펴봅니다.

고성능:

사용자가 처음으로 데이터베이스의 일부 데이터에 액세스한다고 가정합니다. 이 프로세스는 하드 디스크에서 읽기 때문에 속도가 느려집니다. 사용자가 접근한 데이터를 캐시에 저장하여 다음에 데이터에 접근할 때 캐시에서 직접 가져올 수 있도록 합니다.

연산캐시(Operation Cache)는 메모리를 직접 연산하는 것이기 때문에 속도가 상당히 빠릅니다. 데이터베이스의 해당 데이터가 변경되면 캐시의 해당 데이터를 동기적으로 변경하면 됩니다!

높은 동시성:

캐시를 직접 조작하여 허용할 수 있는 요청이 데이터베이스에 직접 액세스하는 요청보다 훨씬 많기 때문에 데이터베이스의 일부 데이터를 캐시로 전송하는 것을 고려할 수 있습니다. 사용자 요청의 일부는 데이터베이스를 거치지 않고 캐시로 직접 이동합니다.

3. 캐싱에 map/guava 대신 Redis를 사용하는 이유는 무엇입니까?

캐시는 로컬 캐시와 분산 캐시로 구분됩니다. Java를 예로 들면, 내장된 맵이나 구아바를 사용하여 로컬 캐싱을 구현합니다. 주요 기능은 jvm이 소멸되는 것으로 수명 주기가 끝나며, 여러 인스턴스의 경우 각 인스턴스가 캐시됩니다. 저장해야 하는데 캐시가 일관성이 없습니다.

redis 또는 memcached를 사용하는 것을 분산 캐시라고 합니다. 여러 인스턴스의 경우 각 인스턴스는 데이터 캐시를 공유하며 캐시는 일관성이 있습니다. 단점은 redis 또는 memcached 서비스의 가용성을 높게 유지해야 하며 전체 프로그램 아키텍처가 상대적으로 복잡하다는 것입니다.

4. Redis가 왜 그렇게 빠른가요?

1) 완전히 메모리를 기반으로 합니다. 대부분의 요청은 매우 빠른 순수 메모리 작업입니다. HashMap과 마찬가지로 데이터가 메모리에 저장되는 장점은 검색 및 연산의 시간 복잡도가 O(1)이라는 것입니다.

2) 데이터 구조가 간단하고 데이터 구조도 간단합니다. Redis에서는 특별히 설계되었습니다.

3) 단일 스레드를 사용하면 불필요한 컨텍스트 전환 및 CPU를 소비하는 스레드로 인한 전환이 없습니다. 잠금 및 해제 작업이 없습니다.

4) 다중 채널 I/O 다중화 모델, 비차단 IO 사용

5 기본 모델이 다르며, 기본 모델과 클라이언트와의 관계가 다릅니다. 통신 애플리케이션 프로토콜은 다릅니다. Redis는 자체 VM 메커니즘을 직접 구축합니다. 왜냐하면 일반 시스템이 시스템 기능을 호출하면 이동 및 요청에 일정 시간이 낭비되기 때문입니다.

2. 데이터 유형

Redis에는 주로 String, List, Set, Zset, Hash 등 5가지 데이터 유형이 있으며 대부분의 사용 요구 사항을 충족합니다

6. Redis 애플리케이션 시나리오

요약 1

Counter

: 문자열에 대해 증가 및 감소 연산을 수행하여 카운터 기능을 실현할 수 있습니다. 인메모리 데이터베이스인 Redis는 읽기 및 쓰기 성능이 매우 높으며 자주 읽고 쓰는 횟수를 저장하는 데 매우 적합합니다.

Cache

: 핫스팟 데이터를 메모리에 넣고 최대 메모리 사용량 및 제거 전략을 설정하여 캐시 적중률을 보장합니다.

세션 캐시

: Redis는 여러 애플리케이션 서버의 세션 정보를 균일하게 저장하는 데 사용할 수 있습니다. 애플리케이션 서버가 더 이상 사용자의 세션 정보를 저장하지 않으면 더 이상 상태가 없으므로 사용자는 애플리케이션 서버를 요청할 수 있으므로 고가용성과 확장성을 더 쉽게 얻을 수 있습니다.

전체 페이지 캐시(FPC)

: Redis는 기본 세션 토큰 외에도 매우 간단한 FPC 플랫폼도 제공합니다. Magento를 예로 들면, Magento는 Redis를 전체 페이지 캐시 백엔드로 사용할 수 있는 플러그인을 제공합니다. 또한 WordPress 사용자를 위해 Pantheon에는 매우 유용한 플러그인 wp-redis가 있어 탐색한 페이지를 최대한 빨리 로드하는 데 도움이 됩니다.

조회 테이블

: 예를 들어 DNS 레코드는 Redis를 사용한 저장에 적합합니다. 조회 테이블은 캐시와 유사하며 Redis의 빠른 조회 기능도 활용합니다. 그러나 캐시는 신뢰할 수 있는 데이터 소스 역할을 하지 않기 때문에 조회 테이블의 내용은 무효화될 수 없지만 캐시의 내용은 무효화될 수 있습니다.

메시지 큐(게시/구독 기능):

List는 lpush 및 rpop을 통해 메시지를 쓰고 읽을 수 있는 이중 연결 목록입니다. 그러나 Kafka 및 RabbitMQ와 같은 메시징 미들웨어를 사용하는 것이 가장 좋습니다.

분산 잠금 구현:

분산 시나리오에서는 독립 실행형 환경의 잠금을 사용하여 여러 노드의 프로세스를 동기화할 수 없습니다. Redis와 함께 제공되는 SETNX 명령을 사용하여 분산 잠금을 구현할 수도 있습니다. 또한 공식적으로 제공되는 RedLock 분산 잠금 구현을 사용할 수도 있습니다.

기타:

Set은 교차점, 합집합 등의 연산을 구현하여 상호 친구와 같은 기능을 실현할 수 있습니다. ZSet은 순위 지정과 같은 기능을 달성하기 위해 순서가 지정된 작업을 구현할 수 있습니다.

요약 2

다른 캐시에 비해 Redis는 매우 큰 장점이 있습니다. 즉, 다양한 데이터 유형을 지원한다는 것입니다.

데이터 유형 설명 문자열 문자열, 가장 간단한 k-v 저장소 해시 해시 형식, 값은 필드 및 값이며 ID-세부 사항과 같은 시나리오에 적합합니다. 리스트는 단순 리스트, 순차 리스트, 세트의 첫 번째 또는 끝에 데이터 삽입 지원, 순서가 지정되지 않은 리스트, 빠른 검색 속도, 교차, 합집합 및 차이 세트 처리에 적합 정렬된 세트 순서 세트

실제로는 위 데이터 유형의 특성에 따라 기본적으로 적합한 응용 시나리오를 생각할 수 있습니다.

string - Memcached 저장소 구조, SMS 확인 코드, 구성 정보 등과 유사한 가장 간단한 k-v 저장소에 적합하며 이 유형을 사용하여 저장합니다.

hash

——일반적으로 키는 ID 또는 고유 식별자이며 값은 세부 사항에 해당합니다. 상품상세정보, 개인정보상세정보, 뉴스상세정보 등

list

——목록은 순서가 지정되어 있기 때문에 순서가 있고 상대적으로 고정된 일부 데이터를 저장하는 데 더 적합합니다. 지방 및 도시 테이블, 사전 테이블 등 목록이 정렬되어 있기 때문에 최신 ***, 메시지 큐 등 작성 시간에 따라 정렬하는 것이 적합합니다.

set

——Weibo에 어떤 친구가 있는지 간단히 알 수 있는 ID-List 모델로 이해할 수 있습니다. 집합의 가장 좋은 점은 두 집합에 대한 교집합, 합집합, 차이 연산을 제공할 수 있다는 것입니다. 예: 두 사람 사이의 공통 친구 찾기 등.

Sorted Set

- 점수 매개변수를 추가하여 점수 값에 따라 자동으로 정렬되는 향상된 버전의 세트입니다. 삽입 시간에 따라 정렬되지 않은 상위 ​​10개 등의 데이터에 더 적합합니다.

위에서 언급했듯이 Redis는 관계형 데이터베이스만큼 데이터 구조가 복잡하지는 않지만 일반적인 캐시 데이터 구조 이상을 포함하여 많은 시나리오에 적합할 수도 있습니다. 각 데이터 구조에 적합한 비즈니스 시나리오를 이해하면 개발 효율성 향상에 도움이 될 뿐만 아니라 Redis의 성능을 효과적으로 활용하는 데 도움이 됩니다.

3. 지속성

7. Redis 지속성이란?

지속성은 서비스가 다운될 때 메모리 데이터가 손실되는 것을 방지하기 위해 메모리 데이터를 디스크에 쓰는 것입니다.

8. 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: 지속성

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보다 좋습니다

둘 다 구성하면 AOF가 먼저 로드됩니다

9 적절한 지속성 방법을 선택하는 방법

일반적으로 원하는 경우 PostgreSQL에 필적하는 데이터 보안을 위해서는 두 가지 지속성 기능을 모두 사용해야 합니다. 이 경우 Redis가 다시 시작되면 원본 데이터를 복원하기 위해 AOF 파일이 먼저 로드됩니다. 왜냐하면 정상적인 상황에서는 AOF 파일에 의해 저장된 데이터 세트가 RDB 파일에 의해 저장된 데이터 세트보다 더 완전하기 때문입니다.

데이터에 많은 관심이 있지만 몇 분 안에 데이터 손실을 감당할 수 있다면 RDB 지속성을 사용하면 됩니다.

많은 사용자가 AOF 지속성만 사용하지만 RDB 스냅샷을 정기적으로 생성하는 것이 데이터베이스 백업에 매우 편리하고 RDB가 AOF보다 빠르게 데이터 세트를 복원하므로 이 방법은 권장되지 않습니다. 또한 RDB를 사용하면 AOF 프로그램의 버그도 피할 수 있습니다.

서버가 실행될 때만 데이터가 존재하도록 하려면 지속성 방법을 사용할 수도 없습니다.

10. Redis 영구 데이터 및 캐시를 확장하는 방법은 무엇입니까?

Redis를 캐시로 사용하는 경우 일관된 해싱을 사용하여 동적 확장 및 축소를 달성합니다.

Redis를 영구 저장소로 사용하는 경우 고정된 키-노드 매핑 관계를 사용해야 하며, 한 번 결정된 노드 수는 변경할 수 없습니다. 그렇지 않은 경우(즉, Redis 노드를 동적으로 변경해야 하는 경우) 런타임 시 데이터 균형을 재조정할 수 있는 시스템을 사용해야 하며 현재는 Redis 클러스터에서만 이를 수행할 수 있습니다.

4. 메모리 관련

14. MySQL에는 2천만 개의 데이터가 있지만 Redis에는 20만 개의 데이터만 저장되어 있습니다.

Redis 메모리 데이터 세트의 크기가 특정 크기로 증가하면 데이터 제거 전략이 구현됩니다.

15. Redis의 메모리 제거 전략은 무엇입니까?

Redis의 메모리 제거 전략은 Redis의 캐싱을 위한 메모리가 부족할 때 새로 작성해야 하는 데이터를 처리하는 방법을 말하며 추가 공간 적용이 필요합니다.

전역 키 공간 선택적 제거

noeviction: 메모리가 새로 작성된 데이터를 수용하기에 충분하지 않으면 새 쓰기 작업에서 오류를 보고합니다.

allkeys-lru: 새로 작성된 데이터를 수용할 만큼 메모리가 충분하지 않은 경우 키 공간에서 가장 최근에 사용한 키를 제거합니다. (가장 일반적으로 사용되는 방법입니다)

allkeys-random: 메모리가 새로 작성된 데이터를 수용하기에 충분하지 않으면 키 공간에서 키가 무작위로 제거됩니다.

만료 시간이 설정된 키 공간의 선택적 제거

휘발성-lru: 새로 작성된 데이터를 수용할 만큼 메모리가 부족한 경우 만료 시간이 설정된 키 공간에서 가장 최근에 사용된 키를 제거합니다.

휘발성-random: 새로 작성된 데이터를 수용할 만큼 메모리가 충분하지 않으면 만료 시간이 설정된 키 공간에서 키가 무작위로 제거됩니다.

휘발성-ttl: 새로 작성된 데이터를 수용할 만큼 메모리가 충분하지 않은 경우 만료 시간이 설정된 키 공간에서 만료 시간이 더 빠른 키가 먼저 제거됩니다.

요약

Redis의 메모리 제거 전략 선택은 만료된 키 처리에 영향을 미치지 않습니다. 메모리 제거 정책은 메모리가 부족할 때 추가 공간이 필요한 데이터를 처리하는 데 사용되며 만료 정책은 만료된 캐시 데이터를 처리하는 데 사용됩니다.

16. Redis는 주로 어떤 물리적 리소스를 소비하나요?

메모리.

17. Redis의 메모리가 부족하면 어떻게 되나요?

설정된 상한에 도달하면 Redis 쓰기 명령은 오류 메시지를 반환합니다(그러나 읽기 명령은 여전히 ​​정상적으로 반환될 수 있습니다). 또는 메모리 제거 메커니즘을 구성할 수 있으며 Redis가 메모리 상한에 도달하면 오래된 콘텐츠는 플러시됩니다.

18. Redis는 어떻게 메모리를 최적화하나요?

일반적으로 작은 Key-Value를 여러 개 더 간결하게 함께 저장할 수 있기 때문에 Hash, list, sorted set, set 등과 같은 컬렉션 유형 데이터를 효과적으로 활용할 수 있습니다. 가능한 한 해시를 사용하십시오. 해시 테이블(해시 테이블에 저장되는 숫자가 작다는 의미)은 매우 작은 메모리를 사용하므로 데이터 모델을 최대한 해시 테이블로 추상화해야 합니다. 예를 들어 웹 시스템에 사용자 개체가 있는 경우 사용자의 이름, 성, 이메일 및 비밀번호에 대해 별도의 키를 설정하지 말고 모든 사용자 정보를 해시 테이블에 저장하세요.

5. 스레딩 모델

19. Redis 스레딩 모델

Redis는 Reactor 모델을 기반으로 네트워크 이벤트 프로세서를 개발했습니다. 그 구조는 다중 소켓, IO 멀티플렉서, 파일 이벤트 디스패처 및 이벤트 프로세서의 4개 부분으로 구성됩니다. 파일 이벤트 디스패처 큐의 소비는 단일 스레드이므로 Redis는 단일 스레드 모델이라고 합니다.

파일 이벤트 핸들러는 I/O 멀티플렉싱(멀티플렉싱) 프로그램을 사용하여 동시에 여러 소켓을 수신하고, 현재 소켓에서 수행되는 작업에 따라 다양한 이벤트 핸들러를 소켓과 연결합니다.

모니터링된 소켓이 연결 응답(수락), 읽기(읽기), 쓰기(쓰기), 닫기(닫기) 등의 작업을 수행할 준비가 되면 해당 작업에 해당하는 파일 이벤트가 생성됩니다. 그러면 파일 이벤트 핸들러는 이전에 소켓과 연결된 이벤트 핸들러를 호출하여 이러한 이벤트를 처리합니다.

파일 이벤트 핸들러는 단일 스레드 방식으로 실행되지만 I/O 멀티플렉서를 사용하여 여러 소켓을 수신함으로써 파일 이벤트 핸들러는 고성능 네트워크 통신 모델과 좋은 기능을 모두 구현합니다. 단일 스레드 방식으로 실행되는 Redis 서버의 다른 모듈은 Redis 내에서 단일 스레드 디자인의 단순성을 유지합니다.

6. 스레딩 모델

19. Redis 스레딩 모델

Redis는 Reactor 모델을 기반으로 네트워크 이벤트 프로세서를 개발했습니다. 그 구조는 다중 소켓, IO 멀티플렉서, 파일 이벤트 디스패처 및 이벤트 프로세서의 4개 부분으로 구성됩니다. 파일 이벤트 디스패처 큐의 소비는 단일 스레드이므로 Redis는 단일 스레드 모델이라고 합니다.

파일 이벤트 핸들러는 I/O 멀티플렉싱 프로그램을 사용하여 동시에 여러 소켓을 수신하고 현재 소켓에서 수행되는 작업을 기반으로 다양한 이벤트 핸들러를 소켓과 연결합니다.

모니터링된 소켓이 연결 응답(수락), 읽기(읽기), 쓰기(쓰기), 닫기(닫기) 등의 작업을 수행할 준비가 되면 해당 작업에 해당하는 파일 이벤트가 생성됩니다. 그러면 파일 이벤트 핸들러는 이전에 소켓과 연결된 이벤트 핸들러를 호출하여 이러한 이벤트를 처리합니다.

파일 이벤트 핸들러는 단일 스레드 방식으로 실행되지만 I/O 멀티플렉서를 사용하여 여러 소켓을 수신함으로써 파일 이벤트 핸들러는 고성능 네트워크 통신 모델과 좋은 기능을 모두 구현합니다. 단일 스레드 방식으로 실행되는 Redis 서버의 다른 모듈은 Redis 내에서 단일 스레드 디자인의 단순성을 유지합니다.

7. 불륜

20. 불륜이란?

트랜잭션은 단일 격리된 작업입니다. 트랜잭션의 모든 명령은 직렬화되어 순서대로 실행됩니다. 트랜잭션이 실행되는 동안 다른 클라이언트가 보낸 명령 요청으로 인해 중단되지 않습니다.

트랜잭션은 원자성 작업입니다. 즉, 트랜잭션의 모든 명령이 실행되거나 그 중 아무 것도 실행되지 않습니다.

21. Redis 트랜잭션의 개념

Redis 트랜잭션의 핵심은 MULTI, EXEC, WATCH 등의 명령어 모음입니다. 트랜잭션은 한 번에 여러 명령 실행을 지원하며 트랜잭션의 모든 명령은 직렬화됩니다. 트랜잭션 실행 프로세스 중에 대기열의 명령은 직렬화되어 순서대로 실행되며 다른 클라이언트가 제출한 명령 요청은 트랜잭션 실행 명령 시퀀스에 삽입되지 않습니다.

요약하자면: Redis 트랜잭션은 대기열에 있는 일련의 명령을 일회성, 순차적, 배타적으로 실행하는 것입니다.

22. Redis Transactionsactaction의 3 단계 Redis Transaction

Transaction은 다중 명령 enqueue 연합 실행 실행 실행 실행 실행 실행을 시작합니다. MULTI가 대기열에 추가됩니다.

23. Redis 트랜잭션 관련 명령

Redis 트랜잭션 기능은 MULTI, EXEC, DISCARD, WATCH의 네 가지 기본 요소를 통해 구현됩니다.

Redis는 트랜잭션의 모든 명령을 직렬화한 다음 순서대로 실행합니다.

1)

redis는 롤백을 지원하지 않습니다. "Redis는 트랜잭션이 실패해도 롤백하지 않고 나머지 명령을 계속 실행합니다." 따라서 Redis의 내부는 간단하고 빠르게 유지될 수 있습니다.

2)

트랜잭션의 명령에 오류가 발생하면 모든 명령이 실행되지 않습니다.

.3)

트랜잭션에서 실행 오류가 발생하면 올바른 명령이 실행됩니다.

WATCH 명령은 Redis 트랜잭션에 대한 확인 및 설정(CAS) 동작을 제공하는 낙관적 잠금입니다. 하나 이상의 키를 모니터링할 수 있습니다. 키 중 하나가 수정(또는 삭제)되면 후속 트랜잭션은 실행되지 않으며 EXEC 명령이 실행될 때까지 모니터링이 계속됩니다.

MULTI 명령은 트랜잭션을 시작하는 데 사용되며 항상 OK를 반환합니다. MULTI가 실행된 후 클라이언트는 원하는 만큼의 명령을 서버에 계속 보낼 수 있습니다. 이러한 명령은 즉시 실행되지 않지만 EXEC 명령이 호출되면 대기열에 있는 모든 명령이 실행됩니다. .

EXEC: 모든 트랜잭션 블록 내에서 명령을 실행합니다. 명령 실행 순서대로 정렬되어 트랜잭션 블록 내의 모든 명령의 반환 값을 반환합니다. 작업이 중단되면 빈 값 nil이 반환됩니다.

DISCARD를 호출하면 클라이언트는 트랜잭션 대기열을 지우고 트랜잭션 실행을 포기할 수 있으며 클라이언트는 트랜잭션 상태에서 종료됩니다.

UNWATCH 명령은 시계의 모든 키 모니터링을 취소할 수 있습니다.

24. 트랜잭션 관리(ACID) 개요

원자성:

원자성은 트랜잭션이 분할할 수 없는 작업 단위이며 트랜잭션의 작업이 모두 발생하거나 발생하지 않음을 의미합니다.

일관성:

거래 전후의 데이터 무결성은 일관되게 유지되어야 합니다.

격리:

여러 트랜잭션이 동시에 실행되는 경우 한 트랜잭션의 실행이 다른 트랜잭션의 실행에 영향을 주어서는 안 됩니다.

내구성:

지속성은 트랜잭션이 커밋되면 데이터베이스의 데이터 변경 사항이 영구적이며 데이터베이스에 오류가 발생하더라도 아무런 영향을 미치지 않아야 함을 의미합니다.

Redis 트랜잭션은 항상 일관성을 유지하며 ACID 격리,

다른 기능은 지원되지 않습니다. 서버가 AOF 지속성 모드에서 실행 중이고appendfsync 옵션의 값이 항상인 경우에도 트랜잭션은 내구성이 있습니다.

25. Redis 트랜잭션은 격리를 지원하나요?

Redis는 단일 프로세스 프로그램이며 트랜잭션 실행 시 트랜잭션이 중단되지 않음을 보장합니다. 트랜잭션 대기열의 모든 명령이 실행될 때까지 트랜잭션이 실행될 수 있습니다. 따라서 Redis 트랜잭션은 항상 격리됩니다.

26. Redis 트랜잭션은 원자성을 보장하고 롤백을 지원합니까?

Redis에서는 단일 명령이 원자적으로 실행되지만 트랜잭션은 원자성이 보장되지 않으며 롤백도 없습니다. 트랜잭션의 명령 중 하나라도 실행이 실패하더라도 나머지 명령은 계속 실행됩니다.

27. Redis 트랜잭션의 기타 구현

Lua 스크립트를 기반으로 Redis는 스크립트의 명령이 한 번에 순서대로 실행되도록 보장할 수 있으며 일부 명령이 실행되는 경우 트랜잭션 실행 오류를 롤백하지 않습니다. 실행 오류 동안 나머지 명령은 완료될 때까지 계속 실행됩니다.

중간 mark 변수를 기반으로 또 다른 mark 변수를 사용하여 트랜잭션 완료 여부를 식별합니다. 데이터를 읽을 때 먼저 mark 변수를 읽어 트랜잭션이 완료되었는지 확인합니다. 완료되었습니다. 그러나 이를 위해서는 추가 코드를 구현해야 하므로 더욱 번거롭습니다.

8. 클러스터 솔루션

28. Sentinel 모드

sentinel 소개:

sentinel, 중국어 이름은 sentinel입니다. Sentinel은 Redis 클러스터 조직에서 매우 중요한 구성 요소로 주로 다음과 같은 기능을 가지고 있습니다.

Cluster Monitoring

: Redis 마스터 및 슬레이브 프로세스가 정상적으로 작동하는지 모니터링하는 역할을 담당합니다.

메시지 알림: Redis 인스턴스가 실패하면 Sentinel은 관리자에게 경보 알림 메시지를 보낼 책임이 있습니다.

Failover

: 마스터 노드가 정지되면 자동으로 슬레이브 노드로 전송됩니다.

구성 센터: 장애 조치가 발생하면 클라이언트에 새 마스터 주소를 알립니다.

Sentinel은 Redis 클러스터의 고가용성을 달성하는 데 사용됩니다. 또한 분산되어 있으며 Sentinel 클러스터로 실행되며 서로 작동합니다.

장애 조치 중에 마스터 노드가 다운되었는지 확인하려면 대부분의 센티널의 동의가 필요하며 이는 분산 선택 문제와 관련됩니다.

일부 센티넬 노드가 죽더라도 센티넬 클러스터는 정상적으로 작동할 수 있습니다. 왜냐하면 고가용성 메커니즘의 중요한 부분인 장애 조치 시스템이 단일 지점이라면 매우 혼란스러울 것이기 때문입니다.

Sentinel의 핵심 지식

Sentinel의 견고성을 보장하려면 최소 3개의 인스턴스가 필요합니다.

Sentinel + redis 마스터-슬레이브 배포 아키텍처는 데이터 손실 제로를 보장하지 않지만 Redis 클러스터의 고가용성만 보장할 수 있습니다.

Sentinel + redis 마스터-슬레이브의 복잡한 배포 아키텍처의 경우 테스트 환경과 프로덕션 환경 모두에서 충분한 테스트와 훈련을 수행해 보십시오.

29. 공식 Redis 클러스터 솔루션(서버 측 라우팅 쿼리)

Redis 클러스터 모드의 작동 원리를 설명할 수 있나요? 클러스터 모드에서 redis의 키는 어떻게 처리됩니까? 분산 주소 지정 알고리즘은 무엇입니까? 일관된 해시 알고리즘을 알고 있나요?

소개

Redis Cluster는 서버 측 샤딩 기술로, 버전 3.0에서 공식적으로 사용 가능합니다. Redis 클러스터는 일관된 해싱을 사용하지 않고 총 16384개의 슬롯으로 나누어지는 슬롯 개념을 사용합니다. 임의의 노드에 요청을 보내면, 요청을 받은 노드는 실행을 위해 올바른 노드에 쿼리 요청을 보냅니다

프로젝트 설명

데이터는 해싱으로 조각화되며 각 노드는 일정량의 해시를 균등하게 저장합니다. .해시 슬롯(해시 값) 간격의 데이터에는 기본적으로 16384개의 슬롯이 할당됩니다.

각 데이터 샤드는 서로 마스터이자 슬레이브인 여러 노드에 저장됩니다.

데이터는 마스터 노드에 먼저 기록된 후 동기화됩니다. 슬레이브 노드 (동기화 차단 구성 지원)

동일 샤드에 있는 여러 노드 사이에서 데이터의 일관성이 유지되지 않음

데이터를 읽을 때 클라이언트가 조작하는 키가 노드에 할당되지 않은 경우 redis는 리디렉션으로 돌아갑니다. 올바른 노드를 가리키는 명령

확장 중에 이전 노드의 데이터 일부를 새 노드로 마이그레이션해야 합니다

redis 클러스터 아키텍처에서 각 redis는 6379와 같은 두 개의 포트 번호를 열어야 합니다. , 다른 하나는 16379와 같은 1w 포트 번호를 추가하는 것입니다.

16379 포트 번호는 노드 간 통신, 즉 클러스터 버스 통신에 사용되며 오류 감지, 구성 업데이트 및 장애 조치 권한 부여에 사용됩니다. 클러스터 버스는 노드 간 효율적인 데이터 교환을 위해 또 다른 바이너리 프로토콜인 가십 프로토콜을 사용하여 네트워크 대역폭과 처리 시간을 덜 차지합니다.

노드 간 내부 통신 메커니즘

(기본 ​​통신 원리) 클러스터 메타데이터를 유지하는 방법에는 중앙 집중식 프로토콜과 가십 프로토콜의 두 가지가 있습니다. 가십 프로토콜은 Redis 클러스터 노드 간 통신에 사용됩니다.

분산 주소 지정 알고리즘

해시 알고리즘(대량 캐시 재구성)

일관된 해시 알고리즘(자동 캐시 마이그레이션) + 가상 노드(자동 로드 밸런싱)

redis 클러스터의 해시 슬롯 알고리즘

장점

Centerless 동적 확장을 지원하며 비즈니스에 투명합니다

Sentinel 모니터링 및 자동 장애 조치 기능이 있습니다

클라이언트는 클러스터의 모든 노드에 연결할 필요가 없으며 클러스터의 사용 가능한 노드에 연결하기만 하면 됩니다

높음 성능, 클라이언트가 Redis 서비스에 직접 연결되어 프록시 에이전트 손실이 없습니다

단점

운영 및 유지 관리도 매우 복잡하며 데이터 마이그레이션에는 수동 개입이 필요합니다

0번 데이터베이스만 사용할 수 있습니다

배치 작업을 지원하지 않습니다(파이프라인 파이프라인 작업)

분산 로직 및 스토리지 모듈 결합 등

30. 클라이언트 기반 할당

소개

Redis 샤딩은 다중 Redis 인스턴스입니다. Redis Cluster가 나오기 전에 업계에서 일반적으로 사용되었던 클러스터링 방법입니다. 주요 아이디어는 해시 알고리즘을 사용하여 Redis 데이터의 키를 해시하는 것입니다. 해시 함수를 통해 특정 키가 특정 Redis 노드에 매핑됩니다. Java Redis 클라이언트는 jedis를 구동하고 Redis Sharding 기능, 즉 캐시 풀과 결합된 ShardedJedis 및 ShardedJedisPool을 지원합니다

장점

이점은 서버의 Redis 인스턴스가 각각 독립적이라는 것입니다. 각 Redis 인스턴스는 단일 서버와 동일하게 실행되며 선형 확장이 매우 쉽습니다. 단점: 샤딩 처리가 클라이언트에 배치되므로 추가 확장이 가능합니다. 규모가 커지면 운영 및 유지 관리에 어려움이 따릅니다.

클라이언트 측 샤딩은 노드의 동적 추가 및 삭제를 지원하지 않습니다. 서버의 Redis 인스턴스 그룹의 토폴로지가 변경되면 각 클라이언트를 업데이트하고 조정해야 합니다. 연결을 공유할 수 없습니다. 애플리케이션 규모가 커지면 리소스 낭비로 인해 최적화가 제한됩니다

31. 프록시 서버 샤딩 기준

소개

클라이언트가 프록시 구성 요소에 요청을 보내고, 프록시는 클라이언트의 데이터를 구문 분석하고, 요청을 올바른 노드로 전달하고, 마지막으로 클라이언트에 결과를 응답합니다

Features

투명 access, 비즈니스 프로그램은 백엔드 Redis 인스턴스에 신경 쓸 필요가 없으며 전환 비용도 낮습니다

프록시 로직과 스토리지 로직이 격리되어 있습니다

프록시 레이어에 전달이 하나 더 있어 성능이 저하됩니다

업계 오픈 소스 솔루션

Twtter는 오픈 소스 Twemproxy

Wandoujia 오픈 소스 Codis

32, Redis 마스터-슬레이브 아키텍처

독립형 Redis는 수만에서 수만 범위의 QPS를 전달할 수 있습니다. 캐시의 경우 일반적으로 높은 읽기 동시성을 지원하는 데 사용됩니다. 따라서 아키텍처는 하나의 마스터와 여러 개의 슬레이브로 구성된 마스터-슬레이브 아키텍처로 이루어집니다. 마스터는 다른 슬레이브 노드에 데이터를 쓰고 복사하는 역할을 담당하고, 슬레이브 노드는 읽는 역할을 담당합니다. 모든 읽기 요청은 슬레이브 노드로 이동합니다. 이는 또한 쉽게 수평 확장을 달성하고 높은 읽기 동시성을 지원할 수 있습니다.

redis 복제 -> 마스터-슬레이브 아키텍처 -> 읽기 및 쓰기 분리 -> 수평 확장은 높은 읽기 동시성을 지원합니다.

Redis 복제의 핵심 메커니즘

redis는 비동기 모드를 사용합니다. 그러나 redis2.8부터 슬레이브 노드는 매번 복사되는 데이터의 양을 주기적으로 확인합니다.

마스터 노드는 여러 슬레이브 노드로 구성될 수 있습니다.

슬레이브 노드는 다른 슬레이브에도 연결할 수 있습니다. 노드;

슬레이브 노드가 복제될 때 마스터 노드의 정상적인 작업을 차단하지 않습니다. 슬레이브 노드가 복제할 때 자체 쿼리 작업을 차단하지 않으며 이전 데이터 세트를 사용하여 서비스를 제공합니다. 하지만 복제가 완료되면 이전 데이터 세트를 삭제하고 새 데이터 세트를 로드해야 하는 경우가 있습니다. 이 때 외부 서비스가 중단됩니다.

슬레이브 노드는 주로 읽기와 쓰기의 분리에 사용됩니다. 확장된 슬레이브 노드는 읽기 처리량을 향상시킬 수 있습니다.

마스터-슬레이브 아키텍처를 채택하는 경우 마스터 노드의 지속성을 켜야 하는 것이 좋습니다. 슬레이브 노드를 마스터 노드의 데이터 핫 백업으로 사용하는 것은 권장되지 않습니다. 이 경우 마스터의 지속성을 끄면 마스터 노드가 손상될 수 있으며, 머신이 충돌하고 다시 시작하면 데이터가 비어 있으며, 복제된 후 슬레이브 노드의 데이터가 손실될 수 있습니다.

이 외에도 마스터를 위한 다양한 백업 계획도 이루어져야 합니다. 로컬 파일이 모두 손실된 경우 백업에서 RDB를 선택하여 마스터를 복원하면 시작 시 데이터가 유지됩니다. 나중에 설명하는 고가용성 메커니즘이 채택되더라도 슬레이브 노드가 자동으로 마스터를 인수할 수 있습니다. .노드이지만 Sentinel이 마스터 장애를 감지하기 전에 마스터 노드가 자동으로 다시 시작되거나 위의 모든 슬레이브 노드 데이터가 지워질 수도 있습니다.

redis 마스터-슬레이브 복제의 핵심 원칙

슬레이브 노드가 시작되면 PSYNC 명령을 마스터 노드로 보냅니다.

슬레이브 노드가 마스터 노드에 처음 연결되는 경우 전체 재동기화 전체 복사가 트리거됩니다. 이때 마스터는 백그라운드 스레드를 시작하고 RDB 스냅샷 파일 생성을 시작합니다.

동시에 클라이언트 클라이언트로부터 새로 수신된 모든 쓰기 명령은 메모리에 캐시됩니다. RDB 파일이 생성된 후 마스터는 RDB를 슬레이브에 보냅니다. 슬레이브는 먼저 RDB를 로컬 디스크에 쓴 다음 로컬 디스크에서 메모리로 로드합니다.

그러면 마스터는 메모리에 캐시된 쓰기 명령을 슬레이브에 보내고 슬레이브도 데이터를 동기화합니다.

슬레이브 노드와 마스터 노드 사이에 네트워크 장애가 발생하여 연결이 끊어지면 자동으로 다시 연결됩니다. 연결 후 마스터 노드는 누락된 데이터만 슬레이브에 복사합니다.

프로세스 원리

슬레이브 라이브러리와 메인 라이브러리가 MS 관계를 맺으면 SYNC 명령이 메인 데이터베이스로 전송됩니다.

SYNC 명령을 받은 후 메인 라이브러리가 저장을 시작합니다. 백그라운드에서 스냅샷을 생성하고(RDB 지속성 프로세스) 해당 기간 동안 받은 쓰기 명령을 캐시합니다스냅샷이 완료되면 마스터 Redis는 스냅샷 파일과 캐시된 모든 쓰기 명령을 슬레이브 Redis에게 보냅니다

Redis는 스냅샷 파일을 로드하고 컬렉션을 실행합니다. 캐시된 명령

을 받은 후 마스터 Redis는 쓰기 명령을 받을 때마다 슬레이브 Redis에 명령을 보내 데이터 일관성을 보장합니다

단점

모두 슬레이브 노드 데이터 복제 및 동기화는 마스터 노드 처리에 의해 수행되므로 마스터 노드에 너무 많은 부담이 발생합니다. 마스터-슬레이브 구조를 사용하여 문제를 해결하세요

33. Redis 클러스터의?

일부 노드가 실패하거나 대부분의 노드가 통신할 수 없는 경우에도 클러스터를 계속 사용할 수 있도록 클러스터는 마스터-슬레이브 복제 모델을 사용하며 각 노드에는 N-1 복제본이 있습니다

34. Redis가 배포되었나요?

redis 클러스터, 10개 머신은 Redis 마스터 인스턴스로 배포되고 나머지 5개 머신은 Redis 슬레이브 인스턴스로 배포되며, 5개 노드는 외부 읽기 및 쓰기 서비스를 제공합니다. 읽기 및 쓰기 qps는 초당 50,000회에 도달할 수 있으며, 5대 머신의 최대 수는 초당 읽기 및 쓰기 요청 250,000회입니다.

기계 구성은 어떻게 되나요? 32G 메모리 + 8코어 CPU + 1T 디스크인데, Redis 프로세스에 할당되는 메모리는 10g입니다. 일반적인 온라인 프로덕션 환경에서는 Redis의 메모리가 10g을 초과하면 문제가 발생할 수 있습니다.

5대의 머신은 총 50g의 메모리로 외부 읽기 및 쓰기 기능을 제공합니다.

각 마스터 인스턴스에는 슬레이브 인스턴스가 있으므로 가용성이 높습니다. 마스터 인스턴스가 다운되면 자동으로 장애 조치가 수행되고 Redis 슬레이브 인스턴스는 자동으로 마스터 인스턴스가 되어 읽기 및 쓰기 서비스를 계속 제공합니다.

메모리에 어떤 데이터를 쓰고 있나요? 각 데이터 조각의 크기는 얼마입니까? 제품 데이터, 각 데이터는 10kb입니다. 데이터 100개가 1MB이고, 데이터 100,000개가 1g입니다. 메모리에는 200만 개의 제품 데이터가 상주하고 있으며, 점유된 메모리는 20g으로 전체 메모리의 50%에도 미치지 못합니다. 현재 피크 기간은 초당 약 3,500건의 요청입니다.

실제로 대기업에는 캐시 클러스터의 운영 및 유지 관리를 담당하는 인프라 팀이 있습니다.

35. Redis 해시 슬롯의 개념에 대해 이야기해 주세요.

Redis 클러스터는 일관된 해싱을 사용하지 않지만 해시 슬롯 개념을 도입합니다. Redis 클러스터에는 16384개의 해시 슬롯이 있습니다. 각 키가 CRC16 검사를 통과한 후 모듈로 16384를 사용하여 배치할 슬롯을 결정합니다. 해시 슬롯의 일부에 대해.

36. Redis 클러스터에서 쓰기 작업이 손실되나요? 왜?

Redis는 데이터의 강력한 일관성을 보장하지 않습니다. 즉, 실제로 특정 조건에서는 클러스터의 쓰기 작업이 손실될 수 있습니다.

37. Redis 클러스터는 어떻게 복제되나요?

비동기 복제

38. Redis 클러스터의 최대 노드 수는 몇 개입니까?

16384

39. Redis 클러스터용 데이터베이스를 선택하는 방법은 무엇입니까?

Redis 클러스터는 현재 데이터베이스를 선택할 수 없으며 기본값은 데이터베이스 0입니다.

9. 파티션

40. Redis는 멀티 코어 CPU의 활용도를 높이는 방법은 무엇입니까?

동일한 서버에 Redis의 여러 인스턴스를 배포하고 이를 다른 서버로 사용할 수 있으며, 어쨌든 서버 하나로는 충분하지 않으므로 여러 CPU를 사용하려는 경우 샤딩을 고려할 수 있습니다.

41. Redis를 분할해야 하는 이유는 무엇입니까?

파티션을 사용하면 Redis가 더 큰 메모리를 관리할 수 있으며 Redis는 모든 시스템의 메모리를 사용할 수 있습니다. 파티션이 없으면 최대 한 대의 머신 메모리만 사용할 수 있습니다. 파티셔닝을 사용하면 단순히 컴퓨터를 추가하는 것만으로도 Redis의 컴퓨팅 성능을 두 배로 늘릴 수 있으며, 컴퓨터와 네트워크 카드를 추가하면 Redis의 네트워크 대역폭도 기하급수적으로 증가합니다.

42. 어떤 Redis 파티션 구현 솔루션을 사용할 수 있는지 아시나요?

클라이언트 측 파티셔닝은 클라이언트가 데이터를 저장하거나 읽을 Redis 노드를 이미 결정했음을 의미합니다. 대부분의 클라이언트는 이미 클라이언트측 파티셔닝을 구현하고 있습니다.

프록시 파티셔닝은 클라이언트가 프록시에 요청을 보낸 다음 프록시가 데이터를 쓰거나 읽을 노드를 결정한다는 의미입니다. 에이전트는 파티션 규칙에 따라 요청할 Redis 인스턴스를 결정한 다음 Redis 응답 결과에 따라 이를 클라이언트에 반환합니다. Redis 및 memcached의 프록시 구현은 Twemproxy

Query 라우팅입니다. 즉, 클라이언트가 임의의 Redis 인스턴스를 무작위로 요청한 다음 Redis가 요청을 올바른 Redis 노드로 전달합니다. Redis 클러스터는 하이브리드 형태의 쿼리 라우팅을 구현하지만 한 Redis 노드에서 다른 Redis 노드로 요청을 직접 전달하는 대신 클라이언트의 도움을 받아 올바른 Redis 노드로 직접 리디렉션합니다.

43. Redis 파티션의 단점은 무엇인가요?

여러 키를 사용하는 작업은 일반적으로 지원되지 않습니다. 예를 들어 두 컬렉션은 서로 다른 Redis 인스턴스에 저장될 수 있으므로 교차할 수 없습니다(실제로 이러한 상황에 대한 방법이 있지만 Intersection 명령을 직접 사용할 수는 없습니다).

여러 키를 동시에 조작하는 경우 Redis 트랜잭션을 사용할 수 없습니다. 파티셔닝 세분성이 핵심이므로 매우 큰 정렬 세트처럼 하나의 거대한 키로 데이터 세트를 샤딩하는 것은 불가능합니다.)

사용 시 파티셔닝을 수행하면 데이터 처리가 매우 복잡해집니다. 예를 들어 백업의 경우 여러 Redis 인스턴스와 호스트에서 동시에 RDB/AOF 파일을 수집해야 합니다.

파티셔닝 시 동적 확장 또는 축소는 매우 복잡할 수 있습니다. Redis 클러스터는 런타임에 Redis 노드를 추가하거나 삭제하여 사용자에게 최대한 투명한 데이터 재조정을 달성할 수 있습니다. 그러나 일부 다른 클라이언트 분할 또는 프록시 분할 방법은 이 기능을 지원하지 않습니다. 하지만 이 문제를 더 잘 해결할 수 있는 사전 샤딩 기술도 있습니다.

10. 분산 문제

44. Redis는 분산 잠금을 구현합니다.

Redis는 단일 프로세스 단일 스레드 모드를 사용하여 동시 액세스를 직렬 액세스로 전환하며 Redis에 대한 여러 클라이언트의 연결은 다음과 같습니다. not 경쟁 관계가 있는 경우 SETNX 명령을 사용하여 Redis에서 분산 잠금을 구현할 수 있습니다.

키가 존재하지 않는 경우에만 키 값을 value로 설정하세요. 지정된 키가 이미 존재하는 경우 SETNX는 아무 작업도 수행하지 않습니다.

SETNX는 "SET if Not eXists"(존재하지 않으면 SET)의 약어입니다.

반환 값: 성공적으로 설정되면 1을 반환합니다. 설치가 실패하고 0을 반환합니다.

SETNX를 사용하여 동기화 잠금을 완료하는 과정과 사항은 다음과 같습니다.

SETNX 명령을 사용하여 잠금을 획득합니다. 0이 반환되면(키가 이미 존재, 잠금이 이미 존재함) 획득합니다. 그렇지 않으면 획득이 성공합니다.

잠금을 획득한 후 프로그램에서 예외가 발생하여 SETNX 명령을 호출하고 교착 상태에 들어갈 때 다른 스레드/프로세스가 항상 0을 반환하는 것을 방지하려면 키에 대해 "합리적인" 만료 시간을 설정해야 합니다.

잠금을 해제하고 DEL 명령을 사용하여 잠금 데이터를 삭제하세요.

45. Key in Redis의 동시 경쟁 문제를 해결하는 방법

소위 Key in Redis의 동시 경쟁 문제는 여러 시스템이 동시에 하나의 키에 대해 작동하지만 최종 실행 순서는 다음과 같습니다. 우리가 기대하는 순서와 다릅니다. 이것은 또한 다른 결과로 이어집니다!

해결책 추천: 분산 잠금(Zookeeper와 Redis 모두 분산 잠금을 구현할 수 있음). (Redis에서 Key에 대한 동시 경쟁이 없는 경우 분산 잠금을 사용하지 마십시오. 성능에 영향을 미칠 수 있습니다.)

주키퍼의 임시 주문 노드를 기반으로 하는 분산 잠금입니다. 일반적인 아이디어는 각 클라이언트가 특정 메소드를 잠그면 Zookeeper의 메소드에 해당하는 지정된 노드의 디렉토리에 고유한 순간 순서 노드가 생성된다는 것입니다. 잠금 획득 여부를 결정하는 방법은 매우 간단합니다. 순서가 지정된 노드 중 가장 작은 시퀀스 번호만 결정하면 됩니다. 잠금이 해제되면 임시 노드를 삭제하면 됩니다. 동시에 서비스 가동 중지 시간으로 인해 해제할 수 없는 잠금으로 인해 발생하는 교착 상태 문제를 방지할 수 있습니다. 비즈니스 프로세스 완료 후 해당 하위 노드를 삭제하여 잠금을 해제합니다.

실습에서는 당연히 신뢰성이 최우선입니다. 따라서 Zookeeper를 먼저 권장합니다.

46. 배포된 Redis는 초기 단계에 수행해야 합니까, 아니면 규모가 커지는 후기 단계에 수행해야 합니까? 왜?

Redis는 매우 가볍기 때문에(단일 인스턴스는 1M 메모리만 사용) 향후 확장을 방지하는 가장 좋은 방법은 처음에 더 많은 인스턴스를 시작하는 것입니다. 서버가 하나만 있는 경우에도 파티션을 사용하여 동일한 서버에서 여러 인스턴스를 시작하여 Redis를 처음부터 분산 방식으로 실행할 수 있습니다.

처음에 Redis 인스턴스를 32개 또는 64개 등 몇 개 더 설정합니다. 이는 대부분의 사용자에게 번거로울 수 있지만 장기적으로는 희생할 가치가 있습니다.

이 경우 데이터가 계속해서 증가하고 더 많은 Redis 서버가 필요할 때 해야 할 일은 Redis 인스턴스를 한 서비스에서 다른 서버로 마이그레이션하기만 하면 됩니다(재파티셔닝 문제를 고려하지 않음). 다른 서버를 추가한 후에는 Redis 인스턴스의 절반을 첫 번째 머신에서 두 번째 머신으로 마이그레이션해야 합니다.

47. RedLock이란

Redlock이라는 Redis 기반 분산 잠금을 구현하는 권위 있는 방법을 제안했습니다. 이 방법은 원래의 단일 노드 방법보다 안전합니다. 다음 기능을 보장할 수 있습니다.

안전 기능: 상호 배타적 액세스, 즉 단 하나의 클라이언트만 항상 잠금을 얻을 수 있습니다.

교착 상태 방지: 결국 모든 클라이언트가 잠금을 얻을 수 있으며, 원래 리소스를 잠근 클라이언트가 충돌하거나 네트워크 파티션이 발생하더라도

내결함: 대부분의 Redis 노드가 살아남는 한 서비스는 정상적으로 제공될 수 있습니다

11. 캐시 사태

캐시 사태는 동시에 대규모 캐시 장애를 의미합니다. 따라서 후속 요청이 데이터베이스에 떨어지게 되어 데이터베이스가 짧은 시간 내에 많은 요청을 견디고 붕괴됩니다. .

해결책:

캐시된 데이터의 만료 시간을 무작위로 설정하여 많은 수의 데이터가 동시에 만료되는 것을 방지하세요.

일반적으로 동시성 양이 특별히 크지 않은 경우 가장 일반적으로 사용되는 솔루션은 잠금 및 대기열입니다.

캐시된 각 데이터에 해당 캐시 태그를 추가하고 캐시가 유효하지 않은지 기록합니다. 캐시 태그가 유효하지 않은 경우 데이터 캐시를 업데이트하세요.

49. 캐시 침투

캐시 침투는 캐시에도 없고 데이터베이스에도 없는 데이터를 말하며, 이로 인해 모든 요청이 데이터베이스에 떨어지게 되어 데이터베이스가 짧은 시간 내에 많은 수의 요청을 견딜 수 있게 됩니다. 시간과 붕괴.

해결책:

사용자 인증 확인, 기본 ID 확인, ID

캐시에서 검색할 수 없는 데이터도 데이터베이스가 검색되지 않으면 키-값 쌍을 key-null로 쓸 수도 있습니다. 캐시 유효 시간은 30초와 같이 더 짧게 설정할 수 있습니다(너무 길게 설정하면 정상적인 상황에서 사용할 수 없게 됩니다). 이렇게 하면 공격하는 사용자가 동일한 ID를 반복적으로 사용하여 무차별 대입 공격을 하는 것을 방지할 수 있습니다.

블룸 필터를 사용하여 가능한 모든 데이터를 충분히 큰 비트맵으로 해시하면 존재하지 않아야 하는 데이터가 이 비트맵에 의해 차단되므로 쿼리 압력이 방지됩니다. 기본 스토리지 시스템

추가:

공간 활용의 궁극은 비트맵과 블룸필터입니다.

Bitmap: 일반적으로 해시 테이블입니다

Bitmap은 각 요소에 대해 1비트의 정보만 기록할 수 있다는 것이 단점입니다. 추가 기능을 완성하려면 더 많은 공간을 희생해야만 할 수 있습니다. 그리고 시간.

Bloom 필터(권장)

는 k(k>1)k(k>1) 독립적인 해시 함수를 도입하여 요소가 주어진 공간 내에서 완성되도록 하고 오판율을 판단하는 과정입니다.

일반적인 알고리즘에 비해 공간 효율성과 쿼리 시간이 훨씬 높다는 장점이 있고, 오인식률이 일정하고 삭제가 어렵다는 단점이 있습니다.

블룸 필터 알고리즘의 핵심 아이디어는 여러 가지 해시 함수를 사용하여 "충돌"을 해결하는 것입니다.

해시에는 충돌(충돌) 문제가 있으며, 동일한 해시를 사용하여 얻은 두 URL의 값이 동일할 수 있습니다. 충돌을 줄이기 위해 해시를 여러 개 더 도입할 수 있습니다. 해시 값 중 하나를 통해 요소가 집합에 없다고 결론을 내리면 해당 요소는 확실히 집합에 없습니다. 모든 해시 함수가 해당 요소가 집합에 있음을 알려주는 경우에만 해당 요소가 집합에 존재하는지 확인할 수 있습니다. 이것이 Bloom-Filter의 기본 아이디어입니다.

Bloom-Filter는 일반적으로 대규모 데이터 컬렉션에 요소가 존재하는지 확인하는 데 사용됩니다.

50. 캐시 분석

캐시 분석은 캐시에는 없지만 데이터베이스에 있는 데이터를 말합니다(보통 캐시 시간이 만료됨). 동시 읽기 캐시는 데이터를 읽지 않는 동시에 데이터베이스로 이동하여 데이터를 검색하므로 데이터베이스에 대한 압력이 순간적으로 증가하여 과도한 압력이 발생합니다. Cache Avalanche는 Cache Avalanche와 달리 동일한 데이터의 동시 쿼리를 의미하며, Cache Avalanche는 다른 데이터가 만료되어 많은 데이터를 찾을 수 없어 데이터베이스를 검색하는 것을 의미합니다.

Solution

핫스팟 데이터가 만료되지 않도록 설정하세요.

Add mutex lock, mutex lock

51, 캐시 예열

캐시 예열은 시스템이 온라인 상태가 된 후 관련 캐시 데이터를 캐시 시스템에 직접 로드하는 것입니다. 이런 방식으로 먼저 데이터베이스를 쿼리한 다음 사용자가 요청할 때 데이터를 캐싱하는 문제를 피할 수 있습니다! 예열된 캐시 데이터를 사용자가 직접 쿼리!

해결책:

캐시 새로 고침 페이지를 직접 작성하고 온라인에 접속할 때 수동으로 수행하세요.

데이터 양이 많지 않으며 프로젝트가 시작될 때 자동으로 로드될 수 있습니다.

캐시를 정기적으로 새로 고치세요.

52, 캐시 저하

방문 횟수가 급격하게 증가하거나 서비스 문제(예: 응답 시간이 느리거나 응답이 없는 경우)가 발생하거나 비핵심 서비스가 핵심 프로세스의 성능에 영향을 미치는 경우에도 다음 사항을 확인해야 합니다. 서비스가 손상되더라도 서비스는 계속 사용할 수 있습니다. 시스템은 일부 주요 데이터를 기반으로 자동으로 다운그레이드하거나 스위치를 구성하여 수동으로 다운그레이드할 수 있습니다. ,

캐시 다운그레이드

의 궁극적인 목표는 손실이 발생하더라도 핵심 서비스를 사용할 수 있도록 보장하는 것입니다. 그리고 일부 서비스(장바구니에 추가, 결제 등)는 다운그레이드할 수 없습니다. 다운그레이드하기 전에 시스템이 병사를 잃고 지휘관을 유지할 수 있는지 확인하여 죽음까지 보호해야 할 것과 다운그레이드할 수 있는 것을 분류해야 합니다. 예를 들어 로그 수준을 참조할 수 있습니다. 계획 설정:

일반: 예를 들어 일부 서비스 때때로 네트워크 지터 또는 서비스가 온라인 상태이고 시간 초과로 인해 자동으로 다운그레이드될 수 있습니다.

경고

: 일부 서비스는 일정 기간 내에 성공률이 변동합니다. 95~100% 사이), 자동으로 다운그레이드되거나 수동으로 다운그레이드될 수 있으며 경고를 보냅니다.

Error

: 예를 들어 가용성 비율이 90% 미만이거나 데이터베이스 연결 풀이 소진되었습니다. 방문 횟수가 갑자기 시스템이 감당할 수 있는 최대치까지 증가합니다. 이때 상황에 따라 자동으로 다운그레이드되거나 수동으로 다운그레이드될 수 있습니다.

심각한 오류:

예를 들어 다음과 같은 이유로 데이터가 잘못된 경우. 특별한 이유가 있는 경우 긴급 수동 다운그레이드가 필요합니다. 서비스 다운그레이드의 목적은 Redis 서비스 오류로 인해 데이터베이스에 눈사태 문제가 발생하는 것을 방지하는 것입니다. 따라서 중요하지 않은 캐시 데이터의 경우 서비스 다운그레이드 전략을 채택할 수 있습니다. 예를 들어 Redis에 문제가 있으면 데이터베이스를 쿼리하는 대신 기본값을 사용자에게 직접 반환하는 것이 일반적인 접근 방식입니다.

53. 핫 데이터와 콜드 데이터

핫 데이터, 캐시는 소중합니다.

콜드 데이터의 경우 대부분의 데이터가 다시 액세스되기 전에 메모리에서 압착되었을 수 있으며, 이는 메모리를 차지할 뿐만 아니라 가치도 거의 없습니다. 자주 수정되는 데이터는 상황에 따라 캐시 활용을 고려해 보세요

저희 IM 제품 중 하나, 생일 인사말 모듈, 오늘의 생일 목록 등 핫 데이터의 경우 캐시를 수십만 번 읽을 수 있습니다. 또 다른 예로 내비게이션 제품에서는 내비게이션 정보를 캐시하고 향후 수백만 번 읽을 수도 있습니다.

캐시는 업데이트하기 전에 데이터를 두 번 이상 읽는 경우에만 의미가 있습니다. 이것이 가장 기본적인 전략입니다. 캐시가 적용되기 전에 실패하면 별 가치가 없습니다.

캐시가 존재하지 않고 수정 빈도가 매우 높지만 캐싱을 고려해야 하는 시나리오는 어떻습니까? 가지다! 예를 들어, 이 읽기 인터페이스는 데이터베이스에 많은 부담을 주지만 동시에 핫 데이터이기도 합니다. 이때 좋아요 수, 컬렉션 수 및 데이터베이스에 대한 부담을 줄이기 위한 캐싱 방법을 고려해야 합니다. 이는 매우 일반적인 핫 데이터이지만 계속 변경되므로 데이터베이스에 대한 부담을 줄이기 위해 데이터를 Redis 캐시에 동기식으로 저장해야 합니다.

54. 캐시 핫스팟 키

캐시 내 키(예: 프로모션 제품)는 특정 시점에 만료되며, 이 시점에서 이 키에 대한 동시 요청이 많습니다. 요청 발견 캐시가 만료되면 일반적으로 데이터가 백엔드 DB에서 로드되고 캐시로 재설정됩니다. 이때 대규모 동시 요청이 즉시 백엔드 DB를 압도할 수 있습니다.

해결책:

캐시 쿼리를 잠급니다. KEY가 없으면 잠근 다음 DB를 캐시로 확인한 다음 다른 프로세스에서 잠금을 발견하면 잠금을 해제하고 데이터를 반환합니다. 또는 DB 쿼리 잠금 해제 후 입력

공통 도구

55. Redis에서 지원하는 Java 클라이언트는 무엇인가요? 공식적으로 권장되는 것은 무엇입니까?

Redisson, Jedis, 양상추 등 공식적인 권장 사항은 Redisson을 사용하는 것입니다.

56. 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).

57. 제디스와 레디슨의 장점과 단점은 무엇인가요?

Jedis는 Redis에 의해 Java로 구현된 클라이언트입니다. Redisson은 Jedis에 비해 분산되고 확장 가능한 Java 데이터 구조를 구현하며 문자열 작업을 지원하지 않습니다. 정렬, 트랜잭션, 파이프라인, 파티션과 같은 Redis 기능을 지원하지 않습니다. Redisson의 목적은 Redis에서 사용자의 우려 사항을 분리하여 사용자가 비즈니스 로직 처리에 더 집중할 수 있도록 하는 것입니다

기타 문제

58 Redis와 Memcached의 차이점은

둘 다 비관계형 메모리입니다. 키-값 데이터베이스로 인해 이제 기업에서는 일반적으로 Redis를 사용하여 캐싱을 구현하고 있으며 Redis 자체도 점점 더 강력해지고 있습니다! Redis와 Memcached의 주요 차이점은 다음과 같습니다.

(1) memcached의 모든 값은 간단한 문자열이며, 이를 대체하는 redis는 더 풍부한 데이터 유형을 지원합니다.

(2) redis는 memcached보다 빠릅니다. 훨씬 빠릅니다

(3) Redis는 데이터를 유지할 수 있습니다

59. 캐시와 데이터베이스가 이중으로 기록될 때 데이터 일관성을 보장하는 방법은 무엇입니까?

캐시를 사용하는 한 캐시와 데이터베이스의 이중 저장 및 이중 쓰기가 발생할 수 있습니다. 그러면 데이터 일관성 문제가 발생합니다. 그러면 일관성 문제를 어떻게 해결합니까?

일반적으로 시스템에서 캐시 + 데이터베이스의 일관성을 엄격하게 요구하지 않는 경우 캐시가 데이터베이스와 약간 불일치할 수 있습니다. 이 솔루션을 사용하지 않는 것이 가장 좋습니다. 불일치가 없는지 확인하기 위해 메모리 큐에 저장합니다. 직렬화 후에는 시스템 처리량이 크게 줄어들고 정상적인 상황보다 몇 배 더 많은 시스템이 사용됩니다.

일시적인 불일치가 발생할 수 있지만 발생 확률이 매우 낮은 또 다른 방법은 데이터베이스를 먼저 업데이트한 후 캐시를 삭제하는 것입니다.

60. 일반적인 Redis 성능 문제 및 해결 방법은 무엇입니까?

마스터는 메모리 스냅샷 및 AOF 로그 파일을 포함한 지속성 작업을 수행하지 않는 것이 가장 좋습니다. 특히 지속성을 위해 메모리 스냅샷을 활성화하지 마세요.

데이터가 중요한 경우 슬레이브는 AOF 백업 데이터를 활성화하고 1초에 한 번씩 동기화하는 전략입니다.

마스터-슬레이브 복제 속도와 연결 안정성을 위해서는 슬레이브와 마스터가 동일한 LAN에 있는 것이 가장 좋습니다.

스트레스가 많은 메인 라이브러리에 슬레이브 라이브러리를 추가하지 마세요.

마스터는 AOF 파일을 다시 쓰기 위해 BGREWRITEAOF를 호출합니다. AOF는 다시 쓰는 동안 많은 양의 CPU와 메모리 리소스를 차지하므로 과도한 서비스 로드가 발생하고 짧은 서비스 중단 현상이 발생합니다.

마스터의 안정성을 위해 마스터-슬레이브 복제는 그래프 구조를 사용하지 않아야 합니다. 즉, 마스터-슬레이브 관계는 마스터

61. Redis는 왜 Windows 버전을 공식적으로 제공하지 않습니까?

현재 Linux 버전은 상당히 안정적이고 사용자 수가 많기 때문에 호환성 및 기타 문제가 발생할 수 있는 Windows 버전을 개발할 필요가 없습니다.

62. 문자열 유형 값이 저장할 수 있는 최대 용량은 얼마인가요?

512M

63. Redis는 어떻게 대용량 데이터를 삽입하나요?

Redis 2.6부터 redis-cli는 대량의 데이터 삽입 작업을 수행하기 위해 파이프 모드라는 새로운 모드를 지원합니다.

64. Redis에 1억 개의 키가 있고 그 중 100,000개가 고정된 알려진 접두사로 시작한다면 모두 찾으면 어떻게 될까요?

key 명령을 사용하여 지정된 패턴의 키 목록을 검색하세요.

그러자 상대방은 이렇게 물었습니다. 이 Redis가 온라인 비즈니스에 서비스를 제공하고 있다면, 키 명령을 사용할 때 어떤 문제가 있나요?

이제 Redis의 핵심 기능인 Redis의 단일 스레딩에 답해야 합니다. 키 명령으로 인해 스레드가 일정 기간 동안 차단되고 명령이 실행될 때까지 서비스를 복원할 수 없습니다. 이때, scan 명령을 사용하면 차단 없이 지정된 모드의 키 목록을 추출할 수 있지만, 클라이언트에서 한 번만 수행하면 어느 정도 중복될 가능성이 있지만, 전체 시간이 소요됩니다. 직접 사용하는 것보다 길어집니다.

65. Redis를 사용하여 비동기 대기열을 생성한 적이 있나요?

목록 유형을 사용하여 데이터 정보를 저장하고, rpush는 메시지를 생성하고, lpop은 메시지를 소비합니다. lpop에 메시지가 없으면 잠시 잠자다가 원하지 않는 경우 정보가 있는지 확인하면 됩니다. sleep, 정보가 없으면 blpop을 사용할 수 있습니다. 정보가 도착할 때까지 차단됩니다. Redis는 게시/구독 주제 구독 모델을 통해 하나의 생산자와 여러 소비자를 구현할 수 있습니다. 물론 소비자가 오프라인 상태가 되면 생성된 메시지가 손실됩니다.

66. Redis는 지연 대기열을 어떻게 구현합니까?

sortedset를 사용하고, 타임스탬프를 점수로 사용하고, 메시지 내용을 키로 사용하고, zadd를 호출하여 메시지를 생성하고, 소비자는 zrangbyscore를 사용하여 폴링 처리를 위해 n초 전의 데이터를 얻습니다.

67. Redis 재활용 프로세스는 어떻게 진행되나요?

클라이언트가 새 명령을 실행하고 새 데이터를 추가했습니다.

Redis는 메모리 사용량을 확인하여 maxmemory 한도를 초과하면 설정된 전략에 따라 재활용됩니다.

새로운 명령이 실행되는 등

그래서 우리는 끊임없이 경계에 도달한 다음 끊임없이 경계 아래로 다시 재활용함으로써 메모리 한계의 경계를 끊임없이 넘나들고 있습니다.

명령 결과로 인해 많은 양의 메모리가 사용되는 경우(예: 큰 세트의 교차점을 새 키에 저장) 이 메모리 사용량으로 인해 메모리 제한이 초과되는 데 오래 걸리지 않습니다. .

68. Redis 재활용에는 어떤 알고리즘이 사용되나요?

LRU 알고리즘.

알겠습니다. Redis 면접 질문을 공유합니다. 도움이 되셨다면 좋아요를 눌러 격려해주세요~

위 내용은 2023년 최신 버전 Redis 면접 질문 68개(모음)의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!