Predis: 서버에서 줄을 읽는 동안 오류와 함께 오래 실행되는 blpop이 충돌합니다.

이것은 버그가 아니라 잘못된 구성일 가능성이 높습니다. 다음 단계 에 따라 Redis와 Predis가 모두 장기간 유휴 연결에 대해 올바르게 구성되었는지 확인하고 여전히 문제가 있는 경우 이 티켓에 대해 다시 보고하세요.

300초 후에 유휴 클라이언트를 닫지 않도록 Redis를 구성하고(redis.conf를 편집하고 시간 초과 항목을 0으로 설정하여 이를 수행할 수 있음) predis\Client의 생성자에 전달된 서버 매개변수 배열/문자열에 read_write_timeout => 0을 추가합니다. .

나는 할 수 있지만 그렇게 해서는 안 된다고 생각한다.
나는 redis가 유휴 연결을 닫는 것이 매우 제정신이라고 생각합니다.
반면에 일종의 가비지 수집으로
클라이언트가 새 연결을 사용하여 재시도할 수 있을 만큼 똑똑해야 한다고 생각합니다.

이것은 차단 호출이기 때문에 유휴 상태로 표시되는 것을 피하기 위해 주기적으로 ping을 수행할 수 없습니다.
비슷한 시나리오에 직면했을 때 클라이언트가 더 많은 작업을 수행하도록 제안합니다.
php-mysql을 예로 들어보겠습니다.

http://php.net/manual/en/function.mysql-ping.php

서버 연결을 Ping 하거나 연결 이 없는 경우 다시 연결

php-mysql에서 이전 mysql 연결을 사용할 수 있으며, 여러 가지 이유로 해당 연결이 시간 초과되거나 닫힐 수 있습니다.
ping을 하면 다시 연결됩니다

연결이 재설정되거나 닫힐 때 Predis가 수행해야 하는 작업
$_reconnecting=1이라고 가정해 봅시다.
그런 다음 이전 연결을 대체하는 새 연결을 만든 다음 ping
그런 다음 blpop으로 진행하십시오.

$_reconnecting===1 동안 이 문제에 다시 직면하면 오류가 발생합니다.

사실 Redis 2.6부터 $ redis.conf 의 timeout 구성은 기본적으로 0 로 설정됩니다.

어쨌든, 여전히 유휴 연결에 대한 시간 초과 설정을 선호하는 경우 BLPOP redis.conf (예: BLPOP list 200 ), 따라서 목록에 요소가 푸시되지 않은 경우 200초 후에 명령이 NULL 를 반환하도록 합니다. BLPOP 가 루프 안에 있고 NULL 를 반환하면 즉시 루프를 다시 시작하여 스크립트가 목록에서 유효한 값이 나올 때까지 기다리게 할 수 있습니다. 이 접근 방식은 기본적으로 명시적 핑 및 자동 재연결을 무용지물로 만들고 뒤에서 일어나는 마술에 의존하지 않고 스크립트의 동작을 훨씬 더 많이 제어할 수 있습니다.

추신: Predis는 오류가 발생하기 쉽고 MULTI/EXEC, pubsub 또는 파이프라인과 같은 복잡한 상태에서 예기치 않은 동작으로 이어지기 때문에 자동 재연결을 지원하지 않습니다.

사실 Redis 2.6부터 redis.conf의 시간 초과 구성은 기본적으로 0으로 설정됩니다.

나는 redis 서버가 최대 제한에 도달했기 때문에 새로운 연결을 수락하지 못하게 할 수 있는 영원히 살아있는 redis 서버에 연결이 끊어지는 것을 두려워합니다(conf에 없는 경우 프로세스당 최대 열린 연결에 대한 커널 제한에 있을 수 있음)

여전히 유휴 연결에 대한 시간 초과 설정을 선호하는 경우 redis.conf(예: BLPOP 목록 200)에 지정된 시간 초과보다 짧은 모니터링된 키에 대한 시간 초과를 사용하여 BLPOP을 수행할 수 있습니다.

데이터베이스에서 solr로 증분 인덱싱을 수행하는 또 다른 경우가 있습니다.
우리는 redis에서 마지막 포인트를 읽습니다.
시간이 많이 걸리는 인덱싱을 수행한 후 새 포인트를 redis에 저장합니다.
읽기와 쓰기 사이의 시간이 길기 때문에 Predis가 충돌합니다.

추신: Predis는 오류가 발생하기 쉽고 MULTI/EXEC, pubsub 또는 파이프라인과 같은 복잡한 상태에서 예기치 않은 동작으로 이어지기 때문에 자동 재연결을 지원하지 않습니다.

내가 제안한 방식에 유의하십시오. $_reconnecting=1 플래그로 인해 무한 루프에 빠지지 않습니다.
또한 새 연결이 유효한 핑을 반환하지 않는 한 새 연결은 완료된 것으로 간주되지 않습니다.

일부 명령이 의도적으로 다시 연결하는 것이 비논리적이라면 일부 명령을 재연결 가능이라고 부를 수 있습니다.
일부 명령을 해시 가능 ... 등으로 표시한 것으로 나타났습니다.

redis 서버에서 연결이 끊길까봐 최대 제한에 도달하여 새 연결을 수락하지 못하게 할 수 있습니다(conf에 없는 경우 프로세스당 최대 열린 연결의 커널 제한에 있을 수 있음).

응용 프로그램에서 잘못된 작업이나 예기치 않은 작업을 수행하지 않는 한 영원히 살 수 없으므로 이러한 경우에 문제가 있는 위치를 확인하는 것이 좋습니다. 또는 pub/sub 또는 BRPOP/BLOP 시나리오에 대해 잠재적으로 많은 유휴 연결이 필요할 수 있습니다. 이 경우 마스터/슬레이브 복제에 의존하고 구독자에 대해 다른 슬레이브를 사용해야 할 수 있습니다.

데이터베이스에서 solr로 증분 인덱싱을 수행하는 또 다른 경우가 있습니다.
우리는 redis에서 마지막 포인트를 읽습니다.
시간이 많이 소요되는 인덱싱을 수행한 후 새 포인트를 redis에 저장합니다.
읽기와 쓰기 사이의 시간이 길기 때문에 Predis가 충돌합니다.

$client->disconnect() 를 수행하고 시간이 많이 소요되는 인덱싱을 수행한 다음 $client->connect() 를 수행할 수 있습니다(또는 Predis가 첫 번째 명령 시 서버 연결을 처리하도록 함). 그러나 다시 훨씬 더 예측 가능한 동작이며, 실제로 필요하지 않을 때 Redis에 너무 많은 연결을 열어두는 것에 대한 두려움과도 일맥상통합니다.

일부 명령이 의도적으로 다시 연결하는 것이 비논리적이라면 일부 명령을 재연결 가능이라고 부를 수 있습니다.
일부 명령을 해시 가능 ... 등으로 표시한 것으로 나타났습니다.

이것은 명령 파이프라이닝에서 작동하지 않으며 MULTI / EXEC 컨텍스트에서 예측할 수 없는 동작으로 이어집니다(연결이 끊어지면 전체 트랜잭션이 분명히 서버에서 삭제됨). 반면에 명령을 해싱하는 것은 클라이언트/컨텍스트/기본 연결의 상태에 의존하지 않는 것입니다.

먼저 나는 당신에게 빠른 응답과 문제를 따를 것입니다.

둘째, multi/exec가 다시 연결되어서는 안 된다는 데 동의합니다.

하지만 다른 명령은 정상적인 방식으로 다시 연결해야 한다고 생각합니다(예: get/set 또는 blpop).

우리는 Yii의 CRedisCache를 사용하고 있으며 연결을 캐시하는 getter를 사용합니다.
그리고 새로운 것을 생성하게 할 방법이 없다.

    public function getRedis()
    {
        if($this->_cache!==null)
            return $this->_cache;
        else{
            // to use the old single file approach comment out the next two lines and uncomment the 3rd
            require_once Yii::getPathOfAlias($this->predisPath).'/Autoloader.php';
            Predis\Autoloader::register();
            //require_once Yii::getPathOfAlias($this->predisPath).'.php'; // old single file approach,no autoloading
            Yii::log('Opening Redis connection',CLogger::LEVEL_TRACE);
            return $this->_cache=new Predis\Client($this->servers);
        }
    }

당신은 이것이 그들의 문제라고 말할 수도 있고, 연결 해제/연결/핑 ..etc를 추가하는 것은 우리 검색 팀의 문제라고 말할 수도 있습니다.

하지만 나는 _관심 분리_원칙에 대해 생각하고 싶습니다. 우리 검색 팀은 결코 깊이 들어가 redis 구성 요소가 작동하는 방식을 알아야 합니다. 키를 가져오고 설정해야 합니다.

이것이 Predis를 방탄으로 만드는 부분인 것 같아요.

죄송합니다. 하지만 Predis에 자동 재연결 기능을 추가하지 않을 것입니다 :-) 이것은 아마도 오래전부터 고정된 몇 안 되는 사항 중 하나일 것이며 여전히 귀하의 제안이 예측할 수 없는 행동으로 해킹된 구현으로 이어질 것이라고 생각합니다. . 귀하와 같은 특정 요구 사항은 구현하는 최종 개발자에게 달려 있습니다. 이것이 Predis가 극도로 모듈화되도록 설계된 바로 그 이유입니다.

시나리오에서 기본 연결 클래스 Predis\Network\StreamConnection 를 확장하여 executeCommand() 가 try ... catch 블록 내부에 상위 메서드를 래핑하도록 만들 수 있습니다. 이렇게 하면 다시 연결하고 다시 보낼 수 있습니다. 서버에 대한 연결이 끊어졌을 때의 명령입니다. 화이트리스트 접근 방식을 사용하여 이와 같이 작동해야 하는 명령을 결정할 수도 있습니다. README 에 설명된 대로 새로 생성된 연결 클래스를 클라이언트 인스턴스에 등록할 수 있습니다.

이 접근 방식이 도움이 될까요?

추신: 이 문제를 닫고 #75, 몇 가지 팁이 필요한 경우 개인 이메일로 이동할 수 있습니다.

죄송합니다. 하지만 Predis에 자동 재연결 기능을 추가하지 않을 것입니다 :-) 이것은 아마도 오래전부터 고정된 몇 안 되는 사항 중 하나일 것이며 여전히 귀하의 제안이 예측할 수 없는 행동으로 해킹된 구현으로 이어질 것이라고 생각합니다. .

redis의 작성자가 귀하의 의견에 동의하는 것 같습니다.

https://twitter.com/antirez/status/207117083790684161

이것이 실제로 어떻게 위험인지 알 수 없습니다. 응용 프로그램에서 연결이 누출되는 경우 수정 사항은 IMHO 시간 초과가 아닙니다.

https://twitter.com/antirez/status/207122021665091584

사용자는 해당 기본값을 자유롭게 변경할 수 있습니다. 0이 아닌 기본값은 재연결 시 해결되는 것보다 더 많은 문제를 생성한다고 생각합니다.

그러나 0 시간 초과를 사용하기 전에 php mysql 모듈에 대한 이전 경험에 대한 우려가 있습니다.

옛날 옛적에 mysql 서버는 웹 서버 중 하나(최대 사용자 연결 초과)를 블랙리스트에 올렸습니다. php 치명적인 오류가 있어서 php 스크립트가 스크립트가 연결을 닫는 라인에 도달하는 것을 방지하고 많은 사람들이 웹 서버를 방문하기 때문입니다. 많은 연결이 열렸지만 아무도 연결을 제대로 닫지 않았습니다.

$n=null;
$c=foo_connect();
$n->do_something() ; // fatal error
foo_close($c);

물론 OS는 프로세스가 종료될 때 연결을 닫지만 많은 경우에 php가 있는 프로세스는 오래 지속되는 데몬입니다(예: 미리 포크된 apache 프로세스, php fast cgi 데몬, php-fpm 데몬, ..etc) ) 즉, 프로세스가 종료되지 않았기 때문에 OS는 해당 연결을 닫지 않습니다(스크립트만 종료됨).

Salvatore Sanfilippo(redis의 저자)에 따르면
https://twitter.com/antirez/status/207123059700801537
https://twitter.com/antirez/status/207123035243814912

기본적으로 클라이언트 라이브러리에 달려 있습니다.
PHP 치명적인 오류가 발생할 때 Predis가 사용하는 두 가지 유형의 PHP 소켓이 있습니다. redis 연결은 영원히 좀비/스톨이 되거나 OS가 정리를 처리합니다

이 두 가지 유형 중 Predis는 어떤 유형을 사용합니까?

그러나 0 시간 초과를 사용하기 전에 php mysql 모듈에 대한 이전 경험에 대한 우려가 있습니다.

mysql_pconnect() 를 사용하여 MySQL에 대한 영구 연결을 생성할 때 php.ini의 $ mysql.max_persistent php.ini 가 정상적인 값(MySQL에 대해 설정된 값보다 낮음)으로 설정되어 있는지 확인해야 합니다. 비영구적 MySQL 연결을 사용하고 있었다면 mysql_close() 에 대한 명시적 호출 은 스크립트 실행이 끝날 때 리소스가 해제 되기 때문에 필요하지 않아야 합니다. 글쎄, mysql 모듈이나 PHP 자체의 일부 버그를 제외하고).

즉, Predis는 persistent=1 가 연결 매개변수에 지정된 경우 영구 연결을 지원할 수 있지만 기본적으로 사용하지 않습니다. 비영구 연결은 다른 비영구 리소스와 동일한 규칙을 따르기 때문에 제대로 닫히지만(스크립트 실행이 끝나면 해제됨) 연결 클래스의 __destruct() 메서드는 어쨌든 기본 소켓 스트림을 강제로 닫습니다. 즉, 연결 개체가 더 이상 활성 참조가 없는 범위를 벗어나므로 연결 개체가 가비지 수집될 때 소켓이 닫힙니다.

이렇게 깊은 후속 조치를 주셔서 감사합니다.
이제 시간 초과를 0으로 설정하는 것이 안전하다고 생각합니다.

php.ini를 조정하여 mysql 오류에 대해서도 도움을 주셔서 감사합니다.

http://dev.mysql.com/doc/refman/5.0/en/blocked-host.html

Host 'host_name' is blocked because of many connection errors.
Unblock with 'mysqladmin flush-hosts'