우리는 보통 Redis를 생각할때 이런 키워드를 떠올린다.
- In-Memory
- Key-Value
- 빠른 성능
- Single thread
- .......등등
하지만 redis를 이야기할때 누구는 Single thread이기도 하고 Multi Thread이기도 하다고 이야기한다.. 과연이게 무슨뜻일까?
Single thread vs Multi Thread
사실 Redis는 6.0부터 Multi Thread라고 할 수 있다.
왜냐하면 ThreadedIO가 추가되면서 사용자 명령이 Multi Thread로 동작하기 때문이다.
그렇다면 Single thread가 아닌데 redis의 장점이였던 Atomic을 어떻게 보장하지?라는 의문이 들 수 있다.
하지만 걱정할 필요 없다! redis는 Single thread이기 때문이다..^^
이게 무슨 말이냐면 redis는 부분적으로 Single thread와 Multi Thread를 함께 사용한다.
클라이언트로 부터 전송된 네트워크를 읽는 부분과 전송하는 부분은 Multi Thread로 구현되어있으며
우리가 redis에 요청한 명령을 실행하는 부분은 Single thread로 구현되어 있다.
때문에 single thread의 장점인 Atomic한 요청 처리가 가능한 것이다.
- I/O : 네트워크 connection
- Event Loop : 명령 실행부분
결과적으로 명령을 실행하는 부분이 Single thread라면 성능에는 큰 영향이 없는거 아닌가?
나는 처음 이를 공부할 때 위와 같은 의문이 생겼는데 좀 더 찾아보니 그 이유를 알 수 있었다.
위와 같은 방식을 활용한다면 클라이언트가 네트워크 패킷을 여러번 보냈을 때 Redis는 각 요청의 응답을 기다리지 않고 일괄 처리하게 되는데 이는 네트워크 오버헤드를 줄이면서 시스템의 전체 처리량을 향상시킨다는 이유였다. (이러한 방식을 Pipelining이라 부르는 것 같다.)
해당 구조를 택하면서 Redis의 성능이 2배이상 좋아졌다고 한다.
아마 기존 Redis의 속도가 워낙 빠르다보니 네트워크 대기시간만 줄여도 엄청난 성능향상이 나타난 것 같다..
이전 redis 구조
redis 6.0 이후 구조
참고 (정말 잘 정리되어있으니 추천드립니다)
https://charsyam.wordpress.com/2020/05/05/%EC%9E%85-%EA%B0%9C%EB%B0%9C-redis-6-0-threadedio%EB%A5%BC-%EC%95%8C%EC%95%84%EB%B3%B4%EC%9E%90/
https://www.linkedin.com/pulse/why-heck-single-threaded-redis-lightning-fast-beyond-in-memory-kapur/
