Redis 백업, 재해 복구 및 고가용성 사례 분석 사례

1. Redis에 대한 간략한 소개

Redis는 고성능 키-값 비관계형 데이터베이스로 고성능 특성으로 인해 고가용성, 지속성, 다중 데이터 구조, 클러스터 등을 지원합니다. 눈에 띄게 만들어 일반적으로 사용되는 비관계형 데이터베이스가 되었습니다.

또한 Redis에는 다양한 사용 시나리오가 있습니다.

Session Cache

Redis 캐시 세션은 장바구니 시나리오와 같이 오랫동안 세션을 유지해야 하는 애플리케이션 시나리오에서 우수한 장기 성능을 제공할 수 있는 지속성을 제공하기 때문에 매우 좋은 장점이 있습니다. 사용자에게 좋은 쇼핑 경험을 제공합니다.

전체 페이지 캐시

WordPress에서 Pantheon은 검색한 페이지를 가장 빠른 속도로 로드할 수 있는 우수한 플러그인 wp-redis를 제공합니다.

Queue

Redis는 목록 및 집합 작업을 지원하므로 메시지 대기열 플랫폼으로 사용하기에 매우 적합합니다. 우리는 구매를 제한하기 위해 Reids의 대기열 기능을 자주 사용합니다. 예를 들어 휴일이나 프로모션 기간 동안에는 사용자의 구매 행동을 제한하기 위해 일부 활동이 수행될 수 있습니다. 즉, 오늘 구매를 몇 번으로 제한하거나 일정 기간 내에 한 번만 구매하도록 제한할 수 있습니다. 또한 적용에 더 적합합니다.

Ranking

Redis는 메모리에서 숫자를 늘리거나 줄이는 연산을 매우 잘 구현합니다. 따라서 우리는 많은 순위 시나리오에서 Redis를 사용합니다. 예를 들어 소설 웹 사이트는 소설 순위를 매기고 순위에 따라 사용자에게 최고 순위의 소설을 추천합니다.

Publish/Subscribe

Redis는 게시 및 구독 기능을 제공합니다. 예를 들어 게시 및 구독 스크립트 트리거를 기반으로 Redis의 게시 및 구독 기능을 사용하여 구축된 채팅 시스템을 구현할 수 있습니다.

이 외에도 Redis가 좋은 성능을 보이는 다른 시나리오도 많이 있습니다.

2. Redis 사용 시 단일 실패 문제

Redis는 다양한 기업에서 사용되고 있으며, 다양한 뛰어난 기능과 ​​풍부한 응용 시나리오가 존재 이유입니다. 그러면 문제와 위험이 올 것입니다. Redis에는 풍부한 애플리케이션 시나리오가 있지만 일부 회사에서는 Redis 애플리케이션을 실행할 때 여전히 상대적으로 보수적으로 단일 노드 배포를 사용하므로 향후 유지 관리에 보안 위험이 발생합니다.

저는 2015년에 단일 장애로 인한 업무 중단 문제를 처리한 적이 있습니다. Redis가 처음 배포되었을 때는 분산 배포가 아닌 단일 노드 배포를 사용했으며 재해 복구 문제를 고려하지 않았습니다.

당시 저희는 사용자의 할인 상품 구매를 통제하기 위해 Redis 서버를 사용했습니다. 그러나 알 수 없는 이유로 Redis 노드의 서버가 다운되어 사용자의 구매 행위를 통제할 수 없게 되었습니다. 사용자가 일정 기간 내에 여러 번 구매할 수 있는 상품을 할인하는 행위입니다.

이런 다운타임 사고는 회사에 돌이킬 수 없는 손실을 입혔다고 할 수 있습니다. 보안 위험 문제는 당시 시스템을 운영하고 유지 관리하는 사람으로서 이 문제를 해결해야 했고, 아키텍처를 개선합니다. 그래서 비분산 애플리케이션에서 Redis 단일 실패 지점을 해결하는 방법을 연구하고 배우기 시작했습니다.

3. 비분산 시나리오에서 Redis 애플리케이션의 백업 및 재해 복구

Redis 마스터-슬레이브 복제는 이제 매우 일반적입니다. 일반적으로 사용되는 마스터-슬레이브 복제 아키텍처에는 다음 두 가지 아키텍처 솔루션이 포함됩니다.

일반적으로 사용되는 Redis 마스터-슬레이브 복제

옵션 1

일반적으로 이 구조, 즉 마스터 노드 1개와 슬레이브 노드 2개가 가장 일반적입니다. 클라이언트가 데이터를 쓸 때는 마스터 노드에 쓰고, 읽을 때는 두 개의 슬레이브에서 읽습니다. 이를 통해 읽기 확장이 이루어지고 마스터 노드의 읽기 부하가 줄어듭니다.

옵션 2

이 아키텍처에는 마스터 1개와 슬레이브 2개가 있습니다. 마스터와 슬레이브1은 연결 유지를 사용하여 다양한 방식으로 VIP 마이그레이션을 구현합니다. 클라이언트가 마스터에 연결되면 VIP를 통해 연결됩니다. 이렇게 하면 솔루션 1에서 IP 변경 상황이 방지됩니다.

Redis 마스터-슬레이브 복제의 장점과 단점

장점

마스터가 실패하면 슬레이브 노드를 새 마스터로 승격하고 이전 마스터를 교체하여 계속할 수 있습니다. 서비스를 제공하기 위해

구현 확장 프로그램을 읽어보세요. 마스터-슬레이브 복제 아키텍처는 일반적으로 읽기 확장을 달성하는 데 사용됩니다. Master는 주로 쓰기 기능을 구현하고, Slave는 읽기 기능을 구현합니다.

Insufficiency

Architecture Solution 1

마스터에서 장애가 발생하면 클라이언트는 마스터와의 연결을 끊고 쓰기 기능을 구현할 수 없습니다. 동시에 슬레이브는 마스터가 복사본을 만들 수 없습니다.

이때 다음 작업을 수행해야 합니다(Slave1이 마스터로 승격되었다고 가정).

1. Slave1에서slaveofnoone 명령을 실행하여 Slave1을 새 마스터 노드로 승격합니다.

2. 은 Slave1에서 쓰기 가능으로 구성됩니다. 이는 대부분의 경우 슬레이브가 읽기 전용으로 구성되어 있기 때문입니다.

3. 클라이언트(즉, Redis에 연결하는 프로그램)에게 새 마스터 노드의 연결 주소를 알려줍니다.

4. 새 마스터에서 데이터를 복사하도록 Slave2를 구성합니다.

아키텍처 계획 2

마스터가 실패하면 클라이언트는 데이터 작업을 위해 Slave1에 연결할 수 있지만 Slave1은 단일 지점이 되어 종종 필요한 단일 실패 지점(단일 실패 지점)으로 이어집니다. 실패를 피해야 합니다.)

이후에 다음 작업을 수행해야 합니다.

1. Slave1에서 Slaveof no one 명령을 실행하여 Slave1을 새 마스터 노드로 승격합니다.

2. Slave1을 쓰기 가능으로 구성합니다. 왜냐하면 대부분의 경우 구성이 읽기 전용으로 슬레이브

3. 새 마스터에서 데이터를 복사하도록 Slave2를 구성하세요

모든 아키텍처 솔루션에는 장애 조치를 위해 수동 개입이 필요하다는 점에 유의해야 합니다. 수동 개입의 필요성은 운영 및 유지 관리 작업량을 증가시키고 비즈니스에도 큰 영향을 미칩니다. 이때 Redis의 고가용성 솔루션인 Sentinel

4을 사용할 수 있습니다. Redis Sentinel 소개

Redis Sentinel은 Redis를 위한 고가용성 솔루션을 제공합니다. 실용적인 관점에서 Redis Sentinel을 사용하면 사람의 개입 없이 특정 오류를 방지하는 Redis 환경을 만들 수 있습니다.

Redis Sentinel은 분산 아키텍처를 채택하고 협업 협력을 위해 여러 프로세스를 실행합니다. 여러 Sentinel 프로세스를 실행하여 협력합니다. 여러 Sentinel이 더 이상 특정 마스터에 서비스를 제공할 수 없는 경우 오류 감지가 수행되어 오탐 가능성이 줄어듭니다.

5. Redis Sentinel 기능

Redis 고가용성 솔루션에서 Redis Sentinel의 주요 기능은 다음과 같습니다.

Monitoring

Sentinel은 마스터와 슬레이브가 예상대로 정상적으로 실행되는지 지속적으로 확인합니다

Notification

Sentinel은 API를 통해 시스템 관리자와 프로그램이 모니터링하는 Redis 실패 인스턴스를 알릴 수 있습니다.

자동 장애 조치

마스터가 예상대로 실행되지 않으면 Sentinel은 장애 조치 프로세스를 시작할 수 있습니다. 그 중 하나는 슬레이브가 Redis 서비스를 사용하는 애플리케이션도 연결 시 새 주소를 사용하도록 알림을 받게 됩니다.

구성 공급자

Sentinel은 클라이언트 서비스 검색을 위한 인증 소스로 사용될 수 있습니다. 클라이언트는 Sentinel에 연결하여 현재 특정 서비스를 담당하는 Redis 마스터 주소를 얻습니다. 장애 조치가 발생하면 Sentinel은 새 주소를 보고합니다.

6. Redis Sentinel 아키텍처

7. Redis Sentinel 구현 원칙

Sentinel 클러스터는 자체 모니터링과 Redis 마스터-슬레이브 복제를 모니터링합니다. 마스터 노드에 장애가 발생한 것이 발견되면 다음 단계를 따릅니다.

• 1) 리더를 선출하기 위해 센티널 간에 선거가 진행되며, 선출된 리더는 페일오버를 수행합니다

• 센티넬 리더는 하나를 선택합니다. 슬레이브 노드에서 새로운 마스터 노드로. 다음은 해당 문장을 다시 작성한 것입니다. 슬레이브 선택을 구현하려면 다음 선택 방법을 구현해야 합니다. a) 마스터에서 연결을 끊는 시간

마스터에서 연결을 끊는 시간이 밀리초(센티넬 구성) * 10초를 초과하는 경우 time from sentinel 마스터가 사용할 수 없다고 판단된 시점부터 Sentinel이 장애 조치를 수행하기 시작한 시점 사이의 시간을 기준으로 슬레이브는 마스터로 승격하기에 적합하지 않은 것으로 간주됩니다.

b) 슬레이브 우선순위

각 슬레이브에는 redis.conf 구성 파일에 저장되는 우선순위가 있습니다. 우선순위가 동일하면 계속 진행합니다.

c) 복제 오프셋 위치

복제 오프셋은 마스터에서 데이터가 복사되는 위치를 기록합니다. 복제 오프셋이 클수록 마스터에서 더 많은 데이터를 수신합니다.

d) Run ID

Run ID가 가장 작은 슬레이브를 새로운 마스터로 선택합니다

흐름도는 다음과 같습니다.

• 3) Sentinel 리더는 누구의 슬레이브도 실행하지 않습니다. 이전 단계 Operation에서 선출된 새로운 마스터를 마스터 노드로 승격

• 4) 센티넬 리더는 다른 슬레이브에게 명령을 보내 나머지 슬레이브를 새 마스터 노드의 슬레이브로 만듭니다

• 5) 센티넬 리더는 원래 마스터를 슬레이브로 강등합니다. 정상적인 작업이 재개되면 Sentinel 리더는 새 마스터에서 복사하라는 명령을 보냅니다. 위의 장애 조치 작업은 모두 수동 개입 없이 Sentinel 자체에서 완료됩니다.

위 내용은 Redis 백업, 재해 복구 및 고가용성 사례 분석 사례의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!