10년이 넘는 시간 동안 개발해온 제품을 생각해보면, 그 속에서 낡은 기술이 발견되는 것은 전혀 놀라운 일이 아닙니다. 하지만 XNUMX개월 안에 하중을 XNUMX배 더 높게 유지해야 하고, 추락으로 인한 비용이 수백 배 증가한다면 어떻게 될까요? 이 경우에는 멋진 하이로드 엔지니어가 필요합니다. 하지만 가정부가 없으면 문제 해결을 나에게 맡겼습니다. 기사의 첫 번째 부분에서는 Redis에서 Redis-cluster로 이동한 방법을 설명하고, 두 번째 부분에서는 클러스터 사용을 시작하는 방법과 사용 시 주의할 사항에 대한 조언을 제공합니다.

기술선택

그렇게 나쁜가요? 별도의 Redis (독립형 Redis) 1개의 마스터와 N개의 슬레이브로 구성됩니까? 왜 그것을 쓸모없는 기술이라고 부르는가?

아니요, Redis는 그렇게 나쁘지는 않습니다... 하지만 무시할 수 없는 몇 가지 단점이 있습니다.

• 첫째, Redis는 마스터 장애 후 재해 복구 메커니즘을 지원하지 않습니다. 이 문제를 해결하기 위해 우리는 VIP를 새 마스터로 자동 전송하여 슬레이브 중 하나의 역할을 변경하고 나머지를 전환하는 구성을 사용했습니다. 이 메커니즘은 효과가 있었지만 신뢰할 수 있는 솔루션이라고 할 수는 없었습니다. 첫째, 허위 경보가 발생했고 둘째, 일회용이었고 작동 후 스프링을 충전하기 위해 수동 조치가 필요했습니다.

• 둘째, 마스터가 하나만 있으면 샤딩 문제가 발생합니다. 우리는 "1개의 마스터와 N개의 슬레이브"라는 독립적인 클러스터를 여러 개 생성한 다음 이러한 시스템에 데이터베이스를 수동으로 배포하고 내일 데이터베이스 중 하나가 너무 많이 늘어나서 별도의 인스턴스로 이동해야 하지 않기를 바랐습니다.

옵션은 무엇입니까?

• 가장 비싸고 풍부한 솔루션은 Redis-Enterprise입니다. 이는 완전한 기술 지원이 포함된 박스형 솔루션입니다. 기술적인 관점에서는 이상적으로 보이지만 이념적인 이유로 우리에게는 적합하지 않았습니다.
• Redis 클러스터. 기본적으로 마스터 장애 조치 및 샤딩이 지원됩니다. 인터페이스는 일반 버전과 거의 다르지 않습니다. 유망해 보이지만 나중에 함정에 대해 이야기하겠습니다.
• Tarantool, Memcache, Aerospike 등. 이 모든 도구는 거의 동일한 작업을 수행합니다. 그러나 각각에는 고유한 단점이 있습니다. 우리는 모든 계란을 한 바구니에 담지 않기로 결정했습니다. 우리는 다른 작업에 Memcache와 Tarantool을 사용하고 있으며 앞으로 실제로는 더 많은 문제가 있다고 말할 것입니다.

사용 세부 사항

역사적으로 Redis를 사용하여 어떤 문제를 해결했으며 어떤 기능을 사용했는지 살펴보겠습니다.

• 2GIS와 같은 원격 서비스에 요청하기 전에 캐시 | 골랑
  

  GET SET MGET MSET "SELECT DB"

• MYSQL 이전의 캐시 | PHP
  

  GET SET MGET MSET 스캔 "키별 패턴" "SELECT DB"

• 세션 및 드라이버 좌표 작업 서비스를 위한 메인 스토리지 | 골랑
  

  GET SET MGET MSET "DB 선택" "GEO 키 추가" "GEO 키 가져오기" 스캔

보시다시피 더 높은 수학은 없습니다. 그렇다면 어려움은 무엇입니까? 각 방법을 개별적으로 살펴보겠습니다.

방법
기술
Redis 클러스터의 특징
결정

GET SET
쓰기/읽기 키

MGET MSET
여러 키 쓰기/읽기
키는 다른 노드에 있습니다. 기성 라이브러리는 하나의 노드 내에서만 다중 작업을 수행할 수 있습니다.
MGET을 N GET 작업의 파이프라인으로 대체

DB 선택
우리가 작업할 베이스를 선택하세요
여러 데이터베이스를 지원하지 않습니다
모든 것을 하나의 데이터베이스에 담으세요. 키에 접두사 추가

주사
데이터베이스의 모든 키를 살펴보세요.
데이터베이스가 하나이므로 클러스터의 모든 키를 처리하는 데 비용이 너무 많이 듭니다.
하나의 키 내에서 불변성을 유지하고 이 키에 대해 HSCAN을 수행합니다. 아니면 완전히 거절하세요.

GEO
Geokey를 사용한 작업
Geokey는 샤딩되지 않습니다.

패턴별 키
패턴으로 키 검색
데이터베이스가 하나이므로 클러스터의 모든 키를 검색합니다. 너무 비싼
SCAN의 경우처럼 불변성을 거부하거나 유지하십시오.

Redis 대 Redis 클러스터

클러스터로 전환하면 무엇을 잃고 무엇을 얻습니까?

• 단점: 여러 데이터베이스의 기능이 손실됩니다.
  • 논리적으로 관련이 없는 데이터를 하나의 클러스터에 저장하려면 접두사 형태로 목발을 만들어야 합니다.
  • SCAN, DBSIZE, CLEAR DB 등과 같은 모든 "기본" 작업이 손실됩니다.
  • 다중 작업은 여러 노드에 대한 액세스가 필요할 수 있기 때문에 구현하기가 훨씬 더 어려워졌습니다.
• 장점 :
  • 마스터 장애 조치 형태의 내결함성.
  • Redis 측의 샤딩.
  • 가동 중지 시간 없이 원자적으로 노드 간에 데이터를 전송합니다.
  • 가동 중지 시간 없이 용량과 로드를 추가하고 재분배합니다.

높은 수준의 내결함성을 제공할 필요가 없다면 클러스터로 이동하는 것은 그다지 가치가 없다는 결론을 내릴 수 있습니다. 왜냐하면 이는 사소한 작업이 될 수 있기 때문입니다. 그러나 처음에 별도 버전과 클러스터 버전 중 하나를 선택하는 경우에는 클러스터를 선택해야 합니다. 클러스터가 더 나쁘지 않고 골치 아픈 문제도 완화해 주기 때문입니다.

이사 준비 중

이사 요구 사항부터 시작해 보겠습니다.

• 그것은 원활해야합니다. 5분 동안 서비스가 완전히 중단되는 것은 우리에게 적합하지 않습니다.
• 가능한 한 안전하고 점진적으로 진행되어야 합니다. 나는 상황을 어느 정도 통제하고 싶다. 우리는 모든 것을 한꺼번에 버리고 롤백 버튼을 놓고 기도하고 싶지 않습니다.
• 이동 시 데이터 손실이 최소화됩니다. 우리는 원자적으로 이동하는 것이 매우 어렵다는 것을 이해하므로 일반 Redis와 클러스터형 Redis의 데이터 간에 약간의 비동기화를 허용합니다.

클러스터 유지 관리

이동하기 직전에 클러스터를 지원할 수 있는지 생각해 봐야 합니다.

• 차트. 우리는 Prometheus와 Grafana를 사용하여 CPU 로드, 메모리 사용량, 클라이언트 수, GET, SET, AUTH 작업 수 등을 그래프로 표시합니다.
• 전문적 지식. 내일 당신이 책임지는 거대한 클러스터를 갖게 될 것이라고 상상해 보십시오. 고장나면 당신 외에는 누구도 고칠 수 없습니다. 그가 속도를 늦추기 시작하면 모두가 당신을 향해 달려갈 것입니다. 리소스를 추가하거나 로드를 재분배해야 하는 경우 다시 연락하세요. 25세에 회색으로 변하지 않으려면 이러한 경우를 제공하고 특정 작업에서 기술이 어떻게 작동하는지 미리 확인하는 것이 좋습니다. 이에 대한 자세한 내용은 "전문 지식" 섹션에서 살펴보겠습니다.
• 모니터링 및 경고. 클러스터가 중단되면 가장 먼저 이에 대해 알고 싶습니다. 여기서는 모든 노드가 클러스터 상태에 대해 동일한 정보를 반환한다는 알림으로 제한했습니다(예, 다르게 발생합니다). 그리고 Redis 클라이언트 서비스의 경고를 통해 다른 문제를 더 빨리 발견할 수 있습니다.

재배치

우리가 어떻게 움직일 것인가:

• 먼저, 클러스터와 연동할 라이브러리를 준비해야 합니다. 우리는 go-redis를 Go 버전의 기반으로 삼아 우리에게 맞게 약간 변경했습니다. 파이프라인을 통해 다중 메서드를 구현하고 요청 반복 규칙도 약간 수정했습니다. PHP 버전에는 더 많은 문제가 있었지만 결국 php-redis로 결정했습니다. 최근에 클러스터 지원을 도입했는데 우리 의견으로는 좋아 보입니다.
• 다음으로 클러스터 자체를 배포해야 합니다. 이는 문자 그대로 구성 파일을 기반으로 하는 두 가지 명령으로 수행됩니다. 설정에 대해서는 아래에서 더 자세히 다루겠습니다.
• 점진적인 이동을 위해 건조 모드를 사용합니다. 동일한 인터페이스를 가진 두 가지 버전의 라이브러리(하나는 일반 버전용, 다른 하나는 클러스터용)가 있으므로 별도의 버전에서 작동하고 모든 요청을 클러스터에 병렬로 복제하는 래퍼를 만드는 데 비용이 들지 않습니다. 응답을 비교하고 로그에 불일치를 기록합니다(이 경우 NewRelic). 따라서 롤아웃 중에 클러스터 버전이 중단되더라도 프로덕션에는 영향을 미치지 않습니다.
• 클러스터를 건조 모드로 롤아웃한 후 응답 불일치 그래프를 침착하게 볼 수 있습니다. 오류율이 느리지만 확실하게 작은 상수 쪽으로 이동한다면 모든 것이 정상입니다. 왜 여전히 불일치가 있습니까? 별도의 버전으로의 기록은 클러스터보다 조금 더 일찍 이루어지기 때문에, 마이크로랙으로 인해 데이터가 엇갈릴 수 있습니다. 남은 것은 불일치 로그를 살펴보는 것뿐입니다. 그리고 불일치 로그가 모두 레코드의 비원자성으로 설명되면 계속 진행할 수 있습니다.
• 이제 건조 모드를 반대 방향으로 전환할 수 있습니다. 클러스터에서 쓰고 읽고 이를 별도의 버전으로 복제하겠습니다. 무엇을 위해? 다음 주 동안 나는 클러스터의 작업을 관찰하고 싶습니다. 갑자기 최대 부하에 문제가 있는 것으로 밝혀지거나 무언가를 고려하지 않은 경우 건조 모드 덕분에 항상 이전 코드와 현재 데이터로 긴급 롤백됩니다.
• 남은 것은 건조 모드를 비활성화하고 별도 버전을 분해하는 것뿐입니다.

전문적 지식

먼저 클러스터 디자인에 대해 간략히 설명하겠습니다.

우선 Redis는 키-값 저장소입니다. 임의의 문자열이 키로 사용됩니다. 숫자, 문자열, 전체 구조를 값으로 사용할 수 있습니다. 후자가 많이 있지만 일반적인 구조를 이해하는 데 이것은 우리에게 중요하지 않습니다.
키 다음 추상화 수준은 슬롯(SLOTS)입니다. 각 키는 16개 슬롯 중 하나에 속합니다. 각 슬롯 안에는 원하는 만큼의 키가 있을 수 있습니다. 따라서 모든 키는 383개의 분리된 세트로 나뉩니다.

다음으로 클러스터에는 N개의 마스터 노드가 있어야 합니다. 각 노드는 클러스터 내의 다른 노드에 대한 모든 것을 알고 있는 별도의 Redis 인스턴스로 생각할 수 있습니다. 각 마스터 노드에는 여러 개의 슬롯이 포함되어 있습니다. 각 슬롯은 하나의 마스터 노드에만 속합니다. 모든 슬롯은 노드 간에 분산되어야 합니다. 일부 슬롯이 할당되지 않으면 해당 슬롯에 저장된 키에 액세스할 수 없습니다. 별도의 논리적 또는 물리적 머신에서 각 마스터 노드를 실행하는 것이 합리적입니다. 또한 각 노드는 하나의 코어에서만 실행된다는 점을 기억할 가치가 있습니다. 동일한 논리적 시스템에서 여러 Redis 인스턴스를 실행하려면 서로 다른 코어에서 실행되는지 확인하세요(시도하지는 않았지만 이론적으로는 작동해야 합니다). . 기본적으로 마스터 노드는 일반 샤딩을 제공하고, 더 많은 마스터 노드를 사용하면 쓰기 및 읽기 요청을 확장할 수 있습니다.

모든 키가 슬롯에 분배되고 슬롯이 마스터 노드에 분산된 후 각 마스터 노드에 임의 수의 슬레이브 노드를 추가할 수 있습니다. 이러한 각 마스터-슬레이브 링크 내에서 일반 복제가 작동합니다. 읽기 요청을 확장하고 마스터 오류가 발생한 경우 장애 조치를 수행하려면 슬레이브가 필요합니다.

이제 할 수 있는 것이 더 나은 작업에 대해 이야기해 보겠습니다.

Redis-CLI를 통해 시스템에 액세스하겠습니다. Redis에는 단일 진입점이 없으므로 모든 노드에서 다음 작업을 수행할 수 있습니다. 각 지점에서 나는 부하가 걸린 상태에서 작업을 수행할 가능성에 대해 별도로 주목합니다.

• 우리에게 필요한 첫 번째이자 가장 중요한 것은 클러스터 노드 작업입니다. 클러스터 상태를 반환하고 노드 목록, 역할, 슬롯 분포 등을 표시합니다. 클러스터 정보 및 클러스터 슬롯을 사용하여 더 많은 정보를 얻을 수 있습니다.
• 노드를 추가하고 제거할 수 있으면 좋을 것 같습니다. 이를 위해 클러스터 충족 및 클러스터 삭제 작업이 있습니다. 클러스터 삭제는 마스터와 복제본 모두 모든 노드에 적용되어야 합니다. 그리고 클러스터 모임은 하나의 노드에서만 호출하면 됩니다. 이 차이점은 당황스러울 수 있으므로 클러스터를 실행하기 전에 이에 대해 알아보는 것이 가장 좋습니다. 노드 추가는 전투 중에 안전하게 수행되며 어떤 방식으로든 클러스터 작동에 영향을 미치지 않습니다(논리적임). 클러스터에서 노드를 제거하려면 해당 노드에 슬롯이 남아 있지 않은지 확인해야 합니다. 그렇지 않으면 이 노드의 모든 키에 대한 액세스를 잃을 위험이 있습니다. 또한 슬레이브가 있는 마스터를 삭제하지 마십시오. 그렇지 않으면 새 마스터에 대한 불필요한 투표가 수행됩니다. 노드에 더 이상 슬롯이 없다면 이는 작은 문제이지만 먼저 슬레이브를 삭제할 수 있다면 추가 선택이 필요한 이유는 무엇입니까?
• 마스터와 슬레이브 위치를 강제로 바꿔야 하는 경우 클러스터 장애 조치 명령을 사용하면 됩니다. 전투에서 호출할 때는 작전 중에는 마스터를 사용할 수 없다는 점을 이해해야 합니다. 일반적으로 전환은 XNUMX초 이내에 발생하지만 원자적이지는 않습니다. 이 시간 동안 마스터에 대한 일부 요청이 실패할 것으로 예상할 수 있습니다.
• 클러스터에서 노드를 제거하기 전에 노드에 슬롯이 남아 있지 않아야 합니다. Cluster reshard 명령을 사용하여 재배포하는 것이 좋습니다. 슬롯은 한 마스터에서 다른 마스터로 전송됩니다. 전체 작업은 전송되는 데이터의 양에 따라 몇 분 정도 걸릴 수 있지만 전송 프로세스는 안전하며 어떤 방식으로든 클러스터 작업에 영향을 미치지 않습니다. 따라서 모든 데이터는 가용성에 대한 걱정 없이 부하가 걸린 상태에서 한 노드에서 다른 노드로 직접 전송할 수 있습니다. 그러나 미묘함도 있습니다. 첫째, 데이터 전송은 수신자 및 발신자 노드의 특정 부하와 관련됩니다. 수신자 노드가 이미 프로세서에 과도하게 로드되어 있는 경우 새 데이터를 수신하면서 이를 로드해서는 안 됩니다. 둘째, 보내는 마스터에 슬롯이 하나도 남지 않으면 모든 슬레이브가 즉시 이 슬롯이 전송된 마스터로 이동합니다. 그리고 문제는 이 모든 슬레이브가 동시에 데이터를 동기화하기를 원한다는 것입니다. 그리고 완전한 동기화가 아닌 부분적인 동기화라면 운이 좋을 것입니다. 이를 고려하여 슬롯 전송 작업과 슬레이브 비활성화/전송 작업을 결합하세요. 아니면 충분한 안전 여유가 있기를 바랍니다.
• 전송 중에 어딘가에서 슬롯을 잃어버린 것을 발견하면 어떻게 해야 합니까? 이 문제가 귀하에게 영향을 미치지 않기를 바랍니다. 만약 그렇다면 클러스터 수정 작업이 있습니다. 최소한 그녀는 무작위 순서로 노드 전체에 슬롯을 분산시킬 것입니다. 먼저 클러스터에서 분산된 슬롯이 있는 노드를 제거하여 작동을 확인하는 것이 좋습니다. 할당되지 않은 슬롯의 데이터는 이미 사용할 수 없으므로 해당 슬롯의 가용성 문제를 걱정하기에는 너무 늦었습니다. 결과적으로 작업은 분산된 슬롯에 영향을 주지 않습니다.
• 또 다른 유용한 작업은 모니터입니다. 이를 통해 노드로 이동하는 전체 요청 목록을 실시간으로 확인할 수 있습니다. 게다가, 이를 grep하여 필요한 트래픽이 있는지 알아낼 수도 있습니다.

마스터 장애 조치(failover) 절차도 언급할 가치가 있습니다. 요컨대 그것은 존재하며 제 생각에는 훌륭하게 작동합니다. 그러나 마스터 노드가 있는 시스템에서 전원 코드를 뽑으면 Redis가 즉시 전환되어 클라이언트가 손실을 인식하지 못할 것이라고 생각하지 마십시오. 실제로는 몇 초 안에 전환이 발생합니다. 이 시간 동안 일부 데이터는 사용할 수 없습니다. 마스터의 가용성이 감지되고, 노드가 새 노드에 투표하고, 슬레이브가 전환되고, 데이터가 동기화됩니다. 계획이 제대로 작동하는지 확인하는 가장 좋은 방법은 현지 훈련을 실시하는 것입니다. 노트북에서 클러스터를 올리고, 최소한의 로드를 제공하고, 충돌을 시뮬레이션하고(예: 포트 차단) 전환 속도를 평가합니다. 제 생각에는 이런 방식으로 하루 이틀 플레이를 해봐야만 기술의 작동에 자신감을 가질 수 있을 것 같습니다. 글쎄, 아니면 인터넷의 절반이 사용하는 소프트웨어가 아마도 작동하기를 바랍니다.

구성

도구 작업을 시작하기 위해 가장 먼저 구성이 필요한 경우가 많으며, 모든 것이 제대로 작동하면 구성을 건드리고 싶지도 않습니다. 강제로 설정으로 돌아가서 주의 깊게 살펴보려면 약간의 노력이 필요합니다. 내 기억으로는 구성에 대한 부주의로 인해 적어도 두 번 정도 심각한 실패가 있었던 것으로 기억됩니다. 다음 사항에 특별한 주의를 기울이십시오.

• 0 시간 초과
  비활성 연결이 닫힌 후의 시간(초)입니다. 0 - 닫지 않음
  우리의 모든 라이브러리가 연결을 올바르게 닫을 수 있는 것은 아닙니다. 이 설정을 비활성화하면 클라이언트 수 제한에 도달할 위험이 있습니다. 반면에 그러한 문제가 있는 경우 끊어진 연결이 자동으로 종료되어 이를 가려서 우리가 알아차리지 못할 수도 있습니다. 또한 지속 연결을 사용할 때는 이 설정을 활성화하면 안 됩니다.
• xy 저장 및 추가만 가능 예
  RDB 스냅샷을 저장하는 중입니다.
  아래에서 RDB/AOF 문제에 대해 자세히 논의하겠습니다.
• stop-writes-on-bgsave-error no & 슬레이브 서비스 부실 데이터 예
  활성화된 경우 RDB 스냅샷이 중단되면 마스터가 변경 요청 수락을 중지합니다. 마스터와의 연결이 끊어지면 슬레이브는 계속해서 요청에 응답할 수 있습니다(예). 아니면 응답을 중지합니다(아니요).
  우리는 Redis가 호박으로 변하는 상황에 만족하지 않습니다.
• repl-ping-노예-기간 5
  이 기간이 지나면 마스터가 고장났는지 걱정하기 시작하고 장애 조치(failover) 절차를 수행할 시간입니다.
  거짓 긍정과 장애 조치 트리거 간의 균형을 수동으로 찾아야 합니다. 실제로는 5초입니다.
• repl-백로그 크기 1024mb 및 epl-백로그-ttl 0
  실패한 복제본에 대해 정확히 이만큼의 데이터를 버퍼에 저장할 수 있습니다. 버퍼가 부족하면 완전히 동기화해야 합니다.
  실습에 따르면 더 높은 값을 설정하는 것이 더 좋습니다. 복제본이 지연되기 시작하는 데는 여러 가지 이유가 있습니다. 지연된다면 마스터가 이미 대처하기 위해 고군분투하고 있을 가능성이 높으며 전체 동기화가 마지막 지푸라기가 될 것입니다.
• 최대 클라이언트 10000
  일회성 클라이언트의 최대 수입니다.
  경험상 더 높은 값을 설정하는 것이 좋습니다. Redis는 10개의 연결을 잘 처리합니다. 시스템에 충분한 소켓이 있는지 확인하십시오.
• 최대 메모리 정책 휘발성-ttl
  사용 가능한 메모리 제한에 도달하면 키가 삭제되는 규칙입니다.
  여기서 중요한 것은 규칙 자체가 아니라 이것이 어떻게 일어날 것인지에 대한 이해입니다. Redis는 메모리 제한에 도달했을 때 정상적으로 작동하는 능력으로 칭찬받을 수 있습니다.

RDB 및 AOF 문제

Redis 자체는 모든 정보를 RAM에 저장하지만 데이터를 디스크에 저장하는 메커니즘도 있습니다. 보다 정확하게는 세 가지 메커니즘입니다.

• RDB-스냅샷 - 모든 데이터의 완전한 스냅샷입니다. SAVE XY 구성을 사용하여 설정하고 "최소 Y 키가 변경된 경우 X초마다 모든 데이터의 전체 스냅샷을 저장합니다."라고 읽습니다.
• 추가 전용 파일 - 수행되는 순서에 따른 작업 목록입니다. X초마다 또는 Y 작업마다 파일에 새 수신 작업을 추가합니다.
• RDB와 AOF는 이전 두 가지의 조합입니다.

모든 방법에는 장점과 단점이 있으므로 모두 나열하지는 않겠습니다. 제 생각에는 명확하지 않은 점만 강조하겠습니다.

먼저, RDB 스냅샷을 저장하려면 FORK를 호출해야 합니다. 데이터가 많으면 몇 밀리초에서 몇 초 동안 모든 Redis가 중단될 수 있습니다. 또한 시스템은 이러한 스냅샷을 위해 메모리를 할당해야 하므로 논리 머신에서 RAM을 두 배로 공급해야 합니다. Redis에 8GB가 할당된 경우 가상 머신에서는 16GB를 사용할 수 있어야 합니다. 그것.

둘째, 부분 동기화에 문제가 있습니다. AOF 모드에서는 슬레이브가 다시 연결될 때 부분 동기화가 아닌 전체 동기화를 수행할 수 있습니다. 왜 이런 일이 일어나는지 이해할 수 없었습니다. 그러나 이것을 기억할 가치가 있습니다.

이 두 가지 점은 모든 것이 이미 슬레이브에 의해 복제된 경우 디스크에 이 데이터가 정말로 필요한지 여부를 생각하게 만듭니다. 모든 슬레이브가 실패하는 경우에만 데이터가 손실될 수 있으며 이는 "DC 화재" 수준의 문제입니다. 절충안으로 슬레이브에만 데이터를 저장하도록 제안할 수 있지만 이 경우 재해 복구 중에 이러한 슬레이브가 마스터가 되지 않도록 해야 합니다(이를 위해 구성에 슬레이브 우선순위 설정이 있습니다). 우리는 각각의 특정 경우에 데이터를 디스크에 저장할 필요가 있는지 생각하며 대부분의 경우 대답은 "아니오"입니다.

결론

결론적으로, redis-cluster에 대해 전혀 들어보지 못한 분들에게는 redis-cluster가 어떻게 작동하는지에 대한 일반적인 아이디어를 줄 수 있었으면 좋겠고, 사용해 보신 분들에게는 몇 가지 불명확한 점에 대해서도 관심을 끌 수 있었으면 좋겠습니다. 오랫동안.
시간을 내주셔서 감사드리며, 언제나 그렇듯이 해당 주제에 대한 의견을 환영합니다.

출처 : habr.com