Redis 파티션 구현 원리 소개

Redis 파티셔닝은 간단히 말해서 데이터를 여러 Redis 인스턴스에 배포하는 것이므로 각 Redis 인스턴스에 저장된 콘텐츠는 전체 콘텐츠의 하위 집합일 뿐입니다. 의 .

추천: redis 입문 튜토리얼

파티션이 필요한 이유는 무엇인가요? 분할을 하게 된 동기는 무엇이었나요? 일반적으로 Redis 파티셔닝의 이점은 다음과 같은 두 가지 측면을 포함합니다:

1. 단일 시스템 Redis의 네트워크 I/O 기능 및 컴퓨팅 리소스는 제한적이며 요청은 다음으로 분산됩니다. 여러 머신의 컴퓨팅 성능과 네트워크 대역폭을 최대한 활용하여 Redis의 전반적인 서비스 기능을 향상시킵니다.

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

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

Redis 파티션 기본

실제 애플리케이션에서 파티셔닝을 위한 구체적인 전략이 많이 있습니다. 예를 들어 이미 4개의 파티션 세트가 있다고 가정합니다. Redis 인스턴스는 각각 R0, R1, R2 및 R3입니다. 또한 user:1, user:2 등과 같이 사용자를 나타내는 키 배치가 있습니다. 은 사용자 ID를 나타냅니다. 우리가 해야 할 일은 이러한 키를 4개의 서로 다른 Redis 인스턴스에 분산 저장하는 것입니다. 어떻게 하나요? 가장 간단한 방법은 범위 분할(range partitioning)입니다. 범위 분할을 기반으로 수행하는 방법을 살펴보겠습니다.

범위 파티셔닝

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

사용자 ID가 0~10000인 사용자 데이터를 R0 인스턴스에 매핑하고, 사용자 ID가 10001~20000인 개체를 R1 인스턴스에 매핑하는 등의 작업을 수행할 수 있습니다.

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

사용자를 저장하는 데 사용되는 테이블이 필요합니다. 매핑 관계 예를 들어 사용자 ID 0-10000은 R0 인스턴스에 매핑됩니다.

이 테이블을 유지 관리해야 할 뿐만 아니라 각 개체 유형에 대한 이러한 테이블도 필요합니다. 예를 들어 현재 사용자 정보를 저장하고 있다면 또 다른 작업을 수행합니다. 매핑 테이블을 생성해야 합니다.

저장하려는 데이터의 키를 범위에 따라 나눌 수 없다면 어떻게 될까요? 예를 들어 우리의 키는 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와 Memcached 프록시 Twemoroxy는 모두 프록시 파티셔닝을 구현합니다.

쿼리 라우팅

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

#🎜🎜 #

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

Redis 파티션의 단점

Redis 파티션은 아직까지는 훌륭하지만 Redis 파티션에는 치명적인 단점이 있어서 결과적으로 , 일부 Redis 기능은 분할된 환경에서 제대로 작동하지 않습니다. 살펴보겠습니다.

다중 키 작업은 지원되지 않습니다. 예를 들어, 일괄 작업할 키는 Redis에서 서로 다른 키로 매핑됩니다. 사례.

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

파티셔닝의 최소 세분성이 핵심이므로 하나의 키와 연결된 매우 큰 데이터 세트를 다른 인스턴스에 매핑할 수 없습니다.

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

머신 추가 및 삭제는 매우 복잡합니다. 예를 들어 Redis 클러스터는 머신을 추가하거나 줄이기 위해 수행해야 하는 거의 런타임 투명 재조정을 지원합니다. 그러나 클라이언트 및 프록시 파티셔닝과 같은 방법은 지원되지 않습니다. 이 기능.

영구 저장 또는 캐싱

데이터 분할은 데이터 영구 저장이든 캐싱이든 개념적으로 Redis와 동일하지만 동일하지만 영구 데이터 저장에는 여전히 큰 제한이 있습니다. Redis를 영구 저장소로 사용하는 경우 각 키는 항상 동일한 Redis 인스턴스에 매핑되어야 합니다. Redis를 캐시로 사용할 때 이 키에 대해 한 인스턴스를 사용할 수 없으면 이 키를 다른 인스턴스에 매핑할 수도 있습니다.

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

1. Redis가 캐시로 사용되는 경우. 기계를 쉽게 추가하거나 제거해야 하기 때문에 일관된 해싱을 사용하는 것은 매우 간단합니다.

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

Pre-Sharding

위의 소개를 통해 Redis만 사용하지 않는 한 Redis 파티션 적용에 문제가 있음을 알고 있습니다. 그렇지 않으면 시스템을 추가하거나 삭제하는 것이 매우 번거로울 것입니다.

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

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

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

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

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

2. 새 물리적 머신을 이동할 슬레이브 머신으로 사용합니다.

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

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

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

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

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

Summary

이 글에서는 Redis 파티셔닝의 개념 이해를 바탕으로 Redis 파티셔닝의 몇 가지 일반적인 구현 방법과 원칙을 소개합니다. 마지막으로 구현 시 발생하는 문제를 바탕으로 설명합니다. 문제는 사전 샤딩 솔루션을 도입합니다.

관련 추천:

mysql 비디오 튜토리얼: https://www.php.cn/course/list/51.html#🎜 🎜#

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