Redis 미드레벨 CS 기초 기술면접

TCP 3-way handshake는 SYN -> SYN-ACK -> ACK 순서로 연결을 수립하고, 4-way handshake는 FIN -> ACK -> FIN -> ACK 순서로 연결을 종료합니다. Redis 클라이언트가 커넥션 풀을 사용하는 이유는 매번 새로운 TCP 연결을 생성하면 handshake 오버헤드가 발생하고 TIME_WAIT 상태의 소켓이 누적되어 리소스를 낭비하기 때문입니다. 적절한 풀 크기는 애플리케이션의 동시 요청 수, Redis 서버의 maxclients 설정, 네트워크 레이턴시를 고려하여 결정하며, 일반적으로 애플리케이션 스레드 수의 1~2배 정도로 설정합니다. 과도하게 큰 풀은 Redis 서버의 파일 디스크립터를 고갈시킬 수 있으므로 주의해야 합니다.

quicklist는 ziplist 노드들을 이중 연결 리스트로 연결한 하이브리드 자료구조입니다. 순수 linkedlist는 각 노드마다 포인터 오버헤드가 크고 메모리 단편화가 발생하며, 순수 ziplist는 연속된 메모리를 사용해 메모리 효율적이지만 크기가 커지면 realloc 비용이 증가하는 단점이 있었습니다. quicklist는 작은 크기의 ziplist들을 linkedlist로 연결하여 메모리 효율성과 삽입/삭제 성능의 균형을 맞췄습니다. list-max-ziplist-size는 각 quicklist 노드의 최대 크기를 제어하며, 양수일 때는 엔트리 개수, 음수일 때는 바이트 크기를 의미합니다. 이 값이 작으면 메모리는 더 사용하지만 삽입/삭제가 빠르고, 크면 메모리는 절약되지만 realloc 비용이 증가합니다.

epoll은 커널 공간에 관심 파일 디스크립터 목록을 유지하여 매번 전체 fd set을 복사하는 select의 오버헤드를 제거합니다. select는 O(n) 시간에 모든 fd를 순회하지만, epoll은 이벤트가 발생한 fd만 반환하여 O(1)에 가까운 성능을 제공합니다. Redis는 Level-Triggered 모드를 사용하는데, 이는 읽을 데이터가 남아있으면 계속 이벤트가 발생하여 프로그래밍이 간단하고 안전하기 때문입니다. Edge-Triggered는 상태 변화 시점에만 이벤트가 발생하여 더 효율적이지만, 모든 데이터를 한 번에 읽지 않으면 이벤트를 놓칠 수 있어 non-blocking I/O와 복잡한 버퍼 관리가 필요합니다. Redis의 단일 스레드 이벤트 루프 모델에서는 Level-Triggered가 더 적합합니다.

reverse binary iteration은 해시 테이블의 인덱스를 이진수로 표현했을 때, 최상위 비트부터 증가시키는 방식으로 순회합니다. 일반적인 순차 증가와 달리, 이 방식은 해시 테이블이 확장되거나 축소될 때 이미 방문한 버킷과 아직 방문하지 않은 버킷을 명확히 구분할 수 있습니다. Redis는 두 개의 해시 테이블(ht[0], ht[1])을 유지하며 rehashing 중에는 두 테이블 모두를 검사합니다. 커서의 비트 패턴을 통해 작은 테이블의 위치와 큰 테이블의 대응 위치를 동시에 추적하므로, 데이터가 이동 중이어도 누락이나 중복 없이 순회할 수 있습니다. 다만 rehashing 중에는 동일한 키가 두 번 반환될 수 있으므로 클라이언트에서 중복 제거가 필요합니다.

Redis의 MULTI/EXEC는 Atomicity(원자성)와 Isolation(격리성)은 제공하지만 Durability(지속성)는 제한적이고 Consistency(일관성)는 개발자가 보장해야 합니다. Redis 트랜잭션은 명령어들을 큐에 저장했다가 EXEC 시점에 순차적으로 실행하며, 중간에 다른 클라이언트의 명령어가 끼어들지 않습니다. 하지만 실행 중 에러가 발생해도 롤백되지 않고 나머지 명령어는 계속 실행됩니다. Redis가 롤백을 지원하지 않는 이유는 명령어 실패가 대부분 프로그래밍 에러(잘못된 타입 연산 등)이며, 롤백 구현은 성능 오버헤드와 복잡성을 증가시키기 때문입니다. 실무에서는 Lua 스크립트를 사용하여 조건 검증 후 실행하거나, WATCH를 통한 낙관적 락으로 충돌을 감지하고, 애플리케이션 레벨에서 보상 트랜잭션을 구현하는 방식으로 대응합니다.