HTTP 500 문제를 해결하는 방법: 실제 프로젝트에서 php+redis 관련 내부 서버 오류-PHP 튜토리얼-php.cn

HTTP 500 문제를 해결하는 방법: 실제 프로젝트에서 php+redis 관련 내부 서버 오류

墨辰丷

풀어 주다： 2023-03-28 08:08:01

원래의

1842명이 탐색했습니다.

사용자 수가 급격히 늘어나고, 빠른 시간 내에 방문 횟수도 두 배로 늘어났습니다. 초기 용량 계획이 좋았기 때문에 하드웨어 자원으로는 지원할 수 있지만 소프트웨어 시스템에는 큰 문제가 있습니다: 40. 요청 중 %가 HTTP 500을 반환합니다: 내부 서버 오류

문제 설명
사용자 수가 빠르게 증가하고 있으며, 초기 용량 계획이 잘 되어 있어 방문 횟수가 단기간에 두 배로 늘어났습니다. 하드웨어 리소스에서는 지원할 수 있지만 소프트웨어 시스템에는 큰 문제가 있습니다.
요청의 40%가 Return HTTP 500: Internal Server Error
로그를 확인해보니 해당 오류가 PHP의 연결 처리에 있는 것으로 나타났습니다. <-> Redis
디버깅 처리

처음
처음에는 근본 원인을 찾을 수 없었으나, 다음과 같은 다양한 오류 관련 방법을 시도해 볼 수 있습니다.
PHP 연결 수를 늘리고 시간 제한을 500ms에서 2.5초로 늘립니다.
PHP 설정에서 default_socket_timeout을 비활성화합니다.
호스트 시스템에서 SYN 쿠키를 비활성화합니다.
Redis 및 웹 서버 확인 파일 설명자 수를 확인합니다. 호스트 시스템의 mbbuffer를 늘립니다.
TCP 백로그 수를 조정합니다
.. .

여러 가지 방법을 시도했지만 모두 효과가 없습니다

두 번째이 문제를 시험판 환경에서 재현하고 싶지만 안타깝게도 여전히 실패했습니다. 아마도 트래픽이 재현할 만큼 크지 않기 때문일 것입니다

세 번째 코드에서 Redis 연결이 닫히지 않은 것은 아닐까요?
일반적으로 PHP는 실행이 끝나면 자동으로 리소스 연결을 닫지만 이전 버전에서는 메모리 누수가 발생할 수 있습니다. 안전을 위해 코드를 수정하고 연결을 수동으로 닫으세요
결과는 여전히 유효하지 않습니다

4번째 의심 대상: phpredis 클라이언트 라이브러리
A/B 테스트를 하고, predis 라이브러리를 교체하고, 데이터센터 사용자의 20%에게 배포합니다.
코드 구조가 좋아서 교체 작업이 완료되었습니다. 빨리
결과가 나왔습니다. 아직은 유효하지 않지만 좋은 면이 있습니다. phpredis

5번째Redis 버전을 확인해 보니 v2.6이더군요. 당시 버전은 v2.8.9
Redis를 업그레이드하고 시도해 보세요. 업그레이드 후에도 여전히 작동하지 않습니다
괜찮아요. 낙관적으로 생각하세요. Redis 버전을 최신 버전으로 업그레이드하는 방법은 아닙니다

6번째문서를 많이 검색해서 공식 문서인 Redis Software Watchdog에서 좋은 디버깅 방법을 찾았고, 개봉 후 실행:

$ redis-cli --latency -p 6380 -h 1.2.3.4
min: 0, max: 463, avg: 2.03 (19443 samples)

로그인 후 복사

Redis 로그 보기:

...
[20398] 22 May 09:20:55.351 * 10000 changes in 60 seconds. Saving...
[20398] 22 May 09:20:55.759 * Background saving started by pid 41941
[41941] 22 May 09:22:48.197 * DB saved on disk
[20398] 22 May 09:22:49.321 * Background saving terminated with success
[20398] 22 May 09:25:23.299 * 10000 changes in 60 seconds. Saving...
[20398] 22 May 09:25:23.644 * Background saving started by pid 42027
...

로그인 후 복사

발견 문제:

몇 분마다 데이터를 하드 디스크에 저장합니다. 백그라운드 저장소를 분기하는 데 약 400ms가 걸리는 이유는 무엇입니까? (위 로그에서 첫 번째 및 두 번째 항목의 시간을 볼 수 있습니다.)

이 시점에서 나는 마침내 문제의 원인을 찾았습니다. Redis 인스턴스에 많은 양의 데이터가 있기 때문에 각 지속성 작업에 대해 백그라운드 프로세스를 포크하는 데 시간이 많이 걸리고 비즈니스에서 키가 수정되는 경우가 많습니다. 해결 방법: 지속성을 위해 별도의 슬레이브를 사용하십시오. 이 슬레이브는 실제 트래픽 요청을 처리하지 않으며, 유일한 기능은 이전 Redis 인스턴스의 지속성 작업을 이 슬레이브로 전송하는 것입니다.

효과는 매우 확실하고 문제는 기본적으로 해결되었으나 여전히 오류가 보고되는 경우가 있습니다

7번째

가능한 문제 해결 Redis의 느린 쿼리를 차단하면 어딘가에 * 키가 사용되는 것으로 나타났기 때문입니다. Redis에 점점 더 많은 데이터가 있으면 이 명령은 자연스럽게 심각한 차단을 발생시킵니다.

8번째
이전 조정 후 문제는 다음 달에도 해결되었습니다. 트래픽이 계속 증가하면 견딜 수 있었습니다

그러나 그들은 새로운 문제를 깨달았습니다.

현재 방법은 요청이 오면 Redis 연결을 만들고 여러 명령을 실행한 다음 요청 볼륨이 끊어지면 연결을 끊는 것입니다. 규모가 크므로 이 방법은 심각한 성능 낭비를 초래합니다. 명령의 절반 이상이 연결 작업을 처리하는 데 사용되어 비즈니스 논리 처리를 초과하고 Redis도 느려지게 합니다.

해결책: Twitter의 twemproxy를 도입했습니다. 각 웹 서버에 프록시만 설치하면 됩니다. twemproxy는 Redis 인스턴스와의 지속적인 연결을 담당하므로 연결 작업이 크게 줄어듭니다. 키, 플러시올 등의 명령효과는 자연스럽게 완벽하여 더 이상 이전 연결 오류에 대해 걱정할 필요가 없습니다

9번째

데이터 전달 최적화를 계속하기 위한 샤딩:

다른 컨텍스트에서 데이터 분할 및 격리

일관된 해시 동일한 컨텍스트에서 데이터 샤딩

효과:

각 머신의 요청 및 부하 감소

캐시 신뢰성 향상 안전성, 노드 장애에 대해 걱정할 필요 없음

위 내용은 이 기사의 전체 내용이므로 도움이 되기를 바랍니다. 모두의 배움에.