Redis 클러스터 솔루션이란 무엇입니까?

Redis의 데이터 양은 나날이 증가하고 있으며, 이를 사용하는 기업도 점점 늘어나고 있습니다. 이는 캐싱에만 사용되는 것이 아니라, 클러스터의 발전도 필연적으로 촉진하게 됩니다. 현재 업계에서는 다음과 같은 클러스터 아키텍처가 일반적으로 사용됩니다. 대부분은 단일 인스턴스 메모리 증가로 인해 발생하는 일련의 문제를 해결하기 위해 샤딩 기술을 사용합니다.

이 문서에서는 다섯 가지 솔루션을 간략하게 소개합니다.

공식 클러스터 솔루션

twemproxy 프록시 솔루션

Sentinel 모드

codis

클라이언트 샤딩

공식 클러스터 솔루션

시작 중 redis 버전 3.0부터 redis-cluster 클러스터가 지원됩니다. redis-cluster는 센터리스 구조를 채택하며 각 노드는 데이터와 전체 클러스터 상태를 저장하고 각 노드는 다른 노드와 연결됩니다. redis-cluster는 서버 측 샤딩 기술입니다.

redis-cluster 아키텍처 다이어그램

redis-cluster 기능:

각 노드는 클러스터 버스라고 하는 n-1 노드와 통신합니다. 외부 서비스 포트 번호에 10000을 더한 특수 포트 번호를 사용합니다. 따라서 이 클러스터의 각 노드 정보를 유지해야 합니다. 그렇지 않으면 전체 클러스터를 사용할 수 없게 되며 전송 속도와 대역폭을 최적화하기 위해 내부적으로 특수 바이너리 프로토콜이 사용됩니다.

redis-cluster는 모든 물리적 노드를 [0,16383] 슬롯(slot)에 매핑하고, 클러스터는 node--slot--값을 유지하는 역할을 담당합니다.

클러스터는 미리 16384개의 버킷으로 나누어져 있습니다. Redis 클러스터에 데이터를 삽입해야 할 경우 CRC16(KEY) mod 16384 값을 기준으로 어떤 버킷에 키를 배치해야 하는지 결정됩니다.

클라이언트는 Redis 노드에 직접 연결됩니다. 클러스터의 모든 노드에 연결할 필요는 없으며 클러스터에서 사용 가능한 노드에 연결하기만 하면 됩니다.

redis-trib.rb 스크립트(rub 언어)는 자동 노드 추가, 슬롯 계획, 데이터 마이그레이션 및 일련의 작업과 같은 클러스터 관리 도구입니다.

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

전체 클러스터는 전체로 간주됩니다. 클라이언트는 작업을 위해 모든 노드에 연결할 수 있습니다. 클라이언트가 작동하는 키가 노드에 할당되지 않은 경우 redis는 올바른 노드를 가리키도록 조정 명령을 반환합니다.

클러스터의 접근성을 높이기 위해 공식적으로 권장되는 솔루션은 노드를 마스터-슬레이브 구조, 즉 마스터 노드와 n개의 슬레이브 노드로 구성하는 것입니다. 마스터 노드에 장애가 발생하면 redis 클러스터는 선택 알고리즘에 따라 슬레이브 노드 중 하나를 선택하여 마스터 노드로 승격시키고 전체 클러스터는 계속해서 외부 세계에 서비스를 제공합니다.

twemproxy 프록시 솔루션

twemproxy 프록시 아키텍처 다이어그램:

Redis 프록시 미들웨어 twemproxy는 샤딩을 위해 미들웨어를 사용하는 기술입니다. Twemproxy는 클라이언트와 서버 사이에 있으며 클라이언트의 요청(샤딩)을 처리한 다음 이를 백엔드의 실제 Redis 서버로 전달합니다. 즉, 클라이언트는 redis 서버에 직접 접근하지 않고, twemproxy 프록시 미들웨어를 통해 간접적으로 접근합니다. 백엔드 서버에 대한 클라이언트 직접 연결 수를 줄이고 서버 클러스터의 수평 확장을 지원합니다.

twemproxy 미들웨어의 내부 처리는 상태 비저장이며 자체적으로 쉽게 클러스터링될 수 있어 단일 스트레스나 실패 지점을 방지합니다.

twemproxy는 nutcracker라고도 알려져 있으며 Twitter 시스템의 redis 및 memcached 클러스터의 경량 프록시에서 유래되었습니다.

Github 소스코드 주소 (https://github.com/twitter/twemproxy)

위의 아키텍처 다이어그램에서 볼 수 있듯이 twemproxy는 단일 포인트이므로 쉽게 많은 부담을 줄 수 있으므로 일반적으로 twemproxy 고가용성을 구현하기 위해 keepalived와 결합됩니다. 이때 일반적으로 하나의 twemproxy만 작동하고 다른 하나는 대기 상태입니다. 하나가 전화를 끊으면 VIP가 자동으로 드리프트되고 대기 시스템이 작업을 대신합니다. Keepalived 사용에 관한 정보는 온라인에서 확인할 수 있습니다.

Sentinel 모드

Sentinel Sentinel

Sentinel(Sentinel)은 Redis를 위한 고가용성 솔루션입니다. 하나 이상의 Sentinel 인스턴스로 구성된 Sentinel 시스템은 원하는 수의 마스터 서버와 이러한 마스터 서버 아래의 모든 슬레이브 서버를 모니터링할 수 있습니다. 모니터링되는 마스터 서버가 오프라인이 되면 오프라인 마스터 서버 아래의 슬레이브 서버가 자동으로 새 마스터 서버로 업그레이드됩니다.

예:

Server1이 오프라인 상태가 된 후:

Server2를 새 기본 서버로 업그레이드:

Sentinel 작동 방식

각 Sentinel은 서버에 초당 한 번씩 보고합니다. 슬레이브 및 기타 Sentinel 인스턴스는 PING 명령 전송에 대해 알고 있습니다.

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

마스터가 주관적 오프라인 상태로 표시되면 마스터를 모니터링하는 모든 센티널은 마스터가 실제로 주관적 오프라인 상태에 진입했는지 1초에 한 번씩 확인해야 합니다.

충분한 수의 센티널(구성 파일에 지정된 값 이상)이 마스터가 지정된 시간 범위 내에 실제로 주관적인 오프라인 상태에 진입했음을 확인하면 마스터는 객관적으로 오프라인으로 표시됩니다.

일반적인 상황에서 각 센티널은 자신이 알고 있는 모든 마스터와 슬레이브에게 10초마다 한 번씩 INFO 명령을 보냅니다.

마스터가 Sentinel에 의해 객관적으로 오프라인으로 표시되면 Sentinel이 오프라인 마스터의 모든 슬레이브에 INFO 명령을 보내는 빈도가 10초에 한 번에서 1초에 한 번으로 변경됩니다.

마스터가 오프라인 상태임을 동의할 만큼 센티넬이 충분하지 않은 경우, 마스터의 목표 오프라인 상태가 제거됩니다. 마스터가 Sentinel의 PING 명령에 유효한 값을 다시 반환하면 마스터의 주관적인 오프라인 상태가 제거됩니다.

codis

codis는 Wandoujia에서 오픈소스로 제공하는 분산형 Redis 솔루션입니다. 상위 계층 애플리케이션의 경우 codis 프록시에 연결하는 것과 기본 Redis 서버에 연결하는 것 사이에는 뚜렷한 차이가 없습니다. redis를 사용하면 codis의 최하위 계층이 요청 전달, 논스톱 데이터 마이그레이션 및 기타 작업을 처리합니다. 이후의 모든 작업은 이전 클라이언트에 투명하게 표시됩니다. 무한한 기억.

클라이언트 측 샤딩

파티셔닝 논리는 클라이언트에서 구현되며 클라이언트는 요청할 노드를 선택합니다. 이 솔루션은 일반적으로 사용자가 클라이언트 동작을 완전히 제어할 수 있는 시나리오에 적합합니다.

요약: 최상의 솔루션은 없고 가장 적합한 솔루션만 있습니다.

더 많은 Redis 관련 기술 기사를 보려면 Redis Tutorial 칼럼을 방문하여 알아보세요!

위 내용은 Redis 클러스터 솔루션이란 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!