Redis는 왜 싱글 스레드일까

Redis가 단일 스레드(single-threaded)로 설계된 이유는 주로 성능 최적화, 복잡성 감소, 그리고 데이터 일관성을 유지에 있습니다.

1. 복잡성을 최소화
멀티 스레드 환경에서 가장 어려운 문제는 동시성이다.
- 레이스 컨디션
- 데드락
- 락경합
- 메모리 가시성 문제
이런 문제를 해결하려면 락, 뮤텍스, 세마포어 같은 복잡한 동기화 메커니즘이 필요하다.
이는 곧 코드 복잡도 증가 -> 버그 가능성 증가 -> 유지보수 비용 증가로 이어진다.
Redis는 이 복잡함을 아예 선택하지 않았다.
모든 명령을 단일 스레드에서 순차적으로 처리함으로써 동시성 문제를 구조적으로 제거했다.

2. 데이터 일관성을 보장
Redis의 모든 명령은 Atomic 하게 실행된다.
이게 가능한 이유가 바로 싱글 스레드이다.
여러 클라이언트가 동시에 같은 키를 수정하더라도 명령은 하나씩 순서대로 중간에 끼어들 수 없이 처리된다.
멀티 스레드였다면 각 명령마다 락을 걸거나, 트랜잭션 수준의 보호 장치가 필요했을 것이다.
Redis는 그런 비용 없이도 강한 데이터 일관성을 기본으로 제공한다.

3. Redis의 본질은 CPU 연산이 아니라 빠른 I/O
Redis는 인메모리 데이터 베이스이다.
대부분 연산은 메모리 접근, 간단한 자료구조 조작, 네트워크I/O 로 이루어진다.
멀티 스레드는 필욘적으로 컨텍스트 스위칭 비용을 발생시킨다.
오히려 짧고 빠른 작업이 많은 Redis 같은 워크로드에서는 이 오버헤드가 성능을 떨어뜨릴 수 있다.
Redis는 이를 피하기 위해 단일 스레드 이벤트 루프(event loop) 구조를 선택했다.

4. 이벤트 기반 아키텍처로 높은 동시성 확보
“싱글 스레드 = 동시에 하나만 처리한다”라고 오해하기 쉽다. 하지만 Redis는 이벤트 기반(event-driven) 서버다.
여러 클라이언트의 요청을 비동기로 수신 이벤트 루프에서 순차 처리 네트워크 I/O는 논블로킹 방식 이 구조 덕분에 Redis는 단일 스레드임에도 불구하고 수만 개의 동시 연결을 효율적으로 처리할 수 있다. 즉, Redis의 동시성은 멀티 스레드가 아니라 비동기 I/O에서 나온다.

5. Redis 6.0 이후의 변화 실행은 여전히 싱글 스레드
Redis 6.0부터는 중요한 변화가 하나 있다. 클라이언트 요청을 읽는 부분 응답을 전송하는 네트워크 I/O 부분 이 두 영역은 멀티 스레드를 지원한다. 하지만 핵심은 여기다.
명령을 실제로 실행하는 부분은 여전히 싱글 스레드다. 이 덕분에 Redis는 네트워크 병목은 줄이고 CPU 활용도는 높이면서 기존과 동일한 Atomic 특성을 유지한다.

정리
복잡한 동시성 문제를 제거하고 데이터 일관성을 자연스럽게 보장하며 컨텍스트 스위칭 오버헤드를 피하고 이벤트 기반 구조로 높은 동시성을 확보하기 위한 의도적이고 전략적인 설계이다.

Redis는 멀티 스레드를 “못 쓰는” 시스템이 아니라, “안 쓰는 게 더 빠른” 시스템이다.