Redis 성능에 어떤 문제가 있나요?

다음은 Redis의 일반적인 성능 문제인가요?

마스터는 메모리 스냅샷을 작성하고 save 명령은 메인 스레드의 작업을 차단하는 rdbSave 함수를 예약합니다. 스냅샷이 상대적으로 크면 성능에 미치는 영향이 매우 크며, 서비스가 간헐적으로 중단되므로 마스터 쓰기 메모리 스냅샷을 사용하지 않는 것이 가장 좋습니다. (추천 학습: Redis 비디오 튜토리얼)

마스터 AOF 지속성. AOF 파일을 다시 작성하지 않으면 이 지속성 방법은 성능에 가장 작은 영향을 미치지만 AOF 파일은 계속해서 증가하고 AOF 파일은 너무 크면 마스터 재시작의 복구 속도에 영향을 미칩니다.

마스터는 AOF 파일을 다시 쓰기 위해 BGREWRITEAOF를 호출합니다. AOF는 다시 쓰는 동안 많은 양의 CPU와 메모리 리소스를 차지하므로 과도한 서비스 로드가 발생하고 일시적인 서비스 중단이 발생합니다.

다음은 실제 프로젝트 중 하나의 상황입니다. 일반적인 상황은 다음과 같습니다.

마스터 1개, 슬레이브 4개, 샤딩 메커니즘 없음, 읽기 및 쓰기 분리만 담당하며 마스터는 쓰기 작업과 AOF 로그 백업은 5G 정도이고, 마스터가 BGREWRITEAOF를 호출하면 마스터와 슬레이브의 로드가 갑자기 증가하므로 기본적으로 응답이 지속되지 않습니다. 약 5분 동안 슬레이브의 읽기 요청이 절반 이상 응답하지 않습니다. 위의 상황은 마스터 머신이 슬레이브였기 때문에 발생하지 않을 것입니다. 매일 오전 10시에 AOF 파일을 다시 작성하기 위해 BGREWRITEAOF를 호출하는 예약된 작업이 발생했습니다. 나중에 마스터 시스템이 다운되었습니다. , 백업 슬레이브를 마스터로 잘라냈지만 이 예약된 작업을 삭제하는 것을 잊어버렸고 이로 인해 위의 비극이 발생했습니다. 상황입니다. 원인을 찾는 데 며칠이 걸렸습니다.

이 문제를 완화하려면 no-appendfsync-on-rewrite 구성을 yes로 설정하세요. yes로 설정하면 다시 쓰기 중에 새 쓰기 작업이 fsyncd되지 않으며 쓰기 전에 다시 쓰기가 완료될 때까지 메모리에 임시 저장됩니다. 마스터의 AOF 백업 기능을 활성화하지 않는 것이 가장 좋습니다.

Redis 마스터-슬레이브 복제의 성능 문제, 슬레이브 대 마스터 동기화의 첫 번째 구현은 다음과 같습니다. 슬레이브가 마스터로 동기화 요청을 보내고, 마스터는 먼저 rdb 파일을 덤프한 다음 전체 rdb 파일을 슬레이브로 전송합니다. 그런 다음 마스터가 이를 캐시합니다. 명령이 슬레이브에 전달되고 초기 동기화가 완료됩니다. 두 번째 및 후속 동기화 구현은 다음과 같습니다. 마스터는 변수의 스냅샷을 실시간으로 각 슬레이브에 직접 보냅니다. 슬레이브와 마스터의 연결이 끊어졌다가 다시 연결되는 원인이 무엇이든 위의 프로세스가 반복됩니다. Redis의 마스터-슬레이브 복제는 슬레이브가 있는 한 메모리 스냅샷의 지속성을 기반으로 합니다. Redis는 디스크 IO 제한으로 인해 마스터-슬레이브 복제가 비차단이라고 주장하지만 마스터 스냅샷 파일이 상대적으로 크면 덤프에 시간이 오래 걸릴 수 있습니다. 요청은 서비스가 중단됨을 의미하며, 중요한 서비스의 경우 이로 인한 결과도 끔찍합니다.

위 1.2.3.4 근본적인 문제의 원인은 모두 시스템 IO 병목 현상 문제와 불가분의 관계에 있습니다. 즉, 하드 디스크 읽기 및 쓰기 속도가 충분히 빠르지 않고 주요 프로세스 fsync()/write() 작업이 막힌.

단일 실패 지점 문제, 현재 Redis의 마스터-슬레이브 복제가 충분히 성숙되지 않았기 때문에 현재는 다음과 같은 명백한 단일 실패 지점 문제가 있습니다. 예: 활성 복제. , Proxy는 Master를 Slave Wait로 교체하는 것을 실현합니다. 이는 Redis 작성자의 현재 우선 순위 작업 중 하나이기도 합니다.

Redis 관련 기술 기사를 더 보려면 Redis 데이터베이스 사용 튜토리얼 소개 칼럼을 방문하여 알아보세요!

위 내용은 Redis 성능에 어떤 문제가 있나요?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!