[Redis Official Documentation] Redis 아키텍처

 

1) Redis의 단일 스레드 특성

- Redis는 주로 단일 스레드 설계를 사용합니다.

  즉, 모든 클라이언트 요청을 처리하는 단일 프로세스가 있으며,

  이를 멀티플렉싱이라는 기법을 사용하여 처리합니다.

 

- 이는 Redis가 한 번에 하나의 요청만 처리할 수 있다는 의미이며, 모든 요청이 순차적으로 처리된다는 뜻입니다.

  이는 Node.js가 작동하는 방식과 매우 유사합니다. 그러나 이 두 제품은 보통 느리다고 인식되지 않습니다.

 

- 그 이유는 단일 요청을 처리하는 데 걸리는 시간이 매우 짧고,

  무엇보다 이들 제품이 시스템 호출에서 차단되지 않도록 설계되었기 때문입니다.

  예를 들어, 소켓에서 데이터를 읽거나 쓰는 작업에서 차단되지 않도록 처리됩니다.

 

- Redis가 주로 단일 스레드라고 말한 이유는

  Redis 2.4 버전부터 디스크 I/O와 관련된 일부 느린 작업을 백그라운드에서 수행하기 위해 스레드를 사용하지만,

  여전히 Redis는 모든 요청을 단일 스레드로 처리하기 때문입니다.

 

 

2) 커넥션 풀과 multiplexing

 

- Redis 예제 코드는 일반적으로 연결을 열고, 명령어 또는 기능을 보여준 후 연결을 닫습니다.

  실제 코드에서는 서버와의 통신이 짧은 시간 동안 집중적으로 이루어지고

  그 사이에 비활성 상태가 지속되는 경우가 많습니다.

 

- 연결을 열고 닫는 작업은 오버헤드가 발생하며, 이를 자주 반복하면 비효율적이 됩니다.

  따라서 프로덕션 코드에서는 가능한 한 적은 수의 연결만 사용하여 성능을 개선할 수 있습니다.

- 자체적으로 연결을 관리하는 것은 까다로울 수 있기 때문에, Redis 클라이언트 라이브러리는 이를 도와주는 기능을 제공합니다.      연결 관리의 두 가지 기본 접근 방식은 연결 풀링(Connection Pooling)과 멀티플렉싱(Multiplexing)입니다.

 

- redis-py, jedis, go-redis 클라이언트는 연결 풀링을 지원하며, NRedisStack은 멀티플렉싱을 지원합니다.

  Lettuce는 두 가지 접근 방식을 모두 지원합니다.

 

 

(1) 커넥션 풀

(1-1) 커넥션 풀 초기화

- 커넥션 풀을 초기화하면 클라이언트가 소수의 연결을 열고 이를 풀에 추가합니다. 

 

(1-2) 커넥션 시작

- 풀에서 "커넥션을 열 때"마다 클라이언트는 기존의 커넥션 중 하나를 반환하고, 해당 커넥션이 사용 중임을 기록합니다.

 

 

(1-3) 커넥션 종료

- 나중에 "커넥션을 닫을" 때, 클라이언트는 실제로 커넥션을 닫지 않고 사용 가능한 커넥션 풀에 다시 넣습니다.

 

(1-4) 커넥션 관리

- 풀에 있는 모든 커넥션이 사용 중이고 앱에서 더 많은 커넥션이 필요하면,

  클라이언트는 필요한 만큼 새 커넥션을 열 수 있습니다.

  이렇게 해서 클라이언트는 결국 앱의 요구를 충족할 수 있는 적절한 수의 커넥션을 찾게 됩니다.

 

 

(2) Multiplexing

 

 

 

- 여러 커넥션을 pooling하는 대신, multiplexer는 단일 커넥션을 유지하며, 

  클라이언트와 서버 간의 모든 트래픽에 사용합니다.

  코드에 반환되는 "커넥션"은 명령의 응답 데이터를 어디로 보낼지를 식별하는데 사용됩니다. 

 

-  여러 명령이 시간상 근접하게 발생하는 것은 문제가 되지 않습니다.

   이 경우, multiplexer는 명령을 파이프라인으로 결합하여 효율성을 향상시킬 수 있습니다. 

 

- Multiplexing은 높은 효율성을 제공하지만, 앱에서 이를 활성화하기 위한 특별한 코드 없이 투명하게 작동합니다.

  Multiplexing이 connection pooling에 비해, 주요한 단점은 블로킹 "팝" 명령을 지원하지 못한다는 점입니다.

  이러한 명령은 connection을 모든 호출자에 대해 멈추게 할 수 있습니다.