redis 가 왜 pipeline 기능 을 제공 하 는 지 정말 알 고 있 습 니까?

Redis 자 체 는 cs 모드 의 tcp server 입 니 다.client 는 하나의 socket 을 통 해 여러 요청 명령 을 연속 으로 실행 할 수 있 습 니 다.모든 요청 명령 이 발 송 된 후 클 라 이언 트 는 보통 redis 서버 처 리 를 막 고 기다 리 며 redis 서버 가 처리 한 후에 결 과 를 클 라 이언 트 에 게 되 돌려 줍 니 다.
       redis 의 pipeline(파이프)기능 은 명령 행 에 없 지만 redis 는 pipeline 을 지원 하 며 각 언어 판 client 에서 해당 하 는 실현 이 있 습 니 다.네트워크 비용 지연,즉 redis server 엔 드 는 매우 강 한 처리 능력 을 가지 고 있 으 며,받 은 client 메시지 가 적어 서 스루풋 이 적다.client 가 pipelining 을 사용 하여 명령 을 보 낼 때 redis server 는 일부 요청 을 대기 열 에 넣 어야 합 니 다(메모리 사용)실행 이 끝 난 후 결 과 를 한꺼번에 보 내야 합 니 다.보 낸 이름 이 많 으 면 되 돌아 오 는 결과 에 탭 을 추가 하 는 것 을 권장 합 니 다.물론 사용 하 는 메모리 도 증가 합 니 다.
       Pipeline 은 특정한 장면 에서 매우 유용 하 다.예 를 들 어 여러 개의 command 가'적시에'제출 되 어야 하고 그들 은 해당 결과 에 대해 서로 의존 하지 않 으 며 결과 에 대한 응답 도 즉시 얻 을 필요 가 없다.그러면 pipeline 은 이런'일괄 처리'의 도구 가 될 수 있다.그리고 어느 정도 에 성능 을 크게 향상 시 킬 수 있다.성능 이 향상 되 는 이 유 는 주로 TCP 링크 에서'상호작용 왕복'시간 이 적 기 때문이다.그러나 인 코딩 을 할 때 pipeline 기간 에'독점'링크 를 합 니 다.이 기간 에 pipeline 이 닫 힐 때 까지'파이프'형식 이 아 닌 다른 작업 을 할 수 없습니다.만약 당신 의 pipeline 명령 집합 이 매우 방대 하 다 면 링크 의 다른 조작 을 방해 하지 않 기 위해 서 는 pipeline 에 새 Client 링크 를 조작 하여 pipeline 과 다른 정상 적 인 조작 을 2 개의 client 에서 분리 할 수 있 습 니 다.그러나 pipeline 이 사실상 용인 할 수 있 는 조작 개 수 는 socket-output 버퍼 크기/결 과 를 되 돌려 주 는 데이터 크기 와 매우 큰 관계 가 있 습 니 다.또한 모든 redis-server 가 동시에 지탱 할 수 있 는 pipeline 링크 의 개수 도 유한 하 다 는 것 을 의미 합 니 다.이것 은 server 의 물리 적 메모리 나 네트워크 인터페이스 의 버퍼 능력 에 제한 을 받 을 것 입 니 다.
redis 가 왜 pipeline 기능 을 제공 하 는 지 보 여 드 리 겠 습 니 다.
일반적으로 우 리 는 redis 로 인터페이스 캐 시 를 한 후에 인터페이스의 성능 을 ms 단계 로 향상 시 킬 수 있다.
그러나 redis 는 순 메모리 작업 입 니 다.ms 까지 가 야 하 는 것 은 아 닙 니 다.공식 적 인benchmark하나의 인 스 턴 스 에 따 르 면 7w+qps 를 저항 할 수 있 습 니 다.즉,하나의 redis 작업 이 redis-server 에서 소모 되 는 시간 은 약 0.014ms 입 니 다.그 시간 은 어디로 소모 되 었 습 니까?
redis 는 client-server 모델 입 니 다.client 클 라 이언 트 는 command 를 tcp 네트워크 연결 을 통 해 server 서버 에 보 냅 니 다.서버 에서 command 를 실행 한 후에 응답 을 tcp 연결 을 통 해 client 에 보 냅 니 다.

응용 서비스 에 있어 우리 가 주목 하 는 성능 은 클 라 이언 트 시간,즉 앞의 전체 실행 과정 입 니 다.redis-server 명령 이 매우 빨리 실행 되 지만 매번 명령 이 실 행 될 때마다 네트워크 에서 한 번 걸 어야 합 니 다.우리 회사 redis 클 라 이언 트 미들웨어 가 집계 한 rt 에 따 르 면 한 번 명령 의 집행 은 평균 1ms 정도 입 니 다.그러면 네트워크 소모 시간 비례:1-0.014/1=0.98(98%!!)이 를 통 해 알 수 있 듯 이 대부분의 시간 은 네트워크 io 에 소모 된다.
따라서 네트워크 io 횟수 를 줄 이면 redis-client 가 감지 하 는 시간 을 크게 제공 하고 응용 서비스 성능 을 향상 시 킬 수 있 습 니 다.redis 가 제공 하 는 pipeline 기능 은 명령 을 제출 한 후에 이 결 과 를 기다 리 지 않 아 도 다음 명령 을 계속 수행 할 수 있 습 니 다.즉,여러 명령 을 실행 한 후에 모든 결 과 를 한꺼번에 얻 을 수 있 습 니 다.이렇게 해서 인터넷 에서 의 소 모 를 크게 줄 였 다.
예 를 들 면
Client: INCR X
Client: INCR X
Client: INCR X
Client: INCR X
Server: 1
Server: 2
Server: 3
Server: 4
이 밖 에 네트워크 읽 기와 쓰기 횟수 를 줄 이 는 동시에 redis-server 커 널 상태 와 사용자 상태의 컨 텍스트 전환 도 줄 여 성능 을 한층 향상 시 켰 다.
성능 이 얼마나 향상 되 었 습 니까?
redis 공식 발표 pipeline 10 배 성능 향상

테스트 기 Intel(R)Xeon(R)CPU [email protected],pipeline 을 사용 하지 않 은 것 보다 pipeline 성능 이 7 배 가까이 향상 되 었 습 니 다.
//pipeline 으로
$ ./redis-benchmark -r 1000000 -n 2000000 -t get,set,lpush,lpop -P 16 -q
SET: 552028.75 requests per second
GET: 707463.75 requests per second
LPUSH: 767459.75 requests per second
LPOP: 770119.38 requests per second
//pipeline 을 사용 하지 않 았 습 니 다.
SET: 122556.53 requests per second
GET: 123601.76 requests per second
LPUSH: 136752.14 requests per second
LPOP: 132424.03 requests per second
pipeline 을 사용 할 때 여러 명령 의 응답 은 server 엔 드 에 캐 시 되 어 있 으 므 로 pipeline 에서 일부 명령 의 수량 이 너무 많 지 않도록 해 야 합 니 다.
사실 인터넷 io 횟수 를 줄 이 는 처리 기 교 는 비교적 흔히 볼 수 있다.예 를 들 어

CSS Sprites,많은 작은 아이콘 을 한 장의 그림 으로 합 칩 니 다

jdbc batch api 대량 제출 sql참고:
https://redis.io/topics/pipelining
https://redis.io/topics/benchmarks
이상 은 redis 가 왜 pipeline 기능 을 제공 해 야 하 는 지 에 대한 상세 한 내용 입 니 다.redis pipeline 에 관 한 자 료 는 우리 의 다른 관련 글 을 주목 하 세 요!