이 기사는 Redis 클러스터의 마스터-슬레이브 복제 원리에 대한 심층적인 이해를 제공할 것입니다. 도움이 되길 바랍니다!
1. 더 높은 성능 달성: 동시성이 높은 애플리케이션의 경우 단일 머신 성능이 영향을 받으며, 부담을 공유하고 로드 밸런싱을 달성하려면 더 많은 Redis 서버가 필요합니다.
2. 고가용성 달성: 단일 머신인 경우 가동 중지 시간/하드웨어 오류 방지
3. 확장성 달성: 단일 머신 메모리 및 하드웨어는 제한되어 있으며 수평 확장이 가능합니다.
중복 또는 샤딩 스토리지를 통해 위 기능을 달성할 수 있습니다.
Kafka, Mysql, Rocketmq와 마찬가지로 Redis는 클러스터 노드를 마스터 노드와 슬레이브로 구분합니다. 슬레이브(최신 데이터를 복제본이라고 함).슬레이브는 복제 메커니즘을 통해 마스터의 최신 데이터를 동기화합니다. Redis는 마스터-슬레이브 복제를 활성화하는 매우 편리한 명령을 제공합니다. [관련 권장 사항: Redis 비디오 튜토리얼]
마스터-슬레이브 복제를 구성하고 활성화하는 방법은 무엇입니까?
예를 들어 로컬에서 의사 클러스터를 구축하는 경우 포트 6379가 슬레이브 노드이고 포트 6378이 마스터 노드입니다.
1. 슬레이브 노드의 redis.conf에서 masterip 마스터 포트의 복제본을 구성합니다. 슬레이브 노드를 시작하면 자동으로 마스터 노드에 연결되어 데이터 동기화가 시작됩니다. 이 구성은 다시 작성됩니다.
2. 또는 redis-server 프로그램을 시작할 때
./redis-server --replicaof masterip masterport를 지정합니다. 3. 또는 클라이언트에 로그인하고 다음 명령을 실행합니다.
slaveof masterip masterport이 방법은 작업 중에 수정되며 참고: A. 슬레이브 노드 다른 노드의 마스터 노드가 되어 계단식 복제 관계를 형성할 수도 있습니다. 그러나 다른 노드도 최상위 마스터 노드의 데이터를 동기화합니다. 클러스터 구성 후 정보 복제를 통해 클러스터 상태 확인 role 명령을 사용하여 클러스터 내 노드의 역할 정보를 확인하세요.
slaveof no one
3. 마스터-슬레이브 복제 프로세스
//每1s执行这个方法
void replicationCron(void) {
...
//检查是否需要连接到master 如果是REPL_STATE_CONNECT状态，必须连接到master
//#define REPL_STATE_CONNECT 1 Must connect to master
if (server.repl_state == REPL_STATE_CONNECT) {
serverLog(LL_NOTICE,"Connecting to MASTER %s:%d",
server.masterhost, server.masterport);
//和master创建连接
if (connectWithMaster() == C_OK) {
serverLog(LL_NOTICE,"MASTER <-> REPLICA sync started");
}
}
//发送ping命令给slave
if ((replication_cron_loops % server.repl_ping_slave_period) == 0 &&
listLength(server.slaves))
{
/* Note that we don't send the PING if the clients are paused during
* a Redis Cluster manual failover: the PING we send will otherwise
* alter the replication offsets of master and slave, and will no longer
* match the one stored into 'mf_master_offset' state. */
int manual_failover_in_progress =
server.cluster_enabled &&
server.cluster->mf_end &&
clientsArePaused();
if (!manual_failover_in_progress) {
ping_argv[0] = createStringObject("PING",4);
replicationFeedSlaves(server.slaves, server.slaveseldb,
ping_argv, 1);
decrRefCount(ping_argv[0]);
}
}
//发送换行符到所有slave,告诉slave等待接收rdb文件
listRewind(server.slaves,&li);
while((ln = listNext(&li))) {
client *slave = ln->value;
int is_presync =
(slave->replstate == SLAVE_STATE_WAIT_BGSAVE_START ||
(slave->replstate == SLAVE_STATE_WAIT_BGSAVE_END &&
server.rdb_child_type != RDB_CHILD_TYPE_SOCKET));
if (is_presync) {
if (write(slave->fd, "\n", 1) == -1) {
/* Don't worry about socket errors, it's just a ping. */
}
}
}
...
}3. 디스크 없는 복사 또는 RDB 영구 복사 지원 
Replication ID, offset
마스터 노드 버퍼에 백로그 작업이 충분하지 않거나 참조된 복제본은 더 이상 알려지지 않은 기록 레코드(복제 ID)이므로 전체 재동기화가 발생합니다. //没有在rdb进程，没有aof重写进程
if (server.rdb_child_pid == -1 && server.aof_child_pid == -1) {
time_t idle, max_idle = 0;
int slaves_waiting = 0;
int mincapa = -1;
listNode *ln;
listIter li;
listRewind(server.slaves,&li);
while((ln = listNext(&li))) {
client *slave = ln->value;
//判断slave是否是等待bgsave状态
if (slave->replstate == SLAVE_STATE_WAIT_BGSAVE_START) {
//多久没有发送心跳或查询数据了 空闲时间间隔
idle = server.unixtime - slave->lastinteraction;
if (idle > max_idle) max_idle = idle;
slaves_waiting++;
mincapa = (mincapa == -1) ? slave->slave_capa :
(mincapa & slave->slave_capa);
}
}
if (slaves_waiting &&
(!server.repl_diskless_sync ||
max_idle > server.repl_diskless_sync_delay))
{
/* Start the BGSAVE. The called function may start a
* BGSAVE with socket target or disk target depending on the
* configuration and slaves capabilities. */
//bgsave rdb生成
startBgsaveForReplication(mincapa);
}
}복제 프로세스 중에 슬레이브 상태 전환 프로세스가 발생합니다.
4. 명령 전파 단계에서는 완전한 동기화가 수행된 후 마스터와 슬레이브가 데이터 일관성을 달성하기 위해 명령을 전파합니다.
인스턴스가 기본 인스턴스로 처음부터 다시 시작되거나 복제본이 기본 인스턴스로 승격될 때마다 이 인스턴스에 대한 새 복제 ID가 생성됩니다. 두 개의 복제본이 동일한 복제 ID를 갖는 경우 서로 다른 시간에 동일한 데이터를 가질 수 있습니다. 최신 데이터 세트를 보유하는 특정 기록(복제 ID)의 경우 오프셋은 논리적 시간으로 이해됩니다. 복제 ID와 오프셋 두 가지 데이터로 판단해야 합니다. 슬레이브 노드가 데이터를 동기화한 위치를 확인하는 데 사용됩니다.
1. 슬레이브 자체에 데이터가 있으면 어떻게 되나요?
slave는 먼저 자신의 데이터를 삭제한 다음 이를 rdb 파일과 함께 로드합니다.
2.rdb 파일을 생성하는 과정에서 클라이언트가 작성한 명령을 어떻게 처리합니까?
메모리 캐시에 저장하고, RDB 전송 후 슬레이브에 전송합니다.
3. Redis 복제는 키 만료를 어떻게 처리하나요?
1. 복사본은 키를 만료시키지 않지만 호스트가 키를 만료할 때까지 기다립니다. 마스터가 키를 만료(또는 LRU로 인해 제거)하면 모든 복제본에 전송되는 DEL 명령을 합성합니다.
2. 그러나 호스트 드라이버 만료로 인해 마스터 서버가 적시에 DEL 명령을 제공할 수 없기 때문에 복제본에 논리적으로 만료된 메모리 키가 여전히 있을 수 있습니다. 이 문제를 해결하기 위해 복제본은 논리 시계를 사용하여 키가 존재하지 않는다고 보고하며 데이터 세트의 일관성을 위반하지 않는 읽기 작업에만 사용됩니다(마스터의 새 명령이 도착하기 때문입니다)
3 . Lua 스크립트에서 실행 이 기간 동안 키 만료는 수행되지 않습니다. Lua 스크립트가 실행되면 마스터 노드에서 시간이 개념적으로 고정되므로 스크립트가 실행되는 동안 주어진 키가 존재하거나 존재하지 않습니다. 이렇게 하면 스크립트 중간에 키가 만료되는 것을 방지하고 데이터 세트에서 동일한 효과를 보장하는 방식으로 키가 동일한 스크립트를 복제본에 보내도록 요구합니다.
복제본이 기본으로 승격되면 이전 기본의 도움 없이 독립적으로 키 만료가 시작됩니다.
1. 데이터 백업 문제는 해결되었으나 RDB 파일이 크고 대용량 파일이 전송되며 복구 시간도 길다
2. 비정상적인 경우 복제본을 마스터로 수동으로 선택해야 합니다
3. 마스터가 1개이고 슬레이브가 여러 개인 경우 여전히 단일 지점 문제가 있습니다.
4 Redis 버전 2.8.18 이상에서는 디스크 없는 복제를 지원합니다. 성능.
1. 비동기식 복제가 기본으로 사용되며, 동기화된 명령의 수는 비동기성을 통해 확인됩니다
2. 하나의 마스터가 여러 복사본을 가질 수도 있습니다. copy, from redis4 .0부터 복제본은 마스터 노드에서 정확히 동일한 복제 스트림을 수신합니다
4. 복제는 읽기 전용 쿼리의 확장성과 다중 복제본 모두에 사용할 수 있습니다
더 많은 프로그래밍 관련 지식을 확인하세요. 방문:
프로그래밍 입문위 내용은 Redis의 클러스터 마스터-슬레이브 복제 원리에 대한 간략한 분석의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
