Redis가 마스터-슬레이브 복제를 구현하는 방법

　앞서 Redis를 소개하자면, 우리는 모두 서버에서 작업하는데, 이는 읽기, 쓰기, 백업 작업이 모두 Redis 서버에서 수행된다는 의미입니다. 프로젝트 방문 횟수가 늘어날수록 Redis 서버에서의 작업도 점점 더 빈번해지고 있습니다. Redis는 읽기 및 쓰기 속도가 매우 빠르지만, 대규모 액세스 문제를 해결하기 위해 일반적으로 채택되는 한 가지 방법은 마스터/슬레이브 아키텍처입니다. 슬레이브는 주로 읽기용입니다. 마스터 노드가 업데이트된 후 구성에 따라 슬레이브 슬레이브 노드와 자동으로 동기화됩니다.

다음으로 마스터-슬레이브 아키텍처를 구축하는 방법을 소개하겠습니다.

　ps: 여기서는 실제 프로덕션 환경과 비교하여 여러 Redis 서버를 시뮬레이션하고 있으며 IP 주소와 포트 번호만 변경되었습니다.

　

1. 구성 파일 수정

먼저 redis.conf 구성 파일을 3개의 복사본으로 복사하고 포트를 수정하여 3개의 Redis 서버를 시뮬레이션합니다.

　

　 그런 다음 세 개의 redis.conf 파일을 각각 수정합니다.

　1、Modify daemonize yes

　

　Redis가 데몬 프로세스로 시작되었음을 나타냅니다(백그라운드에서 시작)

　②、PID 파일 경로 구성 pidfile

　

　다음을 의미합니다. dis가 데몬 프로세스로 실행되는 경우 PID 기본값을 /Var/redis/run/redis_6379.pid 파일에 기록합니다

③, 포트 포트 구성

④, 로그 파일 이름 구성

⑤RDB 파일 이름을 구성합니다

redis-cli -p 6379 redis-cli -p 6380 redis-cli -p 6381

🎜. 🎜　🎜🎜🎜　 6380redis.conf, 6381redis.conf를 차례로 한 번만 구성하면 구성이 완료됩니다. 🎜🎜 다음으로 세 가지 서비스를 각각 시작합니다. 🎜🎜　🎜🎜🎜　 다음 명령을 통해 Redis가 시작되었는지 확인합니다. 🎜🎜　🎜🎜🎜　 다음으로 다음 명령을 통해 세 가지 Redis 클라이언트를 입력합니다. 🎜🎜🎜🎜🎜🎜1🎜🎜2🎜🎜3 🎜🎜 🎜🎜redis-cli -p 6379🎜🎜redis-cli -p 6380🎜🎜redis-cli -p 6381🎜🎜🎜🎜🎜

2. 마스터-슬레이브 관계 설정

　① 정보 복제 명령을 통해 노드 역할 확인

　

　

이 세 노드가 모두 마스터 역할을 하는 것을 확인했습니다. 노드 6380 및 6381을 슬레이브 노드 역할로 변환하는 방법은 무엇입니까?

　② 포트 6380과 6381을 선택하고 다음 명령을 실행합니다: SLAVEOF 127.0.0.1 6379

　

　6379 노드 정보를 살펴보겠습니다:

　

한 번 서비스가 다시 시작되면 master 명령을 통해 설정합니다. -노예 관계가 무효화됩니다. 이 관계는 redis.conf 파일을 구성하여 영구적으로 저장할 수 있습니다.

3. 마스터-슬레이브 관계 테스트

　①, 증분 복제

　 마스터 노드가 set k1 v1 명령을 실행하면 슬레이브 노드가 k1을 얻을 수 있나요?

　

　

　

　 위 사진에서 보시다시피 사용 가능합니다.

　②、전체 복사

　 SLAVEOF 127.0.0.1 6379를 실행하여 마스터 노드 6379 앞에 키가 아직 남아 있으면 명령 실행 후 슬레이브 노드도 이전 정보를 모두 복사합니까?

　답은 '예'입니다. 여기에 테스트 결과를 게시하지 않겠습니다.

　3, 마스터-슬레이브 읽기 및 쓰기 분리

　 마스터 노드가 쓰기 명령을 실행할 수 있고, 슬레이브 노드도 쓰기 명령을 실행할 수 있나요?

　　

　　이유는 구성 파일 6381redis.conf

　　

　no로 수정하면 write 명령을 실행해도 괜찮습니다.

　

　그러나 슬레이브 노드가 쓴 데이터는 슬레이브 노드나 마스터 노드에서 얻을 수 없습니다.

　4、마스터 노드가 다운되었습니다

　 마스터 노드 마스터가 끊기면 두 슬레이브 노드의 역할이 바뀌나요?

　　

　　

　 위 그림에서 알 수 있듯이 마스터 노드 마스터가 끊긴 후에도 슬레이브 노드의 역할은 변하지 않습니다.

　⑤. 마스터 노드 다운 후 복구

마스터 노드 마스터가 끊긴 후 즉시 호스트 마스터를 시작합니다. 마스터 노드가 여전히 마스터 역할을 합니까?

　

　즉, 마스터 노드가 끊겼다가 다시 시작된 후에 마스터 노드의 역할이 복원됩니다.

4. 센티넬 모드

기존 구성에서는 마스터 노드가 하나만 있었는데, 마스터 노드가 중단되면 슬레이브 노드가 마스터 노드의 작업을 대신할 수 없게 되어 전체 시스템이 작동하게 됩니다. 실행할 수 없습니다. 여기서 센트리 모드가 탄생했는데, 슬레이브 노드가 마스터 노드의 책임을 자동으로 넘겨받아 마스터 노드 다운타임 문제를 해결할 수 있기 때문입니다.

　 센티넬 모드는 Redis가 예상대로 잘 실행되는지 수시로 모니터링하는 것입니다(적어도 마스터 노드가 존재하는지 확인하기 위해). 호스트에 문제가 있으면 센트리가 자동으로 호스트 아래에 슬레이브를 설정합니다. 새 호스트로 지정하고 다른 슬레이브가 새 호스트와 마스터-슬레이브 관계를 설정하도록 합니다.

　　

　센티넬 모드 구축 단계:

　 ①구성 파일 디렉터리에 새 sentinel.conf 파일을 생성하고 이름이 틀리지 않아야 하며 해당 내용을 구성합니다

　　

1	sentinel monitor 모니터링되는 시스템의 이름(직접 이름 지정) IP 주소 포트 번호 투표 수sentinel monitor 被监控机器的名字(自己起名字) ip地址 端口号 得票数

　　

　　分别配置被监控的名字，ip地址，端口号，以及得票数。当主机宕机时，从机需要投票决定谁接替成为主机，得票数达到1时不足以成为主机，必须超过1才可成为主机

　　②、启动哨兵

1	redis-sentinel /etc/redis/sentinel.conf

　🎜🎜　 모니터링되는 이름, IP 주소, 포트 번호 및 투표 수를 각각 구성합니다. 마스터가 무너지면 슬레이브들이 투표를 통해 누가 마스터가 될지 결정해야 합니다. 투표 수가 1에 도달하면 마스터가 되기 위해서는 1을 초과해야 합니다🎜🎜　　②. 보초 시작🎜

🎜1🎜🎜🎜🎜 redis-sentinel /etc/redis/sentinel.conf🎜🎜🎜🎜🎜

　시작 인터페이스:

　

　 다음으로 호스트 6379를 종료하고 슬레이브 노드에서 어떤 변화가 일어나는지 확인합니다.

　

마스터 노드를 종료한 후 백그라운드 인쇄 로그를 확인한 결과 6381명이 마스터 노드가 되기로 투표한 것을 발견했습니다.

　　

　이때 슬레이브 노드 6381의 노드 정보를 확인합니다.

　

　6381 노드가 자동으로 마스터 노드가 됩니다.

PS: Sentinel 모드에도 단일 실패 지점 문제가 있습니다. Sentinel 시스템이 중단되면 더 이상 모니터링이 불가능합니다. 해결책은 Redis Sentinel 모드에서도 클러스터를 지원하는 것입니다.

5. 마스터-슬레이브 복제 원칙

Redis의 복제 기능에는 동기화(sync)와 명령 전파(command propagate)라는 두 가지 작업이 포함됩니다.

　1、이전 버전 동기화

　슬레이브 노드가 SLAVEOF 명령을 보내 슬레이브 서버가 마스터 서버를 복사하도록 요구하면 슬레이브 서버는 마스터 서버에 SYNC 명령을 보내 이를 완료합니다. 명령 실행 단계는 다음과 같습니다.

　1. 서버에서 마스터 서버로 SYNC 명령을 보냅니다

　2. SYNC 명령을 받은 마스터 서버는 BGSAVE 명령을 실행하고 백그라운드에서 RDB 파일을 생성한 후 버퍼를 사용합니다. 모든 실행을 처음부터 기록하는 쓰기 명령

　　3. 마스터 서버의 BGSAVE 명령이 실행되면 마스터 서버는 BGSAVE 명령으로 생성된 RDB 파일을 슬레이브 서버로 전송하고 슬레이브 서버는 RDB 파일을 수신하여 업데이트합니다. 서버 상태를 RDB 파일에 기록된 상태로 변경합니다.

　4. 마스터 서버도 버퍼에 있는 모든 쓰기 명령을 슬레이브 서버로 보내고, 슬레이브 서버는 해당 명령을 실행합니다.

　②、명령 전파

　 동기화 작업이 완료되면 마스터 서버는 해당 수정 명령을 내립니다. 이때 슬레이브 서버와 마스터 서버의 상태가 일치하지 않습니다.

　마스터 서버와 슬레이브 서버의 상태를 일관되게 유지하려면 마스터 서버가 슬레이브 서버에서 명령 전파 작업을 수행해야 합니다. 마스터 서버는 실행을 위해 슬레이브 서버에 자체 쓰기 명령을 보냅니다. 슬레이브 서버가 해당 명령을 실행한 후에도 마스터 서버와 슬레이브 서버의 상태는 계속 일관됩니다.

요약: 동기화 작업 및 명령 전파 기능을 통해 마스터-슬레이브 일관성 기능을 잘 보장할 수 있습니다.

하지만 마스터 서버와 동기화 중에 슬레이브 서버가 갑자기 연결이 끊어지고 이때 마스터 서버가 일부 쓰기 작업을 수행하고 슬레이브 서버가 연결을 복원하는 경우 문제를 고려합니다. 마스터 서버에서 RDB 파일을 가져와 슬레이브 서버에 로드하면 일관성을 보장할 수 있지만 연결이 끊어지기 전에는 마스터 서버와 슬레이브 서버의 상태가 실제로 일치합니다. 불일치는 복원 후 슬레이브 서버의 연결이 끊어지고 마스터 서버가 실행된다는 것입니다. 서버와의 연결을 끊는 경우 전체 RDB 스냅샷 대신 쓰기 명령 연결만 끊을 수 있나요?

　 동기화 작업은 실제로 시간이 많이 걸리는 작업입니다. 마스터 서버는 먼저 BGSAVE 명령을 통해 RDB 파일을 생성한 다음 슬레이브 서버에서 파일을 받은 후 파일을 슬레이브 서버로 보내야 합니다. 그런 다음 파일을 로드하고 이 기간 동안 슬레이브 서버는 다른 명령을 처리할 수 없습니다.

　이 문제를 해결하기 위해 Redis는 버전 2.8부터 SYNC 명령을 대체하는 새로운 동기화 명령인 PSYNC을 사용합니다. 이 명령의 부분 재동기화 기능은 연결 끊김 후 재복제의 효율성 문제를 처리하는 데 사용됩니다. 즉, 슬레이브 서버가 연결이 끊어진 후 마스터 서버에 다시 연결되면 마스터 서버는 연결이 끊어진 후 실행된 쓰기 명령만 슬레이브 서버로 전송하고, 슬레이브 서버는 마스터를 유지하기 위해 이러한 쓰기 명령만 수신하고 실행하면 됩니다. - 노예 일관성.

6. 마스터-슬레이브 복제의 단점

마스터-슬레이브 복제는 마스터 노드의 단일 장애 지점 문제를 해결하지만 모든 쓰기 작업은 마스터 노드에서 수행된 후 슬레이브 노드로 동기화되므로 동기화 문제 특정 지연이 있습니다. 시스템이 매우 바쁜 경우 지연 문제는 더욱 심각해지고 슬레이브 노드 수가 증가하면 더욱 심각해집니다.

위 내용은 Redis가 마스터-슬레이브 복제를 구현하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!