버퍼는 메모리 공간의 일부입니다. 즉, 메모리 공간에는 일정량의 저장 공간이 예약되어 있으며, 이 저장 공간은 입력 또는 출력 데이터를 버퍼링하는 데 사용됩니다.
Redis에는 버퍼 개념이 사용되는 세 가지 주요 시나리오가 있습니다.
클라이언트와 서버 간 통신 시 클라이언트가 보낸 명령 데이터나 서버가 클라이언트로 반환한 데이터 결과를 임시로 저장하는 데 사용됩니다. 마스터 노드와 슬레이브 노드 간 데이터 동기화를 수행할 때 Redis는 버퍼를 사용합니다. 마스터 노드에서 수신한 쓰기 명령과 데이터를 임시로 저장하기 위해 Redis는 AOF 지속성을 수행할 때 잦은 디스크 쓰기를 방지하기 위해 버퍼 개념도 사용합니다.
버퍼 개념은 원래 운영 체제에서 데이터 간의 불일치를 완화하기 위해 사용되었습니다. CPU 및 I/O 장치 속도 CPU 및 I/O 장치의 병렬성을 향상시키기 위해 일치 모순이 도입되었습니다.
고속 장치와 저속 장치의 불일치로 인해 고속 장치는 필연적으로 저속 장치를 기다리는 데 시간을 소비하게 됩니다. 버퍼의 개념은 이 문제를 매우 잘 해결할 수 있습니다. 버퍼는 생산자-소비자 모델의 중요한 구현이기도 합니다.
qubf-free가 소진되면 클라이언트 입력 버퍼가 오버플로됩니다. Redis의 처리 방법은 클라이언트 연결을 종료하는 것이며 결과는 다음과 같습니다. 비즈니스 프로그램 데이터에 접근할 수 없습니다.
일반적으로 클라이언트 연결이 차지하는 총 메모리 양이 Redis의 최대 메모리 구성을 초과하면 Redis가 액세스에 영향을 미칩니다. 비즈니스 프로그램의 성능.
클라이언트가 여러 개라도 Redis가 너무 많은 메모리를 차지하게 되고 메모리 오버플로 문제가 발생하여 Redis가 중단될 수도 있습니다.
입력 버퍼와 출력 버퍼라는 두 개의 클라이언트 버퍼가 더 있으며, 둘 다 클라이언트와 서버 간의 요청 전송 및 처리 속도 불일치를 해결하기 위해 설정됩니다.
입력 버퍼는 클라이언트가 보낸 명령을 임시로 저장합니다. 오버플로가 발생하는 일반적인 이유는 두 가지입니다.
수백만 개의 해시를 쓰거나 한 번에 데이터를 설정하는 등 BigKey를 작성하면 서버가 버퍼 크기를 초과합니다. 요청을 너무 느리게 처리하여 차단이 발생하고 요청을 제때에 처리할 수 없게 되어 클라이언트가 보낸 요청이 점점 더 많이 버퍼에 쌓이게 됩니다.
출력 버퍼는 Redis 메인 스레드가 클라이언트에 반환할 데이터를 임시로 저장합니다.
이 데이터에는 단순하고 고정된 크기의 OK 응답(예: SET 명령 실행) 또는 오류 메시지뿐만 아니라 다양한 크기와 특정 데이터가 포함된 실행 결과(예: HGET 명령 실행)가 포함됩니다.
공통 출력 buffers 오버플로가 발생하는 세 가지 이유는 다음과 같습니다.
BigKey 결과가 너무 많이 반환됨 불합리한 명령 실행 버퍼 크기 설정이 불합리함
입력 및 출력 버퍼에서 오버플로가 발생하는 일반적인 원인으로 판단하면 BigKey가 오버플로의 가장 가능성이 높은 원인입니다. 이유가 있으므로 BigKey를 사용하지 않도록 노력해야 합니다.
입력 버퍼의 경우 크기(클라이언트당 기본 1G)를 변경할 수 있는 방법이 없기 때문에 최대한 차단되지 않도록 명령의 전송 및 처리 속도만 제어할 수 있습니다.
출력 버퍼의 경우 KEYS, MONITOR 등과 같이 많은 수의 결과를 반환하는 일부 명령을 사용하지 마세요. 동시에 출력 버퍼의 크기를 조정하여 오버플로를 방지할 수 있습니다.
복사 버퍼는 Redis 마스터 노드와 슬레이브 노드 간 복사에 사용됩니다. 마스터와 슬레이브 노드 간의 데이터 복제에는 전체 복제와 증분 복제가 포함되기 때문입니다. 따라서 복사 버퍼도 복사 버퍼와 복사 백로그 버퍼의 두 가지 유형으로 구분됩니다.
전체 복제 과정에서 마스터 노드는 RDB 파일을 슬레이브 노드로 전송하는 동안 클라이언트가 보낸 쓰기 명령 요청을 계속 수신합니다. 이러한 쓰기 명령은 먼저 복제 버퍼에 저장되며, RDB 파일 전송이 완료된 후 슬레이브 노드로 전송되어 실행됩니다. 마스터 노드와 슬레이브 노드 간의 데이터 동기화를 보장하기 위해 각 슬레이브 노드는 마스터 노드에 복제 버퍼를 유지합니다.
복사 버퍼의 경우 메인 라이브러리가 RDB 파일을 전송하고 슬레이브 라이브러리에서 RDB 파일을 로드하는 데 시간이 오래 걸리고 동시에 메인 라이브러리가 쓰기 명령 작업을 많이 받으면, 복사 버퍼가 가득 차서 오버플로될 수 있습니다.
복제 버퍼 오버플로를 방지하기 위해 한편으로는 마스터 노드에 의해 저장되는 데이터의 양을 제어할 수 있습니다. 이를 통해 RDB 파일 전송 속도와 슬레이브 라이브러리 로딩 시간을 단축하여 너무 많은 명령이 누적되는 것을 방지할 수 있습니다. 복제 버퍼에서.
또한 마스터 노드의 데이터 볼륨, 마스터 노드의 쓰기 부하 압력 및 오버플로를 방지하기 위한 마스터 노드 자체의 메모리 크기를 기반으로 오버플로를 방지하기 위해 복제 버퍼의 크기를 보다 합리적으로 설정할 수 있습니다. 마스터 노드는 각 슬레이브 노드의 크기를 설정하므로 복제 버퍼의 경우 클러스터에 슬레이브 노드가 너무 많으면 마스터 노드의 메모리 오버헤드가 매우 커지므로 슬레이브가 너무 많지 않도록 노력해야 합니다. 하나의 마스터 노드에 대한 노드.
증분 복제 과정에서 마스터 노드와 슬레이브 노드가 정기적으로 동기화를 수행하면 쓰기 명령이 복제 버퍼에 임시 저장됩니다. 슬레이브 노드와 마스터 노드 사이에 네트워크 단절이 발생하는 경우, 슬레이브 노드가 다시 연결된 후 복제 백로그 버퍼에서 아직 복제되지 않은 명령 작업을 동기화할 수 있습니다.
복사 백로그 버퍼는 크기가 제한된 링 버퍼라는 점에 유의해야 합니다.
마스터 노드가 복제 백로그 버퍼를 가득 채우면 버퍼에 있는 이전 명령 데이터를 덮어쓰게 됩니다. 이때 마스터 노드와 슬레이브 노드의 데이터는 일치하지 않습니다.
이 문제에 대한 일반적인 해결책은 복사 백로그 버퍼의 크기를 늘리는 것입니다. 일반적으로 이 크기의 계산 방법을 사용할 수 있습니다.
缓冲区大小=(主库写入命令速度 * 操作大小 - 主从库间网络传输命令速度 * 操作大小)* 2
동시 요청 수가 너무 많으면 버퍼 크기를 조정할 수 없습니다. 그런 다음 슬라이싱 클러스터를 사용하여 문제를 해결할 수 있습니다.
AOF 버퍼는 AOF 지속성을 위해 Redis에서 설정한 버퍼이며 AOF 버퍼와 AOF 재작성 버퍼도 있습니다.
우리 모두는 SSD의 경우에도 읽기 및 쓰기 속도가 메모리의 속도와 많이 다르다는 것을 알고 있습니다. AOF 버퍼는 주로 메인 프로세스의 명령 실행 속도와 디스크 쓰기 속도 간의 동기화 문제를 해결하기 위해 Redis에 의해 설정됩니다. AOF 버퍼는 하드 디스크의 빈번한 읽기 및 쓰기를 효과적으로 방지하여 성능을 향상시킬 수 있습니다. AOF 지속성을 수행할 때 Redis는 먼저 명령을 AOF 버퍼에 쓴 다음 다시 쓰기 정책에 따라 하드 디스크 AOF 파일에 씁니다.
AOF 버퍼의 오버플로는 디스크 쓰기 속도와 관련이 있을 수도 있고, AOF 다시 쓰기 전략과 관련이 있을 수도 있습니다. AOF 버퍼에 많은 수의 명령이 백로그되어 설정된 임계값을 초과하는 경우입니다. , 버퍼 오버플로가 발생하므로 이 문제를 방지하려면 쓰기 저장 전략을 조정하거나 AOF 버퍼 크기를 조정하여 해결할 수 있습니다.
AOF 재작성 버퍼는 Redis가 하위 프로세스에서 AOF 재작성을 수행할 때 상위 프로세스가 새 명령을 수락할 때 해당 명령이 하위 프로세스 이후까지 AOF 재작성 버퍼에 기록됩니다. 프로세스 재작성이 완료되면 새 AOF 파일에 AOF 재작성 버퍼 명령을 추가합니다.
AOF 다시 쓰기 버퍼의 오버플로는 AOF 다시 쓰기 중에 기본 프로세스에서 처리하는 명령 수와 관련이 있습니다. Redis 기본 프로세스가 AOF 다시 쓰기 중에 많은 수의 명령을 처리하면 이러한 명령이 AOF 재작성 버퍼 영역, 설정된 임계값을 초과하면 오버플로가 발생합니다.
AOF 재작성 버퍼의 오버플로를 방지하기 위해 AOF 재작성 버퍼의 크기를 조정하여 해결할 수도 있습니다.
위 내용은 Redis 버퍼 오버플로를 해결하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!