Redis 파티션 구현

파티셔닝은 데이터를 여러 Redis 인스턴스로 분할하는 프로세스이므로 각 인스턴스는 키의 하위 집합만 저장합니다. 이 기사에서는 redis가 파티셔닝을 구현하는 방법을 소개합니다.

구역 설정이 필요한 이유는 무엇인가요? 분할을 하게 된 동기는 무엇이었나요? 일반적으로 Redis 파티셔닝의 이점은 다음과 같습니다.

1. 성능 향상 단일 시스템 Redis의 네트워크 I/O 기능 및 컴퓨팅 리소스는 여러 시스템을 최대한 활용하기 위해 요청을 분산합니다. 머신의 컴퓨팅 성능은 네트워크 대역폭을 증가시켜 Redis의 전반적인 서비스 기능을 향상시키는 데 도움이 됩니다.

2. 스토리지의 수평적 확장. Redis의 서비스 기능이 애플리케이션 요구 사항을 충족하더라도 스토리지 데이터가 증가함에 따라 단일 머신은 머신 자체의 스토리지 용량으로 인해 데이터를 여러 머신에 분산시키는 방식으로 제한됩니다. 수평으로 확장할 수 있습니다.

일반적으로 파티셔닝을 사용하면 단일 컴퓨터의 하드웨어 리소스로 인해 제한되는 원래 문제가 더 이상 문제가 되지 않습니다. 컴퓨팅 리소스가 부족합니까? 대역폭이 충분하지 않습니까? 기계를 더 추가하면 이러한 문제를 해결할 수 있습니다.

Redis 파티셔닝 기본

실제 애플리케이션에는 파티셔닝을 위한 다양한 전략이 있습니다. 예를 들어 R0, R1, R2, R3라는 4개의 Redis 인스턴스 세트가 이미 있다고 가정해 보겠습니다. 대표 사용자 키 그룹(예: user:1, user:2,...etc.) 여기서 "user:" 뒤의 숫자는 사용자의 ID를 나타냅니다. 우리가 해야 할 일은 이 키를 이 네 개에 저장하는 것입니다. Redis 인스턴스에서는 다릅니다.

어떻게 하나요? 가장 간단한 방법은 범위 분할(range partitioning)입니다. 범위 분할을 기반으로 하는 방법을 살펴보겠습니다.

범위 파티셔닝

소위 범위 파티셔닝은 범위의 모든 키를 동일한 Redis 인스턴스에 매핑하는 것입니다. 데이터 세트를 추가하는 것은 여전히 ​​위에서 언급한 사용자 데이터입니다.

우리는 다음과 같습니다. 사용자 ID를 추가할 수 있습니다. 0부터 10000까지의 사용자 데이터는 R0 인스턴스에 매핑되고, 10001부터 20000까지의 사용자 ID를 가진 객체는 R1 인스턴스에 매핑되는 식입니다.

이 방법은 간단하지만 실제 적용에서는 매우 효과적이지만 여전히 문제가 있습니다.

1. 이 테이블은 사용자 ID 범위와 Redis 인스턴스 간의 매핑 관계를 저장하는 데 사용됩니다. 예를 들어 사용자 ID 0-10000은 R0 인스턴스에 매핑됩니다.

2. 이 테이블을 유지해야 할 뿐만 아니라 각 개체 유형에 대한 테이블도 필요합니다. 예를 들어 현재 주문 정보를 저장하는 경우 다른 테이블을 만들어야 합니다. 관계 테이블.

3. 저장하려는 데이터의 키를 범위에 따라 나눌 수 없는 경우, 예를 들어 우리의 키는 uuid 집합이므로 범위 분할을 사용하기 어렵습니다.

해시 파티션

범위 파티션에 비해 해시 파티션의 확실한 장점은 키가 object_name: 형식이어야 하는 범위 파티셔닝과 달리 해시 파티션은 모든 형태의 키에 적합하다는 것입니다. 파티셔닝 방법도 매우 간단합니다.

id=hash(key)%N

여기서 id는 Redis 인스턴스의 번호를 나타냅니다. 이 공식은 먼저 키와 해시 함수를 기반으로 숫자 값을 계산한다고 설명합니다. crc32 함수로). 위의 예에 따르면 우리가 처리하려는 첫 번째 키는 user:1이고 해시(user:1)의 결과는 93024922입니다.

그러면 해시 결과는 모듈로입니다. 모듈로의 목적은 0에서 3 사이의 값을 계산하는 것이므로 이 값을 Redis 인스턴스 중 하나에 매핑할 수 있습니다. 예를 들어 93024922%4의 결과가 2라면 foobar가 R2에 저장된다는 것을 알 수 있습니다.

다양한 파티션 구현

파티셔닝은 Redis 소프트웨어 스택의 다양한 부분에서 구현될 수 있습니다. 다음을 살펴보겠습니다.

클라이언트 구현

클라이언트 구현은 키가 Redis 클라이언트에서 결정된다는 의미입니다. 해당 Redis 인스턴스에 저장하려면 아래 그림을 참조하세요.

프록시 구현

프록시 구현은 클라이언트가 프록시 서버에 요청을 보내고 프록시 서버가 Redis 프로토콜을 구현한다는 의미이므로 프록시는 서버는 프록시를 사용할 수 있습니다. 클라이언트는 Redis 서버와 통신합니다. 프록시 서버는 구성된 파티션 스키마를 통해 클라이언트의 요청을 올바른 Redis 인스턴스로 전달하고 피드백 메시지를 클라이언트에 반환합니다.

Redis 파티셔닝의 프록시 구현에 대한 도식 다이어그램은 다음과 같습니다.

쿼리 라우팅

쿼리 라우팅은 Redis 클러스터에서 구현한 Redis 파티셔닝 방법입니다.

쿼리 라우팅 프로세스 중에 우리는 쿼리 요청이 임의의 Redis 인스턴스로 전송되도록 무작위화할 수 있으며, 이 Redis 인스턴스는 요청을 올바른 Redis 인스턴스로 전달하는 역할을 담당합니다. Redis 클러스터는 쿼리 라우팅을 위해 클라이언트와 협력하는 하이브리드를 구현합니다.

Redis 파티션의 단점

Redis 파티셔닝은 지금까지는 훌륭했지만, Redis 파티셔닝에는 몇 가지 치명적인 단점이 있어 파티셔닝된 환경에서 일부 Redis 기능이 제대로 작동하지 않는 것을 살펴보겠습니다.

1. 예를 들어 일괄 작업할 키는 서로 다른 Redis 인스턴스에 매핑됩니다.

2. 다중 키 Redis 트랜잭션은 지원되지 않습니다.

3. 분할의 최소 세분성이 핵심이므로 키와 관련된 대규모 데이터 세트를 다른 인스턴스에 매핑할 수 없습니다.

4. 파티셔닝을 적용할 때 데이터 처리는 매우 복잡합니다. 예를 들어 여러 개의 rdb/aof 파일을 처리하고 백업을 위해 서로 다른 인스턴스에 분산된 파일을 수집해야 합니다.

5. 머신 추가 및 삭제는 매우 복잡합니다. 예를 들어 Redis 클러스터는 머신을 추가하거나 줄이는 데 필요한 거의 런타임 투명 재조정을 지원하지만 클라이언트 및 에이전트 분할과 같은 방법은 이 기능을 지원하지 않습니다.

영구 스토리지 또는 캐싱

데이터 영구 스토리지이든 캐시이든 Redis의 데이터 파티셔닝은 개념적으로 동일하지만 데이터 영구 스토리지에는 여전히 큰 제한이 있습니다.

Redis를 영구 저장소로 사용하는 경우 각 키는 항상 동일한 Redis 인스턴스에 매핑되어야 합니다. Redis를 캐시로 사용할 때 이 키에 대해 한 인스턴스를 사용할 수 없으면 이 키를 다른 인스턴스에 매핑할 수도 있습니다.

일관적인 해싱 구현을 사용하면 일반적으로 키가 매핑된 인스턴스를 사용할 수 없을 때 키를 다른 인스턴스에 매핑할 수 있습니다. 마찬가지로 머신이 추가되면 키의 일부가 새 머신에 매핑됩니다. 이해해야 할 두 가지 사항은 다음과 같습니다.

1. Redis를 캐시로 사용하는 경우 쉽게 추가하거나 머신 삭제, 일관된 해싱을 사용하는 것은 매우 간단합니다.

2. Redis를 (영구) 저장소로 사용하는 경우 고정된 키-인스턴스 매핑이 필요하므로 더 이상 머신을 유연하게 추가하거나 삭제할 수 없습니다. 그렇지 않으면 현재 Redis 클러스터에서 지원하는 머신을 추가하거나 삭제할 때 시스템이 재조정할 수 있어야 합니다.

Pre-Sharding

위의 소개를 통해 우리는 Redis 파티션을 캐시로만 사용하지 않는 이상 머신을 추가하거나 삭제하는 것이 매우 번거롭다는 것을 알고 있습니다.

그러나 일반적으로 Redis 용량 변경은 실제 애플리케이션에서 매우 일반적입니다. 예를 들어 오늘은 10개의 Redis 머신이 필요하고 내일은 50개의 머신이 필요할 수 있습니다.

Redis는 매우 가벼운 서비스(각 인스턴스는 1M만 차지)이므로 위 문제에 대한 간단한 해결책은 다음과 같습니다.

물리적 머신이더라도 여러 Redis 인스턴스를 열 수 있습니다. 인스턴스가 처음에 발생합니다. 32개 또는 64개의 인스턴스와 같은 일부 인스턴스를 작업 클러스터로 선택할 수 있습니다. 하나의 물리적 머신에 스토리지가 충분하지 않은 경우 일반 인스턴스를 두 번째 물리적 머신으로 이동하고 순서대로 페어링할 수 있습니다. 클러스터의 Redis 인스턴스 수가 변경되지 않도록 보장하고 머신 확장 목적을 달성할 수 있습니다.

Redis 인스턴스를 이동하는 방법은 무엇입니까? Redis 인스턴스를 독립 머신으로 이동해야 하는 경우 다음 단계를 통해 수행할 수 있습니다.

1. 새 물리적 머신에서 새 Redis 인스턴스를 시작합니다.

2. 새 실제 머신을 이동할 슬레이브 머신으로 사용합니다.

3. 클라이언트를 중지합니다.

4. 이동할 Redis 인스턴스의 IP 주소를 업데이트합니다.

5. SLAVEOF ON ONE 명령을 슬레이브 머신에 보냅니다.

6. 새 IP를 사용하여 Redis 클라이언트를 시작합니다.

7. 더 이상 사용하지 않는 Redis 인스턴스를 닫습니다.

더 많은 Redis 지식을 알고 싶다면 redis 입문 튜토리얼 칼럼을 주목해 주세요.

위 내용은 Redis 파티션 구현의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!