이 글은 주로 Redis 면접 질문과 분산 클러스터를 소개합니다. 이제 여러분과 공유합니다. 도움이 필요한 친구들이 참고할 수 있습니다.

Redis 인터뷰 질문 및 분산 클러스터

1.

(1) HashMap과 마찬가지로 데이터가 메모리에 저장되므로 빠릅니다. HashMap의 장점은 검색 및 연산의 시간 복잡도가 O(1)
(2) 풍부한 데이터 유형을 지원하고, 문자열을 지원합니다. list, set , sorted set, hash
(3) 트랜잭션 지원, 작업은 모두 원자성입니다. 소위 원자성은 데이터에 대한 모든 변경 사항이 실행되거나 전혀 실행되지 않음을 의미합니다.
(4) 풍부한 기능: 사용할 수 있습니다. 캐싱, 메시징, 누르기 키의 만료 시간을 설정하면 만료 후 자동으로 삭제됩니다

특별 추천: 2020 redis 인터뷰 질문(최신)

2. 멤캐시드?

(1) memcached의 모든 값은 간단한 문자열입니다. Redis는 더 풍부한 데이터 유형을 지원합니다.
(2) redis는 memcached보다 훨씬 빠릅니다.
(3) redis는 데이터를 유지할 수 있습니다.

3. 문제 및 해결 방법:

(1) 마스터는 RDB 메모리 스냅샷 및 AOF 로그 파일과 같은 지속성 작업을 수행하지 않는 것이 가장 좋습니다.
(2) 데이터가 중요한 경우 슬레이브는 AOF 백업을 활성화해야 합니다. 데이터 및 정책은 다음으로 설정됩니다. 초당 한 번 동기화
(3) 마스터-슬레이브 복제 속도와 연결 안정성을 위해 마스터와 슬레이브가 동일한 LAN에 있는 것이 가장 좋습니다.
(4) 상위에 추가 데이터를 추가하지 마십시오. 스트레스 마스터 데이터베이스 슬레이브 라이브러리
(5) 마스터-슬레이브 복제에 그래프 구조를 사용하지 마십시오. 즉, Master 이러한 구조는 단일 실패 지점 문제를 쉽게 해결하여 마스터를 슬레이브로 대체할 수 있습니다. 마스터가 전화를 끊으면 즉시 Slave1을 마스터로 활성화하고 다른 모든 것은 변경하지 않을 수 있습니다.

4. MySQL에는 2천만 개의 데이터가 있지만 Redis에는 20만 개의 데이터만 저장됩니다. Redis의 데이터가 핫 데이터인지 확인하는 방법

관련 지식: Redis 메모리 데이터 세트의 크기가 특정 수준으로 증가하는 경우 크기, 데이터 제거 전략이 구현됩니다. Redis는 6가지 데이터 제거 전략을 제공합니다.

voltile-lru: 만료 시간이 설정된 데이터 세트(server.db[i].expires)에서 가장 최근에 사용된 데이터를 선택하여 제거합니다.

휘발성-ttl: 만료 날짜 설정 시간 데이터 세트(server.db[i].expires)에서 만료될 데이터를 선택하고 제거합니다

휘발성-random: 만료 시간이 설정된 데이터 세트(server.db[i].expires)에서 제거할 데이터를 무작위로 선택합니다.

allkeys-lru: 데이터 세트(server.db[i)에서 가장 최근 데이터를 선택합니다. ].dict) 가장 적게 사용되는 데이터를 제거합니다

allkeys-random: 제거를 위해 데이터 세트(server.db[i].dict)에서 데이터를 선택합니다

no-enviction(eviction): 데이터를 제거하는 것이 금지됩니다

5. Memcache와 Redis의 차이점은 무엇인가요?

1) 저장 방법

Memecache는 모든 데이터를 메모리에 저장합니다. 정전 후에는 데이터가 메모리 크기를 초과할 수 없습니다.

Redis는 데이터 지속성을 보장하기 위해 부분적으로 하드 디스크에 저장됩니다.

2), 데이터 지원 유형

Memcache의 데이터 유형 지원은 비교적 간단합니다.

Redis에는 복잡한 데이터 유형이 있습니다.

3) 사용되는 기본 모델이 다릅니다.

클라이언트와의 통신을 위한 기본 구현 방법과 애플리케이션 프로토콜이 다릅니다.

Redis는 VM 메커니즘을 자체적으로 직접 구축합니다. 일반 시스템이 시스템 기능을 호출하면 이동 및 요청에 일정 시간이 낭비되기 때문입니다.

4), 값 크기

Redis는 최대 1GB에 도달할 수 있지만 memcache는 1MB에 불과합니다

6. Redis의 일반적인 성능 문제는 무엇입니까? 어떻게 해결하나요?

1) 마스터는 메모리 스냅샷을 작성하고 save 명령은 메인 스레드의 작업을 차단하는 rdbSave 함수를 예약합니다. 스냅샷이 상대적으로 크면 성능에 미치는 영향이 매우 크기 때문에 서비스가 일시 중지됩니다. 간헐적으로 발생하므로 마스터가 메모리 스냅샷을 작성하지 않는 것이 가장 좋습니다.

2) 마스터 AOF 지속성. AOF 파일을 다시 작성하지 않으면 이 지속성 방법은 성능에 가장 작은 영향을 미치지만 AOF 파일이 계속 커지면 마스터 재시작의 복구 속도에 영향을 미칩니다. 메모리 스냅샷 및 AOF 로그 파일을 포함하여 마스터에서 지속성 작업을 수행하지 않는 것이 가장 좋습니다. 특히 데이터가 중요한 경우 슬레이브는 AOF 백업 데이터를 활성화해야 하며 전략은 다음과 같습니다. 초당 한 번 동기화합니다.

3).Master는 AOF 파일을 다시 작성하기 위해 BGREWRITEAOF를 호출합니다. AOF는 다시 작성하는 동안 많은 양의 CPU 및 메모리 리소스를 차지하므로 과도한 서비스 로드가 발생하고 단기 서비스가 중단됩니다.

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

7, 가장 적합한 시나리오입니다. for redis

Redis는 모든 사용자에게 가장 적합합니다. 메모리 내 데이터 시나리오에서 Redis는 지속성 기능도 제공하지만 실제로는 전통적인 의미의 지속성과는 상당히 다른 디스크 기반 기능에 가깝습니다. 궁금한 점이 있을 수 있습니다. Redis는 Memcached의 향상된 버전에 더 가까운 것 같으니 언제 Memcached를 사용해야 하고 언제 Redis를 사용해야 할까요?
Redis와 Memcached의 차이점을 간단히 비교해 보면 대부분의 사람들은 다음과 같은 의견을 갖게 될 것입니다. Redis는 단순한 k/v 유형의 데이터를 지원할 뿐만 아니라 list, set, zset, hash 등과 같은 데이터 구조의 저장도 제공합니다.
2. Redis는 데이터 백업, 즉 마스터-슬레이브 모드의 데이터 백업을 지원합니다.
3. Redis는 데이터를 디스크의 메모리에 보관하고 다시 시작할 때 다시 로드할 수 있는 데이터 지속성을 지원합니다.
(1), 세션 캐시

Redis 사용에 가장 일반적으로 사용되는 시나리오 중 하나는 세션 캐시입니다. Redis를 사용하여 다른 스토리지(예: Memcached)보다 세션을 캐시할 때의 이점은 Redis가 지속성을 제공한다는 것입니다. 엄격하게 일관성을 요구하지 않는 캐시를 유지 관리할 때 대부분의 사람들은 사용자의 장바구니 정보가 모두 손실되면 불만을 품게 됩니다. 그래도 여전히 그럴까요?

다행히 Redis가 수년에 걸쳐 개선됨에 따라 Redis를 올바르게 사용하여 세션 문서를 캐시하는 방법을 쉽게 알아낼 수 있습니다. 잘 알려진 상용 플랫폼인 Magento도 Redis 플러그인을 제공합니다.

(2), 전체 페이지 캐시(FPC)

Redis는 기본 세션 토큰 외에도 매우 간단한 FPC 플랫폼도 제공합니다. 일관성 문제로 돌아가서, Redis 인스턴스가 다시 시작되더라도 사용자는 디스크 지속성으로 인해 페이지 로딩 속도가 떨어지는 것을 볼 수 없습니다. 이는 PHP 로컬 FPC와 유사하게 크게 개선되었습니다.

Magento를 다시 예로 들면, Magento는 Redis를 전체 페이지 캐시 백엔드로 사용할 수 있는 플러그인을 제공합니다.

또한 WordPress 사용자를 위해 Pantheon에는 검색한 페이지를 최대한 빨리 로드하는 데 도움이 되는 매우 유용한 플러그인 wp-redis가 있습니다.

(3), Queue

메모리 저장 엔진 분야에서 Redis의 가장 큰 장점 중 하나는 Redis를 좋은 메시지 대기열 플랫폼으로 사용할 수 있도록 하는 목록 및 집합 작업을 제공한다는 것입니다. Redis가 대기열로 사용하는 작업은 로컬 프로그래밍 언어(예: Python)에서 목록의 푸시/팝 작업과 유사합니다.

Google에서 "Redis 대기열"을 빠르게 검색하면 수많은 오픈 소스 프로젝트를 즉시 찾을 수 있습니다. 이러한 프로젝트의 목적은 Redis를 사용하여 다양한 대기열 요구 사항을 충족하는 매우 좋은 백엔드 도구를 만드는 것입니다. 예를 들어 Celery에는 Redis를 브로커로 사용하는 백엔드가 있습니다. 여기에서 볼 수 있습니다.

(4), Leaderboard/Counter

Redis는 메모리에서 숫자를 늘리거나 줄이는 작업을 매우 잘 구현합니다. 세트와 정렬 세트도 이러한 작업을 수행하는 것을 매우 간단하게 해줍니다. Redis는 이 두 가지 데이터 구조를 제공합니다. 따라서 우리는 정렬된 세트에서 상위 10명의 사용자를 가져오고 싶습니다. 이를 "user_scores"라고 부르겠습니다. 다음과 같이 하면 됩니다.

물론 이것은 사용자 점수를 기준으로 정렬되었다고 가정합니다. 오름차순. 사용자와 사용자의 점수를 반환하려면 다음과 같이 실행해야 합니다.

ZRANGE user_scores 0 10 WITHSCORES

Agora Games는 Ruby로 구현된 좋은 예이며 순위는 Redis를 사용하여 데이터를 저장합니다. 여기에서 볼 수 있습니다.

(5), Publish/Subscribe

마지막(그러나 가장 중요한 것은) Redis의 게시/구독 기능입니다. 게시/구독에는 실제로 많은 사용 사례가 있습니다. 사람들이 이를 소셜 네트워크 연결에서 게시/구독 기반 스크립트의 트리거로 사용하고 심지어 Redis의 게시/구독 기능을 사용하여 채팅 시스템을 구축하는 것을 보았습니다! (아니요, 사실입니다. 확인하실 수 있습니다.)

Redis가 제공하는 모든 기능 중에서 사용자에게 다양한 기능을 제공하지만 가장 마음에 들지 않는 기능이라고 생각합니다.

고가용성 분산 클러스터

첫째, 고가용성

고가용성(High Availability)은 서버가 서비스를 중단하더라도 비즈니스와 사용자에게 아무런 영향을 미치지 않는다는 의미입니다. 서비스 중단 사유는 네트워크 카드, 라우터, 전산실, CPU 과부하, 메모리 오버플로, 천재지변 등 예측할 수 없는 사유가 있을 수 있으며, 많은 경우 단일점 문제라고도 합니다.

(1) 단일 지점 문제를 해결하는 두 가지 주요 방법은 다음과 같습니다.

활성 및 백업 방법
일반적으로 하나의 호스트와 하나 이상의 백업 시스템입니다. 일반적인 상황에서 호스트는 외부 세계에 서비스를 제공하고 데이터를 동기화합니다. . 대기 머신의 경우 메인 머신이 다운되면 대기 머신이 즉시 서비스를 시작합니다.
Keepalived는 Redis HA에서 일반적으로 사용되며, 이를 통해 호스트와 백업 머신은 동일한 가상 IP를 외부에 제공할 수 있습니다. 클라이언트는 평상시에는 가상 IP를 통해 데이터 작업을 수행합니다. 정전 후 VIP는 자동으로 백업 시스템으로 이동합니다.

클라이언트에게 아무런 영향을 주지 않고 여전히 VIP를 통해 운영된다는 장점이 있습니다.
단점도 분명합니다. 대부분의 경우 백업 머신을 사용하지 않고 낭비합니다.

마스터-슬레이브 방식
이 접근 방식은 하나의 마스터와 여러 개의 슬레이브를 채택하고 마스터와 슬레이브 간의 데이터를 동기화합니다. 마스터가 다운되면 선출 알고리즘(Paxos, Raft)을 통해 슬레이브에서 새로운 마스터를 선출하여 외부 세계에 계속 서비스를 제공하며, 마스터가 복구된 후 슬레이브로 다시 합류합니다.
마스터-슬레이브의 또 다른 목적은 읽기와 쓰기를 분리하는 것입니다. 이는 단일 기계의 읽기 및 쓰기 압력이 너무 높을 때 일반적인 솔루션입니다. 호스트 역할은 쓰기 작업이나 소량의 읽기만 제공하고, 로드 밸런싱 알고리즘을 통해 중복된 읽기 요청을 단일 또는 다중 슬레이브 서버로 오프로드합니다.

단점은 호스트가 다운된 후 슬레이브가 새로운 마스터로 선출되더라도 외부에 제공되는 IP 서비스 주소가 변경되어 클라이언트에 영향을 미친다는 점입니다. 이 상황을 해결하려면 몇 가지 추가 작업이 필요합니다. 호스트 주소가 변경되면 클라이언트는 새 주소를 받은 후 계속해서 새 주소를 사용하여 새 요청을 보냅니다.

(2) 데이터 동기화
마스터-슬레이브이든 마스터-슬레이브이든 데이터 동기화 문제와 관련됩니다. 이 역시 두 가지 상황으로 나뉩니다.

동기화 방법: 호스트가 클라이언트 쓰기 작업을 받으면 슬레이브 머신에 대한 데이터 동기화도 성공적으로 기록되면 마스터는 클라이언트에 성공을 반환합니다. 이를 강력한 데이터 일관성이라고도 합니다. 분명히 이 방법의 성능은 많이 저하될 것입니다. 마스터가 특정 슬레이브 머신을 동기화한 후에는 슬레이브 머신이 다른 슬레이브에 데이터 배포를 동기화합니다. 따라서 호스트 시스템의 성능 공유가 향상됩니다. 이 구성은 하나의 마스터와 하나의 슬레이브로 동시에 지원되며, 이 슬레이브는 다른 슬레이브의 마스터 역할을 합니다.

비동기 모드: 쓰기 작업을 받은 후 호스트는 직접 성공을 반환한 다음 비동기 방식으로 백그라운드에서 데이터를 슬레이브에 동기화합니다. 이러한 종류의 동기화 성능은 더 좋지만 데이터 무결성을 보장할 수 없습니다. 예를 들어 비동기 동기화 프로세스 중에 호스트가 갑자기 충돌하는 경우 이 방법을 약한 데이터 일관성이라고도 합니다.

Redis 마스터-슬레이브 동기화는 비동기 방식을 사용하므로 소량의 데이터가 손실될 위험이 있습니다. 최종 일관성이라는 약한 일관성의 특별한 경우도 있습니다. 자세한 내용은 CAP 원칙 및 일관성 모델을 참조하세요.

(3) 솔루션 선택
keepalived 솔루션은 구성이 간단하고 인건비가 저렴하며 데이터 양이 적고 부담이 적을 때 권장됩니다. 데이터 양이 상대적으로 크고 시스템을 너무 많이 낭비하고 싶지 않으며 가동 중지 시간 이후 알람, 로깅, 데이터 마이그레이션 등과 같은 일부 맞춤형 조치를 취하고 싶다면 사용하는 것이 좋습니다. 마스터-슬레이브 방식은 마스터-슬레이브 방식과 일치하기 때문에 일반적으로 관리 및 모니터링 센터도 있습니다.

다운타임 알림은 클라이언트 구성 요소에 통합되거나 별도로 추출될 수 있습니다. Redis 공식 Sentinel은 자동 장애 조치, 알림 등을 지원합니다. 자세한 내용은 저비용 및 고가용성 솔루션 설계(4)를 참조하세요.

논리도 :
Redis 인터뷰 질문 및 분산 클러스터

2. 분산형

분산형(distributed)이란 업무 규모와 데이터량이 증가할 때 임의로 서버 수를 늘리거나 줄여 문제를 해결할 수 있다는 의미입니다.

클러스터 시대
최소 2개의 Redis 서버를 배포하여 소규모 클러스터를 형성합니다. 이 클러스터의 주요 목적은 두 가지입니다.

고가용성: 호스트가 중단된 후 자동 장애 조치를 수행하여 프런트엔드 서비스가 사용자에게 영향을 주지 않습니다.
읽기 및 쓰기 분리: 읽기 압력을 호스트에서 슬레이브로 오프로드합니다.
클라이언트 구성 요소에서 로드 밸런싱을 달성할 수 있으며, 다양한 서버의 작동 조건에 따라 다양한 비율의 읽기 요청 압력을 공유할 수 있습니다.

논리도:
Redis 인터뷰 질문 및 분산 클러스터

세, 분산형 클러스터 시대

캐시된 데이터의 양이 계속 증가하면 단일 머신의 메모리가 부족해지고 데이터를 여러 부분으로 나누어 여러 곳에 분산시켜야 합니다. 서버.
클라이언트에서 데이터가 조각화될 수 있습니다. 데이터 조각화 알고리즘에 대한 자세한 내용은 C# 일관된 해시 세부 설명 및 C# 가상 버킷 조각화를 참조하세요.

논리도:
Redis 인터뷰 질문 및 분산 클러스터

대규모 분산 클러스터 시대
데이터 양이 계속해서 증가하면 애플리케이션은 다양한 시나리오의 비즈니스를 기반으로 해당 분산 클러스터를 신청할 수 있습니다. 그중 가장 중요한 부분은 캐시 관리이며, 가장 중요한 부분은 프록시 서비스 추가입니다. 애플리케이션은 읽기 및 쓰기용 프록시를 통해 실제 Redis 서버에 액세스합니다. 이것의 이점은 다음과 같습니다.

관리하기 어렵고 위험을 초래하는 Redis 서버에 직접 액세스하는 클라이언트가 점점 더 많아지는 것을 방지합니다.
현재 제한, 인증, 샤딩 등 해당 보안 조치를 프록시 계층에서 구현할 수 있습니다.
클라이언트 측에서 더 많은 논리 코드를 피하세요. 이는 비대할 뿐만 아니라 업그레이드도 번거롭습니다.
프록시 레이어는 상태 비저장이며 클라이언트의 경우 노드를 임의로 확장할 수 있습니다. 프록시에 액세스하는 것은 독립형 Redis에 액세스하는 것과 같습니다.
현재 호스트 회사는 클라이언트 구성 요소와 프록시라는 두 가지 솔루션을 사용합니다. 프록시를 사용하면 특정 성능에 영향을 미치기 때문입니다. 프록시 구현을 위한 해당 솔루션에는 Twitter의 Twemproxy 및 Wandoujia의 codis가 포함됩니다.

논리 다이어그램:
Redis 인터뷰 질문 및 분산 클러스터