Redis를 클러스터링하는 방법

Redis 샤딩 클러스터

Redis 샤딩은 클라이언트 측 샤딩 기술입니다.

Redis Sharding은 Redis Cluster가 나오기 전에 업계에서 흔히 사용하던 Multi-Redis 인스턴스 클러스터링 방식이라고 할 수 있습니다. 주요 아이디어는 해시 알고리즘을 사용하여 Redis 데이터의 키를 해시하는 것입니다. 해시 함수를 통해 특정 키가 특정 Redis 노드에 매핑됩니다. (권장 학습: Redis 동영상 튜토리얼)

이러한 방식으로 클라이언트는 어떤 Redis 노드에서 데이터를 작업할지 알 수 있습니다. 이 작업은 클라이언트 측에서 수행된다는 점에 유의해야 합니다.

java redis 클라이언트 jedis는 이미 Redis 샤딩 기능, 즉 캐시 풀과 결합된 ShardedJedis 및 ShardedJedisPool을 지원합니다. Jedis의 Redis Sharding 구현에는 다음과 같은 특징이 있습니다.

1. 일관된 해싱 알고리즘을 사용합니다.

키와 노드 이름을 동시에 해시한 후 매핑 일치를 수행합니다. 일관된 해싱을 하는 주된 이유는 노드를 추가하거나 뺄 때 재매칭으로 인한 재해싱이 발생하지 않기 때문입니다. 일관된 해싱은 인접한 노드의 키 할당에만 영향을 미치며 그 영향은 작습니다. 일관된 해싱 알고리즘에 대한 자세한 소개는 http://blog.csdn.net/cywosp/article/details/23397179/

2를 참조하세요. 가상 노드

ShardedJedis는 각 Redis 노드를 이름에 따라 처리합니다. 해싱을 위해 160개의 가상 노드를 가상화합니다. 매핑 및 일치를 위해 가상 노드를 사용하면 Redis 노드를 추가하거나 줄일 때 인접한 노드만 영향을 받는 대신 Redis 노드 간에 키를 보다 균등하게 이동할 수 있습니다. 그림과 같이 Redis 노드 1은 NODE1-1과 NODE1-2로 가상화되어 해시링에 해시되어 있습니다. 이렇게 object1과 object2를 해싱하면 가장 가까운 노드인 NODE1-1과 NODE1-2가 선택되고, NODE1-1과 NODE1-2는 NODE 노드의 가상 노드, 즉 실제로 NODE에 저장된다. 마디.

가상 노드를 추가하면 균형이 보장됩니다. 즉, 한 머신이 더 많은 데이터를 저장하고 다른 머신은 더 적은 데이터를 저장하는 대신 각 Redis 머신이 유사한 데이터를 저장합니다.

3. ShardedJedis는 keyTagPattern 모드를 지원합니다.

샤딩을 위해 keyTag의 일부를 추출하여 키 이름을 합리적으로 지정하면 관련 키 그룹을 동일한 Redis 노드에 배치하여 노드 간 액세스를 피할 수 있습니다. 즉, 클라이언트는 동일한 Redis 노드에 동일한 규칙의 키 값을 지정하고 저장합니다.

노드를 추가하거나 뺄 때?

Redis 샤딩은 클라이언트측 샤딩 방식을 채택하고 있으며, 서버측 Redis는 여전히 상대적으로 독립적인 Redis 인스턴스 노드입니다. 동시에 추가 중간 처리 구성 요소를 추가할 필요가 없습니다. 이는 매우 가볍고 유연한 Redis 다중 인스턴스 클러스터 솔루션입니다.

물론 이 가볍고 유연한 접근 방식은 클러스터의 다른 기능을 손상시켜야 합니다. 예를 들어 확장 시 Redis 노드를 추가하려는 경우 일관된 해싱을 사용하더라도 다른 Redis 노드에 다른 키가 배포됩니다.

확장해야 할 경우 샤드 목록에 머신을 추가하세요. 이때 클라이언트는 키를 기반으로 계산하여 원래 키와 다른 컴퓨터에 랜딩합니다. 이런 식으로 특정 값을 얻으려면 얻지 못할 수도 있습니다.

이 상황에서 일반적인 접근 방식은 데이터를 검색할 수 없는 후 백엔드 데이터베이스에서 직접 다시 로드하는 것입니다. 그러나 때로는 캐시 계층을 뚫고 데이터베이스 계층에 직접 액세스하면 시스템에 많은 부담이 가해집니다. 입장.

Redis의 저자는 사전 샤딩이라는 방법을 제시했습니다.

원칙은 각 물리적 머신에서 서로 다른 포트를 사용하여 여러 Redis 인스턴스를 실행하는 것입니다. 3개의 물리적 머신이 있고 각 물리적 머신이 3개의 Redis 인스턴스를 실행한다면 샤딩에는 실제로 9개의 Redis 인스턴스가 있습니다. 목록에서 용량을 확장해야 하는 경우 단계는 다음과 같습니다.

1. Redis 서버는 (slaveof) A에 속합니다. 샤드 목록의 특정 Redis-Server(RedisA라고 가정).

3. 마스터-슬레이브 복제(Replication)가 완료된 후 클라이언트 샤드 목록의 RedisA의 IP 및 포트를 새로운 물리적 머신의 Redis-Server의 IP 및 포트로 변경합니다.

4. RedisA 중지

이는 특정 Redis-Server를 새 시스템으로 전송하는 것과 같습니다. 그러나 여전히 Redis 자체의 복제 기능에 크게 의존하고 있으므로 기본 데이터베이스 스냅샷 데이터 파일이 너무 크면 복제 프로세스에 시간이 오래 걸리고 기본 Redis에도 부담을 주게 되므로 선택하는 것이 가장 좋습니다. 이 분할 프로세스에 대한 비즈니스 액세스는 피크 시간 동안 수행됩니다.

노드 장애 시

키 값 손실 문제를 일으키는 것은 Redis 노드의 추가나 삭제뿐만 아니라 Redis 노드의 갑작스러운 다운타임이 더 큰 장애물입니다.

Redis의 성능에 영향을 주지 않으려면 AOF 및 RDB 파일 저장 기능을 활성화하지 않도록 하십시오. 따라서 활성 Redis가 다운되면 대기 Redis는 활성 및 대기 모드를 구축해야 합니다. 백업하면 데이터가 손실되지 않습니다.

샤딩은 다음과 같이 발전했습니다.

이러한 방식으로 우리의 아키텍처 모델은 기본 Redis와 백업 Redis를 포함하는 Redis 노드 슬라이스가 됩니다. 자동 장애 조치를 통해 가용성이 높아집니다.

Redis Sentinel

은 활성 및 백업 모드에서 Redis 모니터링, 장애 조치 및 기타 기능을 제공하여 높은 시스템 가용성을 달성합니다.

읽기-쓰기 분리

높은 접속 시간에서는 Sharding을 사용하더라도 단일 노드는 여전히 많은 접속 압력을 받습니다. 우리는 더 세분화될 필요가 있습니다.

일반적으로 읽기는 쓰기보다 몇 배 빠른 경우가 많습니다. 이때 읽기와 쓰기를 분리할 수 있으며 읽기는 더 많은 인스턴스를 제공합니다. 마스터-슬레이브 모드는 읽기와 쓰기의 분리를 실현하는 데 사용됩니다. 마스터는 쓰기를 담당하고 슬레이브는 읽기만 담당합니다. 동시에 하나의 마스터가 여러 슬레이브를 연결할 수 있습니다. Redis Sentinel 모니터링에서는 노드 오류에 대한 자동 모니터링도 보장할 수 있습니다.

Redis 관련 기술 기사를 더 보려면 Redis 데이터베이스 사용 튜토리얼 열을 방문하여 알아보세요!

위 내용은 Redis를 클러스터링하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!