Redis에서 클러스터링을 구현하는 방법

1. 마스터-슬레이브 복제

마스터-슬레이브 복제의 원리:

• 슬레이브 서버는 마스터 서버에 연결하고

• 마스터 서버가 수신한 후 SYNC 이름에 따라 BGSAVE 명령 실행이 시작됩니다. RDB 파일을 생성하고 버퍼를 사용하여 이후 실행되는 모든 쓰기 명령을 기록합니다.

• 마스터 서버 BGSAVE가 실행된 후 모든 슬레이브 서버에 스냅샷 파일을 전송하고 계속해서 기록합니다.

• 스냅샷 파일을 수신한 후 슬레이브 서버는 이전 데이터를 모두 삭제하고 수신된 스냅샷을 로드합니다.

• 마스터 서버 스냅샷이 전송된 후 쓰기 명령을 보내기 시작합니다.

• 슬레이브 서버는 스냅샷 로드를 완료하고, 명령 요청 수신을 시작하고, 마스터 서버 버퍼에서 쓰기 명령을 실행합니다. (슬레이브 서버 초기화 완료)

• 마스터 서버는 쓰기 명령을 실행할 때마다 슬레이브 서버에 동일한 쓰기 명령을 보냅니다. 서버로부터 받은 쓰기 명령을 받아 실행합니다. (슬레이브 서버 초기화가 완료된 후 동작)

마스터-슬레이브 복제의 장점 및 단점:

장점:

• 마스터-슬레이브 복제를 지원합니다. 호스트는 슬레이브 서버인 마스터의 읽기 작업 부담을 줄이기 위해 자동으로 데이터를 슬레이브 시스템에 동기화하고 읽기 및 쓰기를 분리합니다. 읽기 전용 작업 서비스를 클라이언트에 제공할 수 있습니다. 쓰기 서비스는 여전히 마스터에 의해 완료되어야 합니다.

  슬레이브는 또한 다른 슬레이브의 연결 및 동기화 요청을 수락할 수 있으므로 마스터의 동기화 부담을 효과적으로 줄일 수 있습니다.

• 마스터 서버는 비차단 방식으로 슬레이브에게 서비스를 제공합니다. 따라서 마스터-슬레이브 동기화 중에 클라이언트는 여전히 쿼리나 수정 요청을 제출할 수 있습니다.

• Slave Server는 또한 비차단 방식으로 데이터 동기화를 완료합니다. 동기화 중에 클라이언트가 쿼리 요청을 제출하면 Redis는 동기화 전에 데이터를 반환합니다
단점:

Redis에는 자동 내결함성 및 복구 기능이 없으며 호스트 및 슬레이브 시스템의 가동 중지 시간이 있습니다. 프런트 엔드 부분에서 읽기 및 쓰기 요청이 실패했으며 시스템이 다시 시작될 때까지 기다리거나 복구하려면 프런트 엔드 IP를 수동으로 전환해야 합니다.

호스트가 다운되었습니다. 다운타임 이전에 일부 데이터를 슬레이브에 동기화할 수 없습니다. IP를 전환하면 데이터 불일치가 발생하여 시스템 가용성이 저하됩니다.

• Redis는 온라인 확장을 지원하기 어렵습니다. 클러스터 용량이 상한에 도달하면 온라인 확장이 매우 복잡해집니다.
2.
• 센티넬 모드

마스터 서버가 서비스를 중단하는 경우 슬레이브 서버를 마스터 서버로 업그레이드하여 계속 서비스를 제공할 수 있지만 이 과정에는 수동 작업이 필요합니다. 이를 위해 Redis 2.8은 자동화된 시스템 모니터링 및 오류 복구 기능을 구현하는 감시 도구를 제공합니다.

Sentinel의 역할은 Redis 시스템의 실행 상태를 모니터링하는 것입니다. 그 기능은 다음 두 가지를 포함합니다.

(1) 마스터 서버와 슬레이브 서버가 정상적으로 동작하는지 모니터링합니다.
(2) 메인 서버에 장애가 발생하면 슬레이브 서버에서 메인 서버로 자동 전환됩니다.

센티널 작동 방식:

• 각 Sentinel 프로세스는 초당 한 번씩 시작됩니다. 자주 PING 명령을 다음으로 보냅니다. 전체 클러스터의 마스터 서버, 슬레이브 서버 및 기타 Sentinel 프로세스.

• PING 명령에 대한 마지막 유효한 응답 이후의 시간이 down-after-milliseconds 옵션에 지정된 값을 초과하는 경우 이 인스턴스는 Sentinel에서 전송됩니다( Sentinel ) 프로세스가 주관적 오프라인(SDOWN)으로 표시됨

• 마스터 서버가 주관적으로 오프라인(SDOWN)으로 표시된 경우 마스터 서버가 모니터링되고 있음 모든 Sentinel 프로세스는 한 번 확인해야 함 초당 마스터 서버가 주관적 오프라인 상태에 진입한 비율

• Sentinel 프로세스 수가 충분한 경우(구성에 지정된 값 이상) 파일) 지정된 시간 내에 마스터 서버가 주관적 오프라인 상태(SDOWN)에 진입한 것이 확인되면 마스터 서버는 객관적 오프라인(ODOWN)으로 표시됩니다.

  #🎜🎜 #
# 🎜🎜#일반적인 상황에서 각 Sentinel 프로세스는 10초마다 한 번씩 클러스터의 모든 마스터 서버와 슬레이브 서버에 INFO 명령을 보냅니다.
센티넬(Sentinel) 프로세스에 의해 마스터 메인 서버가 객관적으로 오프라인(ODOWN)으로 표시되면 센티넬(Sentinel)이 오프라인 마스터 메인 서버를 모두 처리합니다. 슬레이브가 서버에서 INFO 명령을 보내는 빈도가 10초에 한 번에서 1초에 한 번으로 변경됩니다.
마스터 서버가 오프라인이 되는 데 동의할 만큼 센티넬 프로세스가 충분하지 않은 경우 마스터 서버의 객관적인 오프라인 상태가 제거됩니다. 마스터 서버가 Sentinel 프로세스에 다시 PING 명령을 보내고 유효한 응답을 반환하면 마스터 서버의 주관적인 오프라인 상태가 제거됩니다.

센트리 모드의 장점과 단점
장점:

#🎜 🎜 #

센트리 모드는 마스터-슬레이브 모드를 기반으로 하며, 센트리 모드는 마스터-슬레이브의 장점을 모두 가지고 있습니다.

• 마스터와 슬레이브를 자동으로 전환할 수 있어 시스템이 더욱 견고하고 유용해집니다.
단점:
Redis는 온라인 확장을 지원하기 어렵습니다. 클러스터 용량이 상한에 도달하면 온라인 확장이 복잡해집니다.

3.Redis-Clustercluster

redis의 센티넬 모드는 기본적으로 구현 가능 고가용성, 읽기와 쓰기의 분리, 그러나 이 모드에서는 각 Redis 서버가 동일한 데이터를 저장하므로 메모리 낭비이므로 redis3.0에 클러스터 모드를 추가하여 Redis의 분산 저장을 구현합니다. Redis 서버는 동일한 데이터를 저장하므로 메모리 낭비입니다. Redis 노드마다 다른 내용이 저장됩니다.

Redis-Cluster는 Centerless 구조를 채택하고 있으며 그 특징은 다음과 같습니다.

• 모든 Redis 노드는 서로 연결되어 있습니다(PING-PONG). 메커니즘), 전송 속도와 대역폭을 최적화하기 위해 내부적으로 바이너리 프로토콜이 사용됩니다.

• 노드 장애는 클러스터 노드 중 절반 이상이 장애를 감지한 경우에만 적용됩니다.

• 클라이언트는 중간 프록시 계층 없이 Redis 노드에 직접 연결됩니다. 클라이언트는 클러스터의 모든 노드에 연결할 필요가 없습니다. 클러스터에서 사용 가능한 노드에 연결합니다.

작업 방법:

Redis의 모든 노드에는 두 가지가 있습니다. 하나는 슬롯입니다. , 값 범위는 0-16383입니다. 또 다른 하나는 클러스터 관리 플러그인으로 이해될 수 있는 클러스터입니다. 액세스 키가 도착하면 redis는 crc16 알고리즘을 기반으로 결과를 얻은 다음 나머지 결과를 16384로 계산하여 각 키가 0-16383 사이의 해시 슬롯에 해당하도록 합니다. 이 값은 다음과 같이 사용됩니다. 해당 슬롯에 해당하는 노드를 찾은 다음 자동으로 해당 노드로 직접 점프하여 액세스 작업을 수행합니다.

고가용성을 보장하기 위해 redis-cluster 클러스터는 마스터-슬레이브 모드를 도입합니다. 하나의 마스터 노드가 하나 이상의 슬레이브 노드에 해당하면 슬레이브 노드가 종료됩니다. 활성화되었습니다. 다른 마스터 노드가 마스터 노드 A를 핑할 때, 절반 이상의 마스터 노드와 A 간의 통신이 시간 초과되면 마스터 노드 A가 다운된 것으로 간주됩니다. 마스터 노드 A와 슬레이브 노드 A1이 모두 다운되면 클러스터는 더 이상 서비스를 제공할 수 없습니다.

더 많은 Redis 관련 기술 기사를 보려면 Redis 튜토리얼#🎜🎜을 방문하세요. # 학습 칼럼!

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