이 기사에서는 Redis의 마스터-슬레이브 동기화를 이해하고 Redis 마스터-슬레이브의 두 가지 구조 모델, 마스터-슬레이브 관계 설정, 마스터-슬레이브 복제 전략 등을 소개할 것입니다. 모두에게 도움이 될 거예요!
이전 글에서 Redis의 특징과 핵심 원리를 자세히 분석했습니다. 이번 글을 시작으로 Redis의 배포 구조와 운영 모드를 분석하고 해석하겠습니다. 실제 프로덕션 환경에서는 기본적으로 단일 노드 Redis를 사용하여 서비스를 제공하지 않으며 적어도 Redis 서비스의 안정성을 보장하기 위해 마스터-슬레이브 구조의 센티널 또는 클러스터 모드를 사용하지 않습니다. 이 기사에서는 Redis의 마스터-슬레이브 동기화 메커니즘을 자세히 설명합니다. [관련 권장사항: Redis 동영상 튜토리얼]
하나의 마스터와 N개의 슬레이브의 복제 구조는 하나의 레벨만 가집니다. 일반적으로 센트리나 클러스터 구조를 구축하는 Redis에서는 1차 슬레이브 노드의 복제 관계를 통해 서비스의 가용성을 보장하고 마스터-슬레이브 전환을 달성할 수 있는 형태이기도 합니다. 비정상적인 상황에서는.
캐스케이드 복제 구조의 복제 관계는 여러 수준을 가질 수 있으며, 마스터 노드의 슬레이브 노드는 하위 슬레이브 노드의 마스터 노드가 될 수 있습니다. 캐스케이드 복제 구조의 적용은 상대적으로 드물다. 이 구조는 슬레이브 노드가 여러 개 있는 구조에서 마스터 노드의 복제 부담을 어느 정도 완화할 수 있다.
Redis의 마스터-슬레이브 동기화는 SLAVEOF 호스트 포트 명령으로 시작됩니다. 이 명령을 통해 SLAVEOF 명령을 사용하여 동작을 수정할 수 있습니다. Redis가 실행 중일 때 복제 기능. SLAVEOF 호스트 포트 명령을 실행하면 현재 서버를 지정된 서버의 슬레이브 서버로 전환할 수 있습니다. 현재 서버가 이미 마스터 서버의 슬레이브 서버인 경우 SLAVEOF 호스트 포트를 실행하면 현재 서버는 이전 마스터 서버와의 동기화를 중지하고 이전 데이터 세트를 삭제한 후 새 마스터 서버와 동기화를 시작합니다. 또한 슬레이브 서버에서 SLAVEOF NO ONE 명령을 실행하면 슬레이브 서버가 복제 기능을 끄고 슬레이브 서버에서 마스터 서버로 다시 전환되므로 원래 동기화된 데이터 세트는 삭제되지 않습니다. Sentinel과 Cluster를 설정하지 않고 동기화된 데이터 세트를 폐기하지 않는 SLAVEOF NO ONE의 기능을 활용하면 마스터 서버에 장애가 발생하면 슬레이브 서버를 새로운 마스터 서버로 사용하여 중단 없는 운영을 달성할 수 있습니다.
다음 그림은 마스터-슬레이브 관계를 설정하는 과정을 보여줍니다.
참고:
위의 실행 과정에 따르면, Slaveof 명령을 실행할 때 주의해야 할 점이 있습니다. 이미 마스터-슬레이브 관계가 있는 노드에서 기존 마스터-슬레이브 관계를 종료하고 노드 아래의 모든 데이터를 삭제합니다. 이는 프로덕션 환경에서 상대적으로 위협적인 작업입니다. 더 안전한 방법이 있나요? 위에서 Slaveof 명령을 소개할 때 NO ONE 매개변수를 전달할 수 있다고 언급했습니다. 즉, SLAVEOF NO ONE 명령을 실행하면 이 명령은 마스터-슬레이브 복제 관계만 종료하고 데이터를 지우지 않으므로 상대적으로 더 안전합니다. .
마스터-슬레이브 관계가 설정된 후 마스터-슬레이브 데이터 동기화 프로세스에 들어갑니다. 여기에는 마스터-슬레이브 관계가 방금 설정된 후 전체 데이터 동기화가 있습니다. 초기 동기화가 완료된 후 마스터-슬레이브 관계가 비정상적으로 중단되고 다시 연결된 후 동기화 방법 선택. 전체 동기화와 증분 동기화의 두 가지 시나리오가 있습니다.
슬레이브 노드가 시작되거나 연결이 끊어졌다가 다시 연결되면(재연결이 증분 동기화 조건을 충족하지 않음) SYNC 명령이 마스터 데이터베이스로 전송됩니다.
마스터 노드는 SYNC 명령을 받은 후 백그라운드에서 스냅샷을 저장하기 시작합니다(즉, 마스터-슬레이브 복제 중에 무조건 RDB를 트리거하는 RDB 지속성). 스냅샷 저장 중에 받은 명령을 캐시합니다. .
마스터 노드는 RDB 지속성을 완료한 후 스냅샷 RDB 파일을 모든 슬레이브 노드에 전송하고 스냅샷 전송 중에 실행된 쓰기 명령을 계속 기록합니다.
스냅샷 파일을 수신한 후 슬레이브 노드는 이전 데이터를 모두 삭제하고(모든 데이터가 지워짐) 수신된 스냅샷을 로드합니다.
마스터 노드 스냅샷이 전송되고 슬레이브 노드가 스냅샷을 로드한 후 마스터 노드는 버퍼에 있는 쓰기 명령을 슬레이브 노드로 보내기 시작합니다.
슬레이브 노드는 스냅샷 로드를 완료하고 명령 요청 수신을 시작하며 기본 데이터베이스 버퍼에서 쓰기 명령을 실행합니다. (데이터베이스에서 초기화 완료)
마스터 노드가 쓰기 명령을 실행할 때마다 슬레이브 노드에도 동일한 쓰기 명령을 보내고, 슬레이브 노드는 수신된 쓰기 명령을 받아 실행합니다. (명령 전파 동작, 슬레이브 노드 초기화 완료 후 동작)
전체 동기화 과정은 아래와 같습니다.
redis2.8 이전에는 슬레이브 노드가 초기화되거나 연결이 끊어졌다가 다시 연결되더라도 전체 동기화를 사용했습니다. .2.8 이후 버전에서는 PSYNC 명령이 도입되어 슬레이브 노드의 연결이 끊어졌다가 다시 연결된 후 증분 동기화를 사용할지 여부를 판단하게 됩니다.
PSYNC에는 전체 데이터 재동기화 및 증분 동기화 모드가 있습니다.
전체 재동기화: 기본적으로 이전 버전의 복사와 동일하며 "전체" 복사로 이해하면 됩니다.
부분 재동기화: 슬레이브의 연결이 끊겼다가 다시 연결될 때 명령 전파 단계에서 마스터와의 연결이 끊어진 기간 동안 실행된 명령만 슬레이브에 보내면 되는데, 이는 "증분" 복제로 이해될 수 있습니다. .
PSYNC 실행 과정에는 runid, 오프셋(복사 오프셋), 백로그 버퍼 복사라는 세 가지 중요한 개념이 있습니다.
1.runid
각 Redis 서버에는 해당 서버의 ID를 나타내는 ID가 있습니다. PSYNC에서 전송된 ID는 이전에 연결된 마스터의 ID를 참조합니다. 이 ID를 저장하지 않으면 PSYNC 명령은 "PSYNC? -1" 형식을 사용하여 전체 복사가 필요함을 나타냅니다.
2.offset(복제 오프셋)
마스터-슬레이브 복제의 마스터와 슬레이브는 모두 각각 오프셋을 유지합니다. 마스터가 N바이트 명령을 성공적으로 보낸 후 마스터의 오프셋은 N만큼 증가합니다. 슬레이브가 N바이트 명령을 받은 후 슬레이브의 오프셋도 N만큼 증가합니다. 마스터와 슬레이브의 상태가 일치하면 오프셋도 일치해야 합니다.
3. 복사 백로그 버퍼
복사 백로그 버퍼는 마스터가 유지 관리하는 고정 길이 순환 백로그 대기열(FIFO 대기열)입니다. 해당 기능은 전파된 명령을 캐시하는 것입니다. 마스터가 명령을 전파할 때 모든 슬레이브에 명령을 보낼 뿐만 아니라 명령을 복제 백로그 버퍼에 기록합니다. PSYNC와 SYNC의 실행 프로세스의 차이점은 salve 연결 시 전체 동기화가 필요한지 여부를 판단한다는 점입니다. 전체 동기화의 논리적 프로세스는 SYNC와 동일합니다. PSYNC의 실행 단계는 다음과 같습니다.
클라이언트가 SLAVEOF 명령을 서버에 보냅니다. 즉, 슬레이브가 마스터에 연결 요청을 시작할 때 슬레이브는 연결 여부에 따라 첫 번째 연결인지 여부를 결정합니다. Master runid를 저장합니다.
첫 번째 동기화인 경우 완전한 동기화를 위해 PSYNC ? -1 명령이 마스터로 전송되고, 재연결인 경우 PSYNC runid 오프셋 명령이 마스터로 전송됩니다(runid는 ID ID입니다. 마스터의 오프셋이고 슬레이브 노드 동기화 명령의 글로벌 마이그레이션 양입니다.
PSYNC 명령을 받은 후 마스터는 먼저 runid가 로컬 머신의 ID와 일치하는지 확인합니다. 일치하는 경우 오프셋 오프셋과 로컬 머신의 오프셋이 복사본을 초과하는지 다시 확인합니다. 백로그 버퍼 크기가 아닌 경우 CONTINUE를 슬레이브에 전송합니다. 이 때 슬레이브는 연결이 끊긴 동안 손실된 명령을 마스터가 반환할 때까지 기다리기만 하면 됩니다. runid가 로컬 ID와 일치하지 않거나 오프셋 간격이 복사 백로그 버퍼 크기를 초과하는 경우 FULLRESYNC runid 오프셋이 반환되고 슬레이브는 runid를 저장하고 전체 동기화를 수행합니다.
마스터 노드가 명령을 전파하면 마스터 데이터베이스는 각 쓰기 명령을 슬레이브 데이터베이스에 전달하는 동시에 쓰기 명령을 백로그 대기열에 저장하고 저장된 명령의 전역 오프셋을 기록합니다. 현재 백로그 큐. 슬레이브가 다시 연결되면 마스터는 슬레이브 노드에서 전달된 오프셋을 기반으로 연결 해제 기간 동안 실행된 명령을 링 백로그 큐에서 찾아 이를 슬레이브 노드와 동기화하여 증분 동기화 결과를 얻습니다.
PSYNC 실행 과정은 아래와 같습니다.
위의 PSYNC 실행 과정에서 슬레이브 노드가 연결 해제되었다가 다시 연결될 때 증분 동기화 사용 여부를 결정하는 코어가 해당 노드의 오프셋 오프셋임을 알 수 있습니다. 슬레이브와 마스터의 오프셋 차이가 복사 백로그 버퍼 크기를 초과하는 경우 이 크기는 다음 매개변수로 구성됩니다. 복제 백로그 버퍼는 기본적으로 고정 길이 순환 대기열입니다. 대기열 크기는 구성 파일을 통해 설정할 수 있습니다. 백로그 대기열이 클수록. 마스터-슬레이브 데이터베이스 연결이 더 오래 걸릴수록
repl-backlog-size 1mb
Redis는 동기화할 슬레이브가 없을 때 링 대기열을 해제하는 데 걸리는 시간도 제공합니다. 기본값은 1시간입니다. 연결, 복제 백로그 버퍼가 해제되는 빈도
repl-backlog-ttl 3600
Redis采用了乐观复制的策略，也就是在一定程度内容忍主从数据库的内容不一致，但是保持主从数据库数据的最终一致性。具体来说，Redis在主从复制的过程中，本身就是异步的，在主从数据库执行完客户端请求后会立即将结果返回给客户端，并异步的将命令同步给从数据库，但是这里并不会等待从数据库完全同步之后，再返回客户端。这一特性虽然保证了主从复制期间性能不受影响，但是也会产生一个数据不一致的时间窗口，如果在这个时间窗口期间网络突然断开连接，就会导致两者数据不一致。如果不在配置文件中添加其他策略，那就默认会采用这种方式。为了防止主从不一致不可控，redis提供了以下两个参数来做约束：
min-slaves-to-write 3 min-slaves-max-lag 10
当slave数量小于min-slaves-to-write，且延迟小于等于min-slaves-max-lag时，master停止写入操作。
还有一个参数也会影响主从之间的延时：
repl-disable-tcp-nodelay：
设置成yes，则redis会合并小的TCP包从而节省带宽，但会增加同步延迟，造成master与slave数据不一致。设置成no，则redis master会立即发送同步数据，几乎没有延迟。
Redis的主从同步无论那种场景可以抽象为以下七个步骤：
1.建立socket连接
从服务器根据设置的套接字创建连向主服务器的套接字连接，主服务器接收从服务器的套接字连接之后，为该套接字创建响应的客户端状态，并将此时的从服务器看做是主服务器的客户端，也就是该从服务器同时具备服务器与客户端两个身份。
2.发送PING命令
PING命令主要有两种作用：虽然建立了套接字连接，但是还未使用过，通过发送PING命令检查套接字的读写状态是否正常；通过发送PING命令检查主服务器能否正常处理命令请求，能处理主服务器回复PONG。
3.身份验证
从服务器接收到主服务器返回的“PONG”回复，接下来就需要考虑身份验证的事。如果从服务器设置了masterauth选项，那么进行身份验证，如果从服务器没有设置masterauth选项，那么不进行身份验证。
4.发送端口信息
在身份验证步骤之后，从服务器将执行命令REPLCONF listening-port ，向主服务器发送从服务器的监听端口号。
5.数据同步
从服务器向主服务器发送SYNC命令、PSYNC命令，执行同步操作。
6.命令传播
主从服务器就会进入命令传播阶段，主服务器只要将自己执行的写命令发送给从服务器，而从服务器只要一直执行并接收主服务器发来的写命令。
本篇详细介绍了redis主从同步机制，不同场景下同步策略的选择，这也是redis高可用的基石。在此基础上，下一篇将对redis高可用的实现来进行分析讲解。
更多编程相关知识，请访问：编程视频！！
위 내용은 Redis의 마스터-슬레이브 동기화 메커니즘에 대한 심층적인 이해의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
