Node-redis: 파이프라이닝

client.multi 및 multi.exec 명령을 통해 수행됩니까?

안녕하세요 @saritasa -- 파이프라이닝은 자동입니다. 항상 클라이언트 내부에서 발생합니다. 활성화하기 위해 multi 또는 exec를 사용할 필요가 없습니다.

안녕하세요 브라이스,

1. 나는 혼란 스럽습니다. node_redis 내부의 "다중"기능의 목적은 무엇입니까?
2. 명령을 자동으로 파이프라인하는 데 사용되는 알고리즘은 무엇입니까?

감사 해요,
드미트리

다중 작업은 Redis 프로토콜 사양에서 가져왔으며 파이프라이닝 외부의 트랜잭션 목적이 있습니다 .

파이프라이닝 작동 방식: http://redis.io/topics/pipelining 이것은 클라이언트가 다음 명령을 작성하기 전에 응답을 기다리지 않고 보내는 만큼 빠르게 Redis에 명령을 작성하는 문제일 뿐입니다. 클라이언트는 전송된 명령을 추적한 다음 Redis가 응답하면 전송된 명령으로 응답을 재정렬합니다.

Bryce에게 감사합니다. http://redis.io/topics/pipelining이 작동하는 방식을 이해합니다. node.js 애플리케이션에서 - 요청이 파이프라인되도록 코드를 어떻게 구성해야 합니까?

그래서 아래 예에서

hgetall 및 만료 - 파이프라인이 되어 있습니까? 호출 중 하나가 콜백 내부에 있습니다.

함수 getByID(테이블, ID, 다음) {
if (!success) return setTimeout(함수() {
getByID(테이블, 아이디, 다음);
}, 2000);

var end = utils.getEndTime(),
    base = getBase(),
    client = getClient(PK2str(table, id)),
    key = getHashID(table, id);

base.sismember(table, key, function (err, val) {
    if (err || !val) return next();

    client.hgetall(key, function (err, val) {
        if (err || !val) return next(new Error('Expired'), id);

        val = arrays_parse(table, val);
        next(null, val);
        client.expire(key, cfg.ttl.shards);

        if (!exports.silent) {
            profiler.log('cache', {
                'table': table,
                'id': key,
                'method': 'getByID',
                'data': val,
                'time': end()
            });
        }
    });  
});

}

모든 명령은 "파이프라인"으로 전송되지만 다음 중 하나 또는 두 가지 이유로 인해 동일한 파이프라인 쓰기 프레임으로 전송되지 않습니다.

1. sismember에 대한 콜백은 hgetall 호출을 호출하는 것이므로 주어진 sismember 호출에 대해 이러한 명령이 함께 파이프라인되는 것을 암시적으로 방지합니다. Redis가 응답할 때까지 콜백이 호출되지 않습니다.
2. base 및 client 가 다른 Redis 클라이언트인 경우 동일한 파이프라인을 _절대_ 공유할 수 없습니다.

파이프라이닝의 이점을 보려면 동일한 컨텍스트*에서 명령을 실행해야 합니다. 예를 들어 redis 파이프라이닝 문서의 PING 예제와 유사합니다.

// These commands will all be pipelined together:
client.ping()
client.ping()
client.ping()
client.ping(function () {
  // This would *NEVER* be in the same pipeline frame as the other four because it requires a reply to be received first
  client.ping()
})

* 또는 Redis가 응답하는 것보다 빠르게 전송된 경우 별도의 컨텍스트에서 전송되지만 종속 컨텍스트에는 응답하지 않습니다.

이제 알았습니다 - 감사합니다! 이것은 매우 귀중한 의견입니다!

node_redis "자동 파이프라이닝"은 공식 redis에서 참조하는 파이프라이닝이 아니라고 생각합니다.

이 시간을 RTT(왕복 시간)라고 합니다. 클라이언트가 연속적으로 많은 요청을 수행해야 하는 경우(예: 동일한 목록에 많은 요소를 추가하거나 많은 키로 데이터베이스를 채우는 경우) 이것이 성능에 어떤 영향을 미칠 수 있는지 매우 쉽게 알 수 있습니다. 예를 들어 RTT 시간이 250밀리초(인터넷을 통한 매우 느린 링크의 경우)인 경우 서버가 초당 100,000개의 요청을 처리할 수 있더라도 초당 최대 4개의 요청을 처리할 수 있습니다.
사용된 인터페이스가 루프백 인터페이스인 경우 RTT는 훨씬 더 짧지만(예를 들어 내 호스트가 127.0.0.1을 핑하는 0,044밀리초를 보고함) 연속으로 많은 쓰기를 수행해야 하는 경우 여전히 많습니다.

공식 redis에 의한 파이프라이닝이 의미하는 것은 여러 명령을 결합하고 node_redis에서 처리되지 않는 RTT로 인한 대기 시간에 대응하기 위해 한 번만 보내는 것입니다. 그리고 node_redis의 "automatica pipelining"은 실제로 Node의 비동기 프로그래밍 모델을 사용하여 동시에 가능한 한 많은 명령을 보내는 것입니다.

다음은 이 문제를 논의하는 좋은 기사입니다. http://informatikr.com/2012/redis-pipelining.html

@Vizwind @saritasa .multi와