Node-redis: 오류를 플러시한 후 retry_strategy가 재설정되지 않습니다.

retry_strategy에 대한 문서를 통해 node_redis는 함수가 숫자를 반환하는 경우에만 재연결을 시도하는 것으로 보입니다.

이 함수에서 숫자를 반환하는 경우 재시도는 정확히 해당 시간(밀리초) 이후에 발생합니다.

귀하의 경우 재연결 시도 요구 사항을 충족하지 않는 비 번호를 반환합니다.

숫자가 아닌 값을 반환하면 더 이상 재시도하지 않고 모든 오프라인 명령이 오류로 플러시됩니다.

내가 찾고 있는 흐름은 연결이 끊길 때 1초 간격으로 3번 연결을 다시 시도하는 것입니다. 세 번째에도 여전히 연결이 끊긴 경우 오류와 함께 모든 미해결 명령을 반환해야 합니다. 다시 연결하려는 시도를 중지하고 싶지 않습니다.

README.md에 제공된 예제의 수정된 버전을 사용하면 원하는 것을 얻을 수 있을 것입니다. 그러나 최대 시도 횟수인 3이 소진되면 클라이언트는 다음 명령에서 자동으로 재연결을 시도하지 않습니다. createClient() 를 수동으로 다시 호출해야 한다고 생각합니다.

const client = redis.createClient({
    url: 'redis://localhost:6379',
    retry_strategy: (options) => {
        if (options.times_connected >= 3) {
            // End reconnecting after a specific number of tries and flush all commands with a individual error
            return new Error('Retry attempts exhausted');
        }
        // reconnect after
        return 1000;
    }
});

예, 여기서는 차이가 없기 때문에 시도를 생략했습니다.

따라서 기본적으로 다음을 의미합니다.

let client = createClient();
function createClient () {
  return redis.createClient({
    url: 'redis://localhost:6379',
    retry_strategy: (options) => {
      client = createClient();
      return new Error('Retry attempts exhausted');
    }
  });
}

내 코드에서 더 이상 내 redis 클라이언트를 전달할 수 없다는 것을 의미합니까?

redis 클라이언트의 싱글톤 인스턴스를 관리하기 위해 가벼운 래퍼를 만들 수 있습니다.

// redisClient.js

let redis = require("redis");

let client = null;

const options = {
    url: 'redis://localhost:6379',
    retry_strategy: (options) => {
        client = null;
        return new Error("Redis client connection dropped.");
    }
};

module.exports = {
    getClient: () => {
        if (client == null) {
            client = redis.createClient(options);
        }
        return client;
    }
};

사용:

// usage

let client = require("redisClient.js");

client.getClient().get("some key");
client.getClient().set("some key", "some value");

나는 이것이 재시도 전략에서 createClient() 를 호출하는 것과 매우 유사하다고 생각하지만 나는 그 방법의 열렬한 팬은 아닙니다.

getClient() 항상 호출해야 하는 필요성을 줄이려면 get() , set() 등과 같은 모든 redis 호출을 래핑하는 큰 래퍼를 만들 수 있습니다. 각 메서드에서 getClient() 를 호출합니다. 그러나 이 getClient() 방식은 열성적으로 연결을 관리하기 보다는 느리게 연결을 관리하는 꽤 일반적인 방법입니다.

확실하지만 어쨌든 추가 재시도 래퍼로 랩핑해야 하는 경우 이 라이브러리가 재시도 전략을 전혀 제공하지 않는 이유는 무엇입니까?

저는 저자가 아니므로 retry_strategy의 특정 구현 이면에 있는 동기를 잘 모르겠습니다. node_redis를 직접 사용하면서 retry_strategy의 현재 기능이 유용하다는 것을 알았지만 어떤 일이 있어도 자동으로 재시도하는 기능이 부족하다는 데 동의합니다. 내 사용에서 나는 항상 연결 시도가 이루어지기를 원하기 때문에 retry_strategy에서 일관되게 숫자를 반환했으며 오류를 반환하지 않았습니다. 그러나 retry_strategy 내에서 오류를 기록합니다.

이런 건 어때? https://github.com/viglucci/node_redis/tree/feature-reconnect-after-flush#retry_strategy -example

var client = redis.createClient({
    retry_strategy: function (options) {
        if (options.error && options.error.code === 'ECONNREFUSED') {
            // End reconnecting on a specific error and flush all commands with a individual error
            return new Error('The server refused the connection');
        }
        if (options.total_retry_time > 1000 * 60 * 60) {
            // End reconnecting after a specific timeout and flush all commands with a individual error
            return new Error('Retry time exhausted');
        }
        // attempt reconnect after retry_delay, and flush any pending commands
        return {
            retry_delay: Math.min(options.attempt * 100, 3000),
            error: new Error('Your custom error.');
        }
    }
});

개념적으로 많은 의미가 있습니다. 이것을 구현하는 또 다른 방법은 이것을 두 가지 전략으로 나누는 것입니다.

var client = redis.createClient({
  // this strategy handles the pending redis commands when the connection goes down
  flush_strategy (options) {
    if (options.attempt >= 3) {
      // flush all pending commands with this error
      return new Error('Redis unavailable')
    }
    // let the connection come up again on its own
    return null;
  },
  // this strategy handles the reconnect of a failing redis
  retry_strategy (options) {
    if (options.total_retry_time > 1000 * 60 * 60) {
      // The connection is never going to get up again
      // kill the client with the error event
      return new Error('Retry time exhausted');
    }
    // attempt reconnect after this delay
    return Math.min(options.attempt * 100, 3000)
  }
});

나는 flush_strategy 라는 이름을 별로 좋아하지 않지만 더 나은 것을 생각해낼 수 있습니다.

오 흥미롭군. 여기서 제안하는 것은 현재 retry_strategy 을 connection_strategy 바꾸고 기존 retry_strategy 를 flush_strategy 라고 부르는 것으로 사용하는 것과 같습니다.

var client = redis.createClient({
    // this strategy handles reconnection
    connection_strategy (options) {
        if (options.total_retry_time > 1000 * 60 * 60) {
            // The connection is never going to get up again
            // kill the client with the error event
            return new Error('Retry time exhausted');
        }
        // attempt reconnect after this delay
        return Math.min(options.attempt * 100, 3000)
    },
    // this strategy handles the pending redis commands when the connection goes down
    retry_strategy (options) {
        if (options.attempt >= 3) {
            // flush all pending commands with this error
            return new Error('Redis unavailable');
        }
        // let the client attempt the commands once a connection is available
        return null;
    },
});

구현: https://github.com/viglucci/node_redis/tree/feature-connection-strategy#retry_strategy -example

@Janpot 이것이 필요한 사용 사례를 자세히 retry_strategy 는 이미 강력한 옵션입니다.

@viglucci 여기에 답변해 하라는 당신의

@BridgeAR 어떤 이유로 redis 연결이 끊어지면 모든 명령이 중단됩니다. redis가 수행하는 작업에 대한 대체가 있다고 가정하면 해당 대체도 중단됩니다. 나는 오히려 redis가 몇 번의 재시도 후에 오류를 반환하기를 원합니다. 나는 이것을 잡아서 대체할 수 있습니다. 그렇다고 해서 클라이언트가 연결 시도를 중지하는 것을 원하지 않는다는 의미는 아닙니다. Redis는 1분 안에 다시 돌아올 수 있습니다.

나는 현재 행동의 요점을 보지 못합니다. 재시도 핸들러에서 오류를 반환하면 클라이언트가 영원히 죽습니다. 모든 명령에 대해 클라이언트를 생성하지 않는 한 누가 그런 종류의 행동을 필요로 합니까?

아니면 물론 그 사용 사례를 보지 못할 수도 있습니다 😄

@BridgeAR 감사합니다. 구성 매개변수에 대한 지원 제거/사용 중단 경고 제거 등과 같은 간단한 작업이 포함된 "V3로 가는 길" 로드맵이 있는 경우 풀 요청 제출에 관심이 있습니다. 아마도 추가 redis 명령에 대한 지원을 추가하는 것과 같은 대규모 작업을 처리할 수 없을 것입니다. 하지만 V3 기능 분기를 사용할 수 있게 되면 PR용으로 열리면 간단한 집 청소 작업을 수행할 수 있을 것입니다.

@viglucci 협력자로 초대했습니다. 조만간 계획을 세워봐야겠다

이 문제에 대한 해결책은 +1입니다.

나는 Express를 사용하고 있으며, 내 retry_strategy 가 여전히 정수를 반환하여 나중에 다시 연결을 시도하고 있지만 명령(및 웹 요청)은 무언가를 던지는 대신 계속해서 쌓여서 백업됩니다. 그들의 삶과 함께... 그리고 희망적으로 연결은 _결국적으로_ 전략이 포기하거나 무엇이든 말하기 전에 재구축됩니다.

이것이 달성될 수 있습니까? @Janpot 현재 이 상황을 해결할 수 있는 것을 찾았습니까?

enable_offline_queue 및/또는 retry_unfulfilled_commands 옵션을 사용하여 이 작업을 수행할 수 있습니까?

모든 분들의 노고와 도움에 감사드립니다!

여기에서 빠른 업데이트.
enable_offline_queue = false 를 createClient 옵션에 추가했는데 원하는 대로 수행된 것 같습니다.
" retry_strategy 기능을 기반으로 내 Redis 서버에 계속 재연결을 시도하지만 그 동안 클라이언트를 사용하려는 시도에 대한 응답으로 즉시 오류를 throw합니다. 그런 다음 다시 연결할 수 있으면 다시 작업을 시작하십시오. ".

참고: get 호출 시 다음 오류가 발생합니다. AbortError: SET can't be processed. Stream not writeable.

DB와 앱 사이의 직선 레이어로 사용하려면 괜찮습니다. 다음과 같은 경우에 가능한 "강력한" 솔루션이 있는지 알고 싶습니다.

• 클라이언트가 retry_strategy 기반으로 계속해서 다시 연결을 시도합니다.
• 클라이언트의 통화/소비자/사용자는 다시 연결하는 동안 중단되지 않습니다.
• 연결이 다시 설정될 때 명령을 실행하기 위해 (조건부로?) 명령을 계속 대기할 수 있습니다.

아마도 여기에서 고려해야 할 어려운 시나리오가 많이 있을 것입니다...

@새집 ,

언급해 주셔서 감사합니다. 우리는 우리 응용 프로그램에 대해 동일한 동작을 원했고 귀하의 솔루션은 호출자에게 즉시 오류를 반환하는 데 효과가 있었지만 무기한 연결을 다시 시도할 수 있습니다.

@newhouse 감사합니다.

IMO 이것은 기본 동작이거나 적어도 retry_strategy 주변의 문서에서 명시적으로 호출되어야 합니다. 후자가 합리적이라고 생각하시면 알려주시면 PR을 열어 문서를 추가하겠습니다.

@bwhitty 누구든지 문서 PR을 환영합니다 👍

enable_offline_queue = false 를 사용하는 한 가지 문제는 createClient 호출한 직후에 전송된 명령이지만 연결이 실제로 열리기 전에도 실패한다는 것입니다.

enable_offline_queue = false 를 사용하는 한 가지 문제는 createClient 호출한 직후에 전송된 명령이지만 연결이 실제로 열리기 전에도 실패한다는 것입니다.

@jkirkwood ready 이벤트(또는 이와 유사한 적절한 이벤트)가 방출될 때까지 첫 번째 명령 전송 시도를 지연하고 싶은 것 같습니까?