Redis 샤딩에 대한 자세한 설명

파티셔닝은 데이터를 여러 Redis 인스턴스로 분할하여 각 인스턴스에 모든 키의 하위 집합만 포함하는 프로세스입니다. 이 기사의 첫 번째 부분에서는 샤딩의 개념을 소개하고, 두 번째 부분에서는 Redis 샤딩 옵션을 보여줍니다.

샤딩이 할 수 있는 작업

Redis의 샤딩에는 두 가지 주요 목표가 있습니다. #🎜 🎜##🎜 🎜#1. 더 큰 데이터베이스를 지원하는 데 여러 컴퓨터의 총 메모리를 사용할 수 있습니다. 샤딩이 없으면 단일 머신이 지원할 수 있는 메모리 양이 제한됩니다.

2. 컴퓨팅 성능을 다중 코어 또는 다중 서버로 확장하고 네트워크 대역폭을 다중 서버 또는 다중 네트워크 어댑터로 확장할 수 있습니다. 다양한 샤딩 기준(기준)이 있습니다. 4개의 Redis 인스턴스 R0, R1, R2, R3과 user:1, user:2 등과 같이 사용자를 나타내는 많은 키가 있다고 가정합니다. 저장할 특정 키를 선택하는 다양한 방법을 찾을 수 있습니다. . 즉, 키를 특정 Redis 서버에 매핑하는 방법에는 여러 가지가 있습니다.

샤딩을 수행하는 가장 간단한 방법 중 하나는 객체의 범위를 지정된 Redis 인스턴스에 매핑하여 샤딩을 완료하는 범위 파티셔닝입니다. 예를 들어, 사용자가 ID 0부터 ID 10000까지 인스턴스 R0을 입력하고, ID 10001부터 ID 20000까지 인스턴스 R1을 입력하는 식으로 가정할 수 있습니다.

이 접근 방식은 실제로 효과적이며 실제로 사용됩니다. 그러나 범위를 인스턴스에 매핑하는 테이블이 필요하다는 단점이 있습니다. 이 테이블은 관리되어야 하며 다양한 유형의 객체에는 테이블이 필요하므로 범위 샤딩은 샤딩 대안보다 효율성이 훨씬 낮기 때문에 Redis에서는 권장되지 않는 경우가 많습니다. 범위 샤딩의 대안은 해시 파티셔닝입니다. 이 모드는 모든 키와 함께 작동하며 키가 object_name: 형식일 필요는 없습니다. 다음과 같이 간단합니다. 해시 함수(예: crc32 해시 함수)를 사용하세요. 키 이름을 변환하려면 숫자로 변환하세요. 예를 들어 키가 foobar인 경우 crc32(foobar)는 93024922와 같은 결과를 출력합니다. 2. 이 데이터를 0에서 3 사이의 숫자로 변환하여 이 숫자를 4개의 Redis 인스턴스 중 하나에 매핑할 수 있습니다. 93024922 모듈로 4는 2이므로 내 키 foobar가 R2 인스턴스에 저장되어야 한다는 것을 알고 있습니다. 참고: 모듈로 연산은 많은 프로그래밍 언어에서 항상 % 연산자로 구현되는 나눗셈 연산의 나머지 부분을 반환합니다.

이 두 가지 예에서 볼 수 있듯이 샤딩하는 다른 방법도 많이 있습니다. 해시 샤딩의 고급 형태를 일관된 해싱이라고 하며 일부 Redis 클라이언트 및 브로커에서 구현합니다.

다양한 샤딩 구현

샤딩은 소프트웨어 스택의 다양한 부분에서 수행될 수 있습니다.

1. 클라이언트 측 파티셔닝은 클라이언트가 지정된 키를 쓰고 읽을 올바른 노드를 직접 선택하는 것을 의미합니다. 많은 Redis 클라이언트는 클라이언트 측 샤딩을 구현합니다.

2. 프록시 지원 파티셔닝은 클라이언트가 Redis 인스턴스에 직접 요청을 보내는 대신 Redis 프로토콜을 이해할 수 있는 프록시에 요청을 보내는 것을 의미합니다. 프록시는 구성된 샤딩 모드에 따라 요청이 올바른 Redis 인스턴스로 전달되는지 확인하고 클라이언트에 응답을 반환합니다. Redis 및 Memcached용 프록시인 Twemproxy는 프록시 지원 샤딩을 구현합니다.

3. 쿼리 라우팅은 쿼리를 임의의 인스턴스로 보낼 수 있음을 의미하며, 이 인스턴스는 쿼리가 올바른 노드로 전달되도록 보장합니다. Redis 클러스터는 클라이언트의 도움을 받아 하이브리드 형태의 쿼리 라우팅을 구현합니다(요청은 하나의 Redis 인스턴스에서 다른 인스턴스로 직접 전달되지 않지만 클라이언트는 올바른 노드로 리디렉션을 받습니다). 샤딩의 단점

Redis의 일부 기능은 샤딩을 가지고 놀기에는 재미가 없습니다. 매우 좋음: # 🎜🎜#

1. 여러 키를 사용하는 작업은 일반적으로 지원되지 않습니다. 예를 들어 두 개의 서로 다른 Redis 인스턴스에 매핑된 키에 대해 교차를 수행할 수 없습니다(실제로 이를 수행하는 방법이 있지만 직접적으로 수행할 수는 없음).

2. 여러 키를 사용하는 거래는 사용할 수 없습니다.

3. 샤딩의 세분성이 핵심이므로 대규모 주문 세트와 같은 데이터 세트를 샤딩하는 데 큰 키를 사용할 수 없습니다.

4. 샤딩을 사용하면 데이터 처리가 더욱 복잡해집니다. 예를 들어 여러 RDB/AOF 파일을 처리해야 할 경우 여러 인스턴스의 지속성 파일을 집계해야 합니다. 호스트. 5. 용량을 추가하고 삭제하는 것도 복잡합니다. 예를 들어 Redis 클러스터에는 투명한 데이터 재조정을 지원하기 위해 런타임에 노드를 동적으로 추가 및 제거하는 기능이 있지만 클라이언트 측 샤딩 및 프록시와 같은 다른 방법은 이 기능을 지원하지 않습니다. 그러나 이 시점에서 도움이 될 수 있는 사전 샤딩이라는 기술이 있습니다.

데이터 저장소 또는 캐시

Redis를 데이터 저장소로 사용하든 캐시로 사용하든 Redis의 샤딩 개념은 동일하지만 데이터 저장소로 사용할 경우 중요한 제한 사항이 있습니다. Redis를 데이터 저장소로 사용하는 경우 지정된 키는 항상 동일한 Redis 인스턴스에 매핑됩니다. Redis를 캐시로 사용할 때 한 노드를 사용할 수 없고 다른 노드를 사용하는 경우에는 큰 문제가 되지 않습니다. 키와 인스턴스의 매핑을 원하는 대로 변경하면 시스템의 가용성(즉, 시스템의 능력)이 향상됩니다. 우리의 질문에 대답하십시오).

일관적인 해싱 구현은 특정 키에 대해 선호하는 노드를 사용할 수 없는 경우 다른 노드로 전환할 수 있는 경우가 많습니다. 마찬가지로, 새 노드를 추가하면 일부 데이터가 이 새 노드에 저장되기 시작합니다.

여기의 주요 개념은 다음과 같습니다.

1. Redis를 캐시로 사용하는 경우 일관된 해싱을 사용하여 확장 및 축소를 쉽게 달성할 수 있습니다.

2. Redis를 스토리지로 사용하는 경우 고정된 키-노드 매핑을 사용하므로 노드 수가 고정되어야 하며 변경할 수 없습니다. 그렇지 않으면 노드를 추가하거나 삭제할 때 노드 간 키 재분배를 지원하는 시스템이 필요합니다. 현재는 Redis Cluster에서만 이를 수행할 수 있지만 Redis Cluster는 아직 베타 단계에 있어 프로덕션 환경에서의 사용은 아직 고려되지 않았습니다.

사전 샤딩

우리는 이미 샤딩에 대한 문제를 알고 있습니다. Redis를 캐시로 사용하지 않는 한, 노드를 추가하고 제거하는 것은 고정 키와 인스턴스 매핑을 많이 사용하는 것이 훨씬 간단합니다.

그러나 데이터 저장 요구 사항은 항상 변할 수 있습니다. 오늘은 10개의 Redis 노드(인스턴스)로 생활할 수 있지만 내일은 50개의 노드가 필요할 수 있습니다.

Redis는 메모리 공간이 상당히 작고 가볍기 때문에(유휴 인스턴스는 1MB의 메모리만 사용) 간단한 해결책은 처음부터 많은 인스턴스를 시작하는 것입니다. 단 하나의 서버로 시작하더라도 첫날부터 분산 세계에 살기로 결정하고 샤딩을 사용하여 단일 서버에서 여러 Redis 인스턴스를 실행할 수 있습니다.

처음부터 많은 수의 인스턴스를 선택할 수 있습니다. 예를 들어, 32개 또는 64개의 인스턴스는 대부분의 사용자를 만족시키고 향후 성장을 위한 충분한 공간을 제공합니다.

이렇게 하면 데이터 스토리지를 늘려야 하고 더 많은 Redis 서버가 필요할 때 한 서버에서 다른 서버로 인스턴스를 이동하기만 하면 됩니다. 첫 번째 서버를 추가할 때 Redis 인스턴스의 절반을 첫 번째 서버에서 두 번째 서버로 이동해야 합니다.

Redis 복제를 사용하면 가동 중지 시간이 거의 또는 전혀 없이 데이터를 이동할 수 있습니다.

1. 새 서버에서 빈 인스턴스를 시작합니다.

2. 데이터를 이동하고 새 인스턴스를 원본 인스턴스의 슬레이브 서비스로 구성합니다.

3. 클라이언트를 중지하세요.

4. 이동된 인스턴스의 서버 IP 주소 구성을 업데이트합니다.

5. 새 서버의 슬레이브 노드에 SLAVEOF NO ONE 명령을 보냅니다.

6. 새롭게 업데이트된 구성으로 클라이언트를 시작하세요.

7. 마지막으로 이전 서버에서 더 이상 사용되지 않는 인스턴스를 닫습니다.

Redis 샤딩 구현

Redis 클러스터는 자동 샤딩 및 고가용성을 위해 선호되는 방법입니다. 아직 프로덕션 용도로 완전히 사용할 수는 없지만 베타 단계에 진입했습니다.

Redis 클러스터를 사용할 수 있고 Redis 클러스터를 지원하는 클라이언트를 사용할 수 있게 되면 Redis 클러스터는 Redis 샤딩의 사실상 표준이 될 것입니다.

Redis 클러스터는 쿼리 라우팅과 클라이언트 샤딩의 하이브리드 모델입니다.

Twemproxy는 Memcached ASCII 및 Redis 프로토콜을 지원하는 Twitter에서 개발한 프록시입니다. 단일 스레드이고 C로 작성되었으며 매우 빠르게 실행됩니다. Apache 2.0 라이센스에 따라 라이센스가 부여된 오픈 소스 프로젝트입니다.

Twemproxy는 여러 Redis 인스턴스에 걸쳐 자동 샤딩을 지원하고 노드를 사용할 수 없는 경우 선택적 노드 제외 지원을 지원합니다(이렇게 하면 인스턴스에 대한 키 매핑이 변경되므로 Redis를 캐시 특성으로 사용하는 경우에만 이를 사용해야 합니다).

여러 프록시를 시작하고 클라이언트가 연결을 허용하는 첫 번째 프록시에 연결되도록 할 수 있으므로 이는 단일 실패 지점이 아닙니다.

Twemproxy의 대안은 일관된 해싱 또는 기타 유사한 알고리즘을 통해 클라이언트측 샤딩을 구현하는 클라이언트를 사용하는 것입니다. redis-rb 및 Predis와 같이 일관된 해싱을 지원하는 여러 Redis 클라이언트가 있습니다.

더 많은 Redis 지식을 알고 싶다면 redis 데이터베이스 튜토리얼 칼럼을 주목해 주세요.

위 내용은 Redis 샤딩에 대한 자세한 설명의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!