Redis 샤딩(분산 캐시)

파티셔닝은 데이터를 여러 Redis 인스턴스로 분할하여 각 인스턴스에 모든 키의 하위 집합만 포함하는 프로세스입니다. (관련 권장 사항: Redis 튜토리얼)

1 샤딩의 용도 ?

Redis의 샤딩에는 두 가지 주요 목표가 있습니다.

• 많은 컴퓨터의 결합된 메모리를 사용하여 더 큰 데이터베이스를 지원할 수 있습니다. 샤딩이 없으면 단일 머신이 지원할 수 있는 메모리 양이 제한됩니다.

• 컴퓨팅 성능을 다중 코어 또는 다중 서버로 확장하고 네트워크 대역폭을 다중 서버 또는 다중 네트워크 어댑터로 확장할 수 있습니다.

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: 형식에는 키가 필요하지 않습니다. 이렇게 간단합니다

• A 해시 함수를 사용합니다(예: crc32 해시) 함수)는 키 이름을 숫자로 변환합니다. 예를 들어 키가 foobar인 경우 crc32(foobar)는 93024922와 같은 결과를 출력합니다.

• 이 데이터를 모듈로 처리하여 0에서 3 사이의 숫자로 변환하면 해당 숫자가 4개의 Redis 인스턴스 중 하나에 매핑될 수 있습니다. 93024922 모듈로 4는 2이므로 내 키 foobar가 R2 인스턴스에 저장되어야 한다는 것을 알고 있습니다. 참고: 모듈로 연산은 많은 프로그래밍 언어에서 항상 % 연산자로 구현되는 나눗셈 연산의 나머지 부분을 반환합니다.

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

3 샤딩 구현(이론)

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

• 클라이언트 측 파티셔닝

클라이언트는 지정된 키를 쓰고 읽기 위해 올바른 노드를 직접 선택합니다. 많은 Redis 클라이언트는 클라이언트 측 샤딩을 구현합니다.

• 프록시 지원 샤딩(프록시 지원 파티셔닝)

우리 클라이언트는 다음으로 요청을 보냅니다. Redis 프로토콜을 이해할 수 있는 프록시입니다. 요청을 Redis 인스턴스로 직접 보내는 대신

프록시는 구성된 샤딩 모드에 따라 요청이 전달되는지 확인하고 클라이언트에 응답을 반환합니다.

Redis 및 Memcached 프록시 Twemproxy는 프록시 지원 샤딩을 구현합니다.

• 쿼리 라우팅

쿼리를 임의의 인스턴스로 보낼 수 있습니다. 이 인스턴스는 쿼리가 올바른 노드로 전달되도록 합니다. 클라이언트의 도움을 받는 하이브리드 형태의 쿼리 라우팅(요청이 Redis 인스턴스에서 다른 인스턴스로 직접 전달되지 않고 클라이언트에서 수신됨).

4 샤딩의 단점

일부 기능 Redis는 샤딩과 잘 작동하지 않습니다

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

• 여러 키와 관련된 트랜잭션은 사용할 수 없습니다.

• 샤딩 세분성(세분성)은 따라서 대량 주문 세트와 같은 데이터 세트를 샤딩하는 데 큰 키를 사용할 수 없습니다.

• 샤딩을 사용하면 데이터 처리가 더 복잡해집니다. 예를 들어 여러 RDB/AOF 파일을 처리해야 하는 경우입니다. 데이터를 백업하려면 여러 인스턴스와 호스트의 영구 파일을 집계해야 합니다

• 용량을 추가하고 삭제하는 것도 복잡합니다. 예를 들어 Redis 클러스터에는 투명한 데이터 재조정을 지원하기 위해 런타임에 노드를 동적으로 추가 및 제거하는 기능이 있지만 클라이언트 측 샤딩 및 프록시와 같은 다른 방법은 이 기능을 지원하지 않습니다. 그러나 이 시점에서 도움이 될 수 있는 사전 샤딩이라는 기술이 있습니다.

5 저장소 또는 캐시

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

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

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

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

• Redis를 스토리지로 사용하는 경우 고정된 키-노드 매핑이 사용되므로 노드 수는 고정되어야 하며 변경할 수 없습니다. 그렇지 않으면 노드를 추가하고 삭제할 때 노드 간 키 재분배를 지원하는 시스템이 필요합니다. 현재는 Redis 클러스터에서만 이를 수행할 수 있습니다.

6 사전 샤딩

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

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

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

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

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

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

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

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

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

• 이동된 인스턴스의 서버 IP 주소 구성을 업데이트하세요.

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

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

• 마지막으로 더 이상 사용하지 않는 이전 서버의 인스턴스를 종료하세요.

7 샤딩 구현(실습)

지금까지 Redis 샤딩에 대해 이론적으로 설명했지만 실습은 어떨까요? 어떤 시스템을 사용해야 합니까?

7.1 Redis Cluster

Redis Cluster는 자동 샤딩 및 고가용성을 위해 선호되는 방법입니다.

Redis Cluster가 사용 가능하고 Redis Cluster를 지원하는 클라이언트가 사용 가능해지면 Redis Cluster는 Redis 샤딩의 사실상 표준이 될 것입니다. .

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

7.2 Twemproxy

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

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

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

기본적으로 Twemproxy는 클라이언트와 Redis 인스턴스 사이의 중간 계층이므로 추가 복잡성을 최소화하면서 샤드를 안정적으로 처리할 수 있습니다. 이는 Redis 샤딩을 처리하는 데 현재 권장되는 방법입니다.

7.3 일관된 해싱을 지원하는 클라이언트

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

Redis 클라이언트의 전체 목록을 확인하여 프로그래밍 언어를 지원하고 일관된 해싱을 구현하는 성숙한 클라이언트가 있는지 확인하세요.

위 내용은 Redis 샤딩(분산 캐시)의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!