Redis 서비스 아키텍처 분석 및 구축을 종합적으로 마스터합니다.

메모리 기반 Redis는 다양한 웹 개발 비즈니스에서 가장 일반적으로 사용되는 키-값 데이터베이스여야 합니다. 우리는 비즈니스에서 사용자 로그인 상태(세션 저장)를 저장하고 일부 핫 데이터 쿼리 속도를 높이기 위해 자주 사용합니다. mysql 속도면에서는 몇 배로 속도가 향상되었으며, 간단한 메시지 큐(LPUSH 및 BRPOP), 구독 퍼블리싱(PUB/SUB) 시스템 등을 만들었습니다. 대규모 인터넷 회사에는 일반적으로 Redis 스토리지를 다양한 비즈니스 통화에 대한 기본 서비스로 제공하는 전담 팀이 있습니다.

그러나 기본 서비스 제공업체는 발신자로부터 다음과 같은 질문을 받게 됩니다. 귀하의 서비스 가용성이 높습니까? 귀하의 서비스에 빈번한 문제가 발생하여 내 사업이 어려움을 겪지 않도록 하는 것이 가장 좋습니다. 최근에는 내 프로젝트에 작은 "고가용성" Redis 서비스도 구축했습니다.

먼저 Redis 서비스의 고가용성을 정의해야 합니다. 즉, 다양한 비정상적인 상황에서도 정상적으로 서비스를 제공할 수 있다는 것입니다. 또는 좀 더 여유를 갖고 이상이 발생한 경우 짧은 시간 내에 정상적인 서비스를 복원할 수 있습니다. 소위 예외에는 최소한 다음 가능성이 포함되어야 합니다.

[예외 1] 특정 노드 서버의 프로세스가 갑자기 다운되었습니다(예: 개발자가 비활성화되어 서버의 redis-server 프로세스가 종료됨)

【예외 2】특정 노드 서버가 다운되었습니다. 이는 해당 노드의 모든 프로세스가 중지되는 것과 같습니다. (예: 운영 및 유지 관리 장애로 인해 서버 전원이 차단됩니다. 예를 들어 일부 오래된 시스템에 하드웨어 오류가 발생함)

【 예외 3】 두 노드 서버 사이의 통신이 중단되는 경우(예: 장애가 있는 손을 가진 임시 직원이 두 컴퓨터실 간의 통신에 사용되는 광케이블을 파낸 경우)

실제로 위의 예외 중 어느 하나라도 가능성은 낮습니다. 고가용성을 달성하기 위한 기본 지침 아이디어는 여러 개의 낮은 확률 이벤트가 동시에 발생할 확률은 무시할 수 있다는 것입니다. 단기간 동안 단일 장애 지점을 허용하도록 시스템을 설계하는 한 고가용성을 달성할 수 있습니다.

인터넷에는 Keepalived, Codis, Twemproxy, Redis Sentinel 등 고가용성 Redis 서비스를 구축하기 위한 많은 솔루션이 있습니다. 그 중 Codis와 Twemproxy는 대규모 Redis 클러스터에서 주로 사용되며 Redis가 Redis Sentinel을 공식 출시하기 전에는 Twitter와 Wandoujia에서 제공한 오픈소스 솔루션이기도 했습니다. 내 사업의 데이터 양이 많지 않기 때문에 클러스터 서비스를 제공하는 것은 시스템 낭비입니다. 마지막으로 Keepalived와 Redis Sentinel 중 하나를 선택했고, 공식 솔루션인 Redis Sentinel을 선택했습니다.

Redis Sentinel은 Redis Server 서비스의 정상 여부를 모니터링하는 프로세스로 이해될 수 있으며, 이상이 감지되면 백업(슬레이브) Redis Server가 자동으로 활성화되어 외부 사용자가 내부의 이상을 인지하지 못하도록 할 수 있습니다. 레디스 서비스. 우리는 최소한의 고가용성 Redis 서비스를 구축하기 위해 단순한 것부터 복잡한 것까지의 단계를 따릅니다.

옵션 1: Sentinel이 없는 Redis 서버의 독립 실행형 버전

보통 우리는 개인 웹사이트를 구축하거나 일상적인 개발을 할 때 Redis Server의 단일 인스턴스를 설정합니다. 호출자는 Redis 서비스에 직접 연결할 수 있으며 클라이언트와 Redis 자체도 동일한 서버에 있습니다. 이 조합은 개인 학습 및 오락에만 적합합니다. 결국 이 구성에는 해결할 수 없는 단일 실패 지점이 항상 존재합니다. Redis 서비스 프로세스가 중단되거나 서버 1이 종료되면 서비스를 사용할 수 없습니다. Redis 데이터 지속성이 구성되지 않으면 Redis에 이미 저장된 데이터도 손실됩니다.

옵션 2: 마스터-슬레이브 동기화 Redis 서버, 단일 인스턴스 Sentinel

고가용성을 달성하고 솔루션 1에 설명된 단일 실패 지점 문제를 해결하려면 백업을 추가해야 합니다. 즉, 두 서버 각각에서 Redis Server 프로세스를 시작합니다. 일반적으로 마스터는 서비스를 제공하고 슬레이브는 동기화 및 백업만 담당합니다. 동시에 두 개의 Redis 서버 인스턴스의 가용성을 모니터링하기 위해 추가 Sentinel 프로세스가 시작되어 마스터가 중단되면 슬레이브가 제때 마스터 역할로 승격되어 계속 서비스를 제공할 수 있습니다. Redis 서버의 이는 고가용성 서비스 설계 기반, 즉 단일 장애 지점 자체는 작은 확률의 사건이며 동시에 여러 단일 지점 장애(즉, 마스터와 슬레이브가 동시에 끊김)를 기반으로 합니다. 시간)은 (기본적으로) 불가능한 사건으로 간주될 수 있습니다.

Redis 서비스 호출자에게 지금 연결해야 할 것은 Redis Server가 아닌 Redis Sentinel 서비스입니다. 일반적인 호출 과정은 클라이언트가 먼저 Redis Sentinel에 접속하여 현재 Redis Server에서 어느 서비스가 Master이고 어느 서비스가 Slave인지 물어본 후 해당 Redis Server에 접속하여 동작시키는 것이다. 물론 현재 타사 라이브러리는 일반적으로 이 호출 프로세스를 구현했으며 더 이상 수동으로 구현할 필요가 없습니다(예: Nodejs의 ioredis, PHP의 predis, Golang의 go-redis/redis, JAVA의 jedis 등).

그러나 Redis 서버 서비스의 마스터-슬레이브 전환을 구현한 후 새로운 문제가 발생했습니다. 즉, Redis Sentinel 자체도 단일 지점 서비스이므로 Sentinel 프로세스가 중단되면 클라이언트가 이를 수행할 수 없습니다. 센티넬에 접속하세요. 따라서 옵션 2의 구성에서는 고가용성을 달성할 수 없습니다.

옵션 3: 마스터-슬레이브 동기화 Redis 서버, 듀얼 인스턴스 Sentinel

솔루션 2의 문제를 해결하기 위해 추가 Redis Sentinel 프로세스도 시작하고 두 개의 Sentinel 프로세스도 시작합니다. 동시에 고객에게 서비스를 제공하십시오. 단말기는 서비스 검색 기능을 제공합니다. 클라이언트의 경우 Redis Sentinel 서비스에 연결하여 현재 Redis Server 인스턴스에 대한 기본 정보를 얻을 수 있습니다. 일반적으로 클라이언트 측에서 여러 Redis Sentinel 링크 주소를 구성합니다. 클라이언트가 특정 주소를 연결할 수 없다는 사실을 발견하면 다른 Sentinel 인스턴스에 연결을 시도합니다. 물론 이를 수동으로 구현할 필요는 없습니다. 다양한 개발 언어 더 널리 사용되는 Redis 연결 라이브러리는 이 기능을 실현하는 데 도움이 되었습니다. 우리는 Redis Sentinel 중 하나가 전화를 끊더라도 서비스를 제공할 수 있는 또 다른 Sentinel이 있을 것으로 기대합니다.

그러나 비전은 아름답지만 현실은 매우 잔인합니다. 이러한 아키텍처에서는 Redis 서비스의 고가용성을 달성하는 것이 여전히 불가능합니다. 옵션 3의 회로도에서 빨간색 선은 두 서버 간의 통신이며, 우리가 예상한 비정상적인 시나리오([이상 2])는 특정 서버가 전체적으로 다운되는 것입니다. 현재는 Redis Sentinel과 슬레이브 Redis Server만 서버 2에서 처리합니다. 이때 Sentinel은 서비스를 계속하기 위해 실제로 나머지 슬레이브를 마스터로 전환하지 않으며, 이로 인해 Redis 서비스를 사용할 수 없게 됩니다. 왜냐하면 Redis의 설정은 Sentinel 프로세스의 50% 이상이 연결 가능하고 새로운 마스터에 투표하면 마스터-슬레이브 전환이 실제로 발생합니다. 이 예에서는 두 개의 Sentinel 중 하나만 연결할 수 있으며 이는 50%에 해당하며 마스터-슬레이브 전환이 가능한 시나리오는 아닙니다.

Redis에 왜 이렇게 50% 설정이 있는지 궁금해하실 수도 있습니다. Sentinel 연결의 50% 이하를 허용한다고 가정하면 마스터-슬레이브 전환도 수행될 수 있습니다. [예외 3]을 상상해 보세요. 즉, 서버 1과 서버 2 사이의 네트워크가 중단되었지만 서버 자체는 작동 중입니다. 아래 그림과 같이

사실 서버 2의 경우 서버 1이 직접 다운되면 서버 1이 네트워크에 연결할 수 없는 것과 같은 효과가 발생합니다. 의사소통이 이루어질 수 있습니다. 네트워크가 중단되면 서버 2의 Sentinel이 슬레이브를 마스터로 전환하도록 허용하며 그 결과 이제 외부 서비스를 제공할 수 있는 두 개의 Redis 서버가 있다고 가정합니다. 클라이언트가 수행하는 모든 추가, 삭제 및 수정 작업은 서버 1의 Redis 또는 서버 2의 Redis(클라이언트가 연결된 Sentinel에 따라 다름)에 수행되어 데이터 혼란을 일으킬 수 있습니다. 나중에 Server 1과 Server 2 사이의 네트워크가 복원되더라도 데이터를 통합할 수 없게 되고(서로 다른 두 데이터, 누구를 믿어야 할까요?) 데이터 일관성이 완전히 파괴됩니다.

옵션 4: 마스터-슬레이브 동기화 Redis 서버, Sentinel 인스턴스 3개

옵션 3에서는 고가용성을 달성할 수 없으므로 최종 버전은 위 그림과 같이 옵션 4입니다. 사실, 이것이 우리가 결국 구축한 아키텍처입니다. 우리는 서버 3을 도입하고 3에 Redis Sentinel 프로세스를 구축했습니다. 이제 3개의 Sentinel 프로세스가 2개의 Redis Server 인스턴스를 관리합니다. 이 시나리오에서는 단일 프로세스 오류, 단일 시스템 오류 또는 두 시스템 간의 네트워크 통신 오류인지 여부에 관계없이 Redis 서비스를 외부 세계에 계속 제공할 수 있습니다.

실제로 머신이 상대적으로 유휴 상태라면 물론 서버 3에서 Redis 서버를 열어 1 마스터 + 2 슬레이브 아키텍처를 구성할 수도 있으며 각 데이터에는 2개의 백업이 있으므로 가용성이 향상됩니다. 물론 슬레이브가 많을수록 좋습니다. 결국 마스터-슬레이브 동기화에도 시간이 필요합니다.

시나리오 4에서는 서버 1과 다른 서버 간의 통신이 완전히 중단되면 서버 2와 3이 슬레이브를 마스터로 전환합니다. 클라이언트의 경우 현재 서비스를 제공하는 2개의 마스터가 있으며, 일단 네트워크가 복원되면 가동 중단 중에 서버 1에 있던 모든 새 데이터는 손실됩니다. 이 문제를 부분적으로 해결하려면 Redis 서버 프로세스를 구성하여 자체 네트워크에 문제가 감지되면 즉시 서비스를 중지하여 네트워크 장애 중에 새 데이터가 들어오는 것을 방지할 수 있습니다. Slaves-to-write 및 min-slaves-max-lag 두 가지 구성 항목).

이 시점에서 우리는 3대의 머신을 사용하여 가용성이 높은 Redis 서비스를 구축했습니다. 실제로 인터넷에는 서비스 공급자의 컴퓨터 대신 클라이언트 컴퓨터에 Sentinel 프로세스를 배치하는 것보다 컴퓨터를 절약하는 방법이 있습니다. 단지 회사에서는 일반 서비스 제공자와 발신자가 같은 팀 출신이 아닐 뿐입니다. 두 팀이 동일한 기계를 함께 작동하는 경우 통신 문제로 인해 오작동이 발생하기 쉽습니다. 따라서 인적 요소를 고려하여 여전히 옵션 4의 아키텍처를 채택했습니다. 그리고 서버 3에서는 단 하나의 Sentinel 프로세스만 실행되므로 서버 리소스를 많이 소모하지 않습니다. 또한 서버 3을 사용하여 다른 서비스를 실행할 수도 있습니다.

사용 편의성: Redis Sentinel을 독립형 Redis 버전처럼 사용하세요

서비스 제공자로서 우리는 항상 사용자 경험 문제에 대해 이야기합니다. 위의 솔루션 중에는 항상 클라이언트가 사용하기 불편하게 만드는 것이 있습니다. Redis 독립형 버전의 경우 클라이언트가 Redis 서버에 직접 연결되며 IP와 포트만 제공하면 클라이언트가 서비스를 사용할 수 있습니다. Sentinel 모드로 변환한 후 클라이언트는 Sentinel 모드를 지원하는 일부 외부 종속성 패키지를 사용해야 하며 자체 Redis 연결 구성도 수정해야 하는데, 이는 분명히 "가식적인" 사용자가 받아들일 수 없는 일입니다. Redis 독립형 버전을 사용하는 것처럼 클라이언트에 고정 IP와 포트만 제공하여 서비스를 제공할 수 있는 방법이 있나요?

답은 물론 그렇습니다. 이를 위해서는 위 그림과 같이 가상 IP(Virtual IP, VIP) 도입이 필요할 수 있습니다. Redis 서버 마스터가 위치한 서버로 가상 IP를 지정할 수 있습니다. Redis 마스터-슬레이브 전환이 발생하면 콜백 스크립트가 VIP를 슬레이브가 있는 서버로 전환합니다. 이런 식으로 클라이언트의 경우 여전히 가용성이 높은 Redis 서비스의 독립형 버전을 사용하고 있는 것으로 보입니다.

결론

독립형 Redis 버전을 실행하는 것처럼 서비스를 구축하고 "사용 가능"하게 만드는 것은 실제로 매우 간단합니다. 그러나 "고가용성"을 달성하려는 경우 상황이 복잡해집니다. 사고가 발생하더라도 서비스를 계속 사용할 수 있도록 하기 위해 두 개의 추가 서버(센티넬 프로세스 3개 + 슬레이브 프로세스 1개)가 비즈니스에 사용됩니다. 실제 비즈니스에서는 프로세스 모니터링을 위한 감독자를 활성화합니다. 프로세스가 예기치 않게 종료되면 자동으로 다시 시작됩니다.

관련 권장 사항:

linux 설치 redis 서비스 및 php redis 확장

위 내용은 Redis 서비스 아키텍처 분석 및 구축을 종합적으로 마스터합니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!