Redis의 높은 동시성을 보장하는 방법을 알고 계십니까?

아래 Redis Tutorial 칼럼에서는 Redis의 높은 동시성을 보장하는 방법을 소개하겠습니다. 도움이 필요한 친구들에게 도움이 되길 바랍니다!

　 단일 머신 Redis가 100,000+(일반적으로 수만) 이상의 QPS를 갖는 것은 거의 불가능합니다.

기계 성능이 특히 좋고, 구성이 특히 높고, 물리적 기계가 특히 잘 유지 관리되고, 전반적인 작업이 너무 복잡하지 않은 등 특별한 상황이 없는 한.

Redis는 읽기와 쓰기를 분리하기 위해 마스터-슬레이브 아키텍처를 사용합니다. 마스터 노드는 다른 슬레이브 노드에 대한 데이터 쓰기 및 동기화를 담당하고, 슬레이브 노드는 읽기를 담당하므로 높은 동시성을 달성합니다. .

Redis는 동시성이 높을 뿐만 아니라 하나의 마스터와 여러 슬레이브 등 많은 양의 데이터를 수용해야 하며 각 인스턴스는 전체 데이터를 수용합니다. 예를 들어 Redis 마스터에는 10G의 메모리만 있습니다. 실제로 10g의 데이터만 저장할 수 있습니다. 캐시가 수십 기가바이트, 심지어 수백 기가바이트 또는 수 톤에 달하는 대량의 데이터를 수용해야 한다면 Redis 클러스터가 필요하며, Redis 클러스터를 사용하면 초당 수십만 개의 데이터를 제공할 수 있습니다. 동시에 읽고 씁니다.

복제의 핵심 메커니즘

redis는 비동기 방식을 사용하여 슬레이브 노드에 데이터를 복사하지만, Redis 2.8부터 슬레이브 노드는 매번 복사하는 데이터의 양을 주기적으로 확인합니다
마스터 A 노드는 여러 개의 슬레이브 노드로 구성될 수 있습니다.
슬레이브 노드는 다른 슬레이브 노드에도 연결할 수 있습니다.
슬레이브 노드가 복제될 때 마스터 노드의 정상적인 작업을 방해하지 않습니다
슬레이브 노드는 복제 중입니다. 복사가 완료되면 자체 쿼리 작업을 차단하지 않고 이전 데이터 세트를 사용하여 서비스를 제공하지만, 복사가 완료되면 이전 데이터 세트를 삭제하고 새 노드를 사용해야 합니다. 데이터 세트가 로드되었으며 현재 외부 서비스가 중단됩니다
　슬레이브 노드는 주로 읽기 및 쓰기의 수평 확장 및 분리에 사용됩니다. 확장된 슬레이브 노드는 읽기 처리량을 향상시킬 수 있습니다

의미 마스터-슬레이브 아키텍처의 보안을 위한 마스터 지속성

채택할 경우 마스터-슬레이브 아키텍처가 있는 경우 마스터 노드의 지속성을 반드시 활성화하는 것이 좋습니다!

슬레이브 노드를 마스터 노드의 데이터 핫 백업으로 사용하는 것은 권장하지 않습니다. 이 경우 마스터의 지속성을 끄면 마스터가 충돌하고 다시 시작할 때 데이터가 비어 있을 수 있기 때문입니다. 복사하면 노드 데이터도 삭제될 수 있습니다.

두 번째, 마스터에 대한 다양한 백업 계획을 수행하시겠습니까? 마스터를 복원하기 위한 백업입니다. 이는 마스터가 시작되는 것을 보장할 수 있습니다.

슬레이브 노드가 시작되면 마스터가 데이터를 동기화하는 프로세스입니다. 마스터 노드에 PSYNC 명령을 보냅니다

이것이 마스터 노드에 다시 연결되는 슬레이브 노드라면 마스터 노드는 누락된 데이터만 슬레이브에 복사합니다. 그렇지 않으면 슬레이브 노드가 마스터 노드에 연결됩니다. 처음에는 전체 재동기화가 시작됩니다

전체 재동기화가 시작되면 마스터는 백그라운드 스레드를 시작하고 RDB 스냅샷 파일 생성을 시작하며 클라이언트로부터 받은 모든 쓰기 명령을 메모리에 캐시합니다.

RDB 파일이 생성된 후 마스터는 RDB를 슬레이브에 보냅니다. 슬레이브는 먼저 이를 로컬 디스크에 쓴 다음 로컬 디스크에서 메모리로 로드합니다. 그런 다음 마스터는 메모리에 캐시된 쓰기 명령을 슬레이브에 보내고 슬레이브도 데이터를 동기화합니다.

　 슬레이브 노드가 마스터 노드와 네트워크 장애가 발생하여 연결이 끊어지면 자동으로 다시 연결됩니다. 마스터가 여러 슬레이브 노드가 다시 연결되어 있음을 발견하면 rdb 저장 작업만 시작하고 데이터 복사본을 사용하여 모든 슬레이브 노드를 제공합니다.

마스터-슬레이브 복제 중단점 재개

Redis 2.8부터 마스터-슬레이브 복제 프로세스 중에 네트워크 연결이 끊어지면 처음부터 시작하지 않고 마지막으로 복사한 위치에서 계속 복사할 수 있습니다. 노드는 백로그를 메모리에 저장합니다. 마스터와 슬레이브 모두 복제본 오프셋과 마스터 ID를 저장합니다.

마스터와 슬레이브 사이의 네트워크 연결이 끊어지면 슬레이브는 마스터가 마지막 복제본 오프셋부터 계속 복사하도록 합니다.

그러나 해당 오프셋을 찾을 수 없으면 재동기화가 수행됩니다.

디스크 없는 복제

마스터가 메모리에 직접 RDB를 생성한 다음 이를 슬레이브에 보냅니다. 로컬에 디스크를 저장하지 않습니다

　 repl-diskless-sync

repl-diskless -sync-delay, 더 많은 슬레이브가 다시 연결될 때까지 기다려야 하기 때문에 복제를 시작하기 전에 일정 시간 동안 기다립니다.

만료된 키 처리

　슬레이브는 키를 만료시키지 않고 키만 만료시킵니다. 마스터가 키를 만료할 때까지 기다립니다.

마스터가 키를 만료하거나 LRU를 통해 키를 제거하면 del 명령이 시뮬레이션되어 슬레이브에 전송됩니다.

복제의 전체 과정

슬레이브 노드가 시작되고 마스터 노드의 호스트와 IP를 포함한 마스터 노드의 정보만 저장됩니다(redis.conf에서 Slaveof로 구성됨).

슬레이브 노드 내부에는 연결하고 복사할 새로운 마스터 노드가 있는지 매초 확인하는 예약된 작업이 있습니다. 발견되면 마스터와 소켓 네트워크 연결을 설정합니다. node

슬레이브 노드가 마스터 노드에 ping 명령을 보냅니다
　비밀번호 인증, 마스터가 requirepass를 설정하면 슬레이브 노드는 인증을 위해 masterauth 비밀번호를 보내야 합니다
　마스터 노드는 첫 번째 전체 복제를 수행합니다. 시간을 두고 모든 데이터를 슬레이브 노드로 보냅니다
　마스터 노드는 앞으로도 계속 명령을 작성하여 슬레이브 노드에 비동기 복사합니다

데이터 동기화와 관련된 핵심 메커니즘

은 슬레이브가 msater에 처음으로 연결될 때 수행되는 전체 복사 및 해당 프로세스의 일부 세부 메커니즘

(1) 마스터와 슬레이브 모두 오프셋을 유지합니다

마스터는 지속적으로 자체적으로 오프셋을 축적합니다. , 그리고 슬레이브도 계속해서 자신에게 오프셋을 축적합니다

슬레이브는 매초 마스터에게 자신의 오프셋을 보고하고, 마스터도 각 슬레이브의 오프셋을 저장합니다
이는 구체적으로 오프셋을 저장한다는 의미는 아닙니다. 전체 복제에 사용되는 가장 큰 이유는 마스터와 슬레이브 모두 서로의 데이터 불일치를 알기 위해 자신의 데이터 오프셋을 알아야 하기 때문입니다

(2) 백로그

마스터 노드 백로그가 있고 기본 크기는 1MB입니다.

마스터 노드가 슬레이브 노드에 데이터를 복사할 때 백로그에 동기적으로 데이터 복사본도 기록합니다.
백로그는 전체 복제 시 증분 복제에 주로 사용됩니다. is Interrupted
(3) master run id

Info 서버에서 master run id

를 볼 수 있습니다. 호스트+IP를 기반으로 마스터 노드를 찾으면 마스터 노드가 다시 시작되면 신뢰할 수 없습니다. 또는 데이터가 변경되면 다른 실행 ID에 따라 슬레이브 노드를 구별해야 합니다. 실행 ID가 다른 경우 실행 ID를 변경하지 않고 Redis를 다시 시작해야 하는 경우 redis-cli를 사용할 수 있습니다. debug reload command
(4) psync
슬레이브 노드는 psync를 사용하여 마스터 노드에서 복사합니다. psync runid offset

마스터 노드는 자체 상황에 따라 응답 정보를 반환합니다. 전체 복제를 트리거하는 runid 오프셋이거나 계속 증분 복사

전체 복사일 수 있습니다.

　마스터는 bgsave를 실행하고 로컬에서 rdb 스냅샷 파일을 생성합니다
　마스터 노드는 rdb 스냅샷 파일을 슬레이브 노드로 보냅니다. rdb 복사 시간이 60초(repl-timeout)를 초과하면 슬레이브 노드는 이 매개변수는 적절하게 조정될 수 있습니다.
기가비트 네트워크 카드가 있는 시스템의 경우 일반적으로 100MB, 6G 파일이 초당 전송되며 이는 60초를 초과할 가능성이 높습니다
마스터 노드가 RDB를 생성하면 캐시됩니다. 메모리의 모든 새로운 쓰기 명령, salve 노드가 rdb를 저장한 후 새 쓰기 명령을 salve 노드
　client-output-buffer-limit 슬레이브 256MB 64MB 60, 메모리 버퍼가 계속해서 64MB 이상을 소비하는 경우 256MB를 초과하면 복사를 중지하고 복사에 실패합니다
슬레이브 노드가 rdb를 수신한 후 이전 데이터를 삭제한 다음 rdb를 자체 메모리에 다시 로드하고, same time은 이전 데이터 버전을 기반으로 외부 서비스를 제공합니다
슬레이브 노드가 AOF가 켜져 있으면 BGREWRITEAOF가 즉시 실행되어 AOF를 다시 작성합니다

증분 복사

마스터가- 전체 복사 프로세스 중에 슬레이브 네트워크 연결이 끊어진 후 슬레이브가 마스터에 다시 연결되면 증분 복제가 시작됩니다.
마스터는 자신의 백로그에서 손실된 데이터의 일부를 직접 가져와 슬레이브 노드로 보냅니다. 기본 백로그는 1MB입니다.
msater는 슬레이브가 보낸 psync의 오프셋을 기반으로 백로그에서 데이터를 얻습니다. BHeartBeat

메인 노드는 HeartBeat 정보를 보냅니다.

마스터는 기본적으로 10초마다 HeartBeat를 보냅니다. Node는 1초마다 HeartBeat를 보냅니다

비동기 사본을 보냅니다.

　마스터가 쓰기 명령을 받을 때마다 이제 내부적으로 데이터를 쓴 다음 비동기적으로 슬레이브 노드에 보냅니다

위 내용은 Redis의 높은 동시성을 보장하는 방법을 알고 계십니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!