초기 Redis 분석 - 이벤트 루프

들어가기 전에

Redis beta 1 버전을 기준으로 작성한 글입니다.

해당 버전의 코드는 다음 링크에서 확인하실 수 있습니다.

http://redisgate.kr/redis/introduction/redis_release1.php

Redis Release Notes 1

이벤트 종류

• 파일 이벤트: 클라이언트 생성, 커맨드 수행과 DB 백업 과정에서 발생하는 응답에 대한 이벤트
• 타임 이벤트: redis 내부에서 주기적으로 돌아가는 cron 작업.
  초기에는 최소 사이즈를 만족하지 못하는 해시 테이블을 축소하는 작업만 한다.

redis의 이벤트 루프 객체

작동방식

이벤트 루프를 통해 지속적으로 파일, 타임 이벤트를 확인하고 처리한다.
하나의 while 문으로 돌아가기 때문에 redis는 싱글 스레드로 처리된다.

 

하나의 루프로 이벤트 처리

 

다만 DB 백업 같은 복잡한 I/O 작업의 경우 이벤트 루프가 blocking 될 수 있으니 fork를 통해 자식 프로세스를 생성한다.

이벤트 처리는 다음 과정을 거친다.

 

1. 현재 파일 이벤트에 등록된 read, write, exception 마스킹과 최대 file descripter 값 갱신
2. 파일 이벤트 처리 전 가장 가까운 타임 이벤트를 찾아 언제 실행할지 계산
3. 파일 이벤트 처리 (일부 이벤트들은 파일 디스크립터가 준비되지 않을 수 있다.)
4. 현재 시간보다 이전에 실행돼야 했던 타임 이벤트 처리

서비스 과정에선 redis 서버에 요청이 수시로 발생하기 때문에 파일과 타임 이벤트리스트에 변동이 자주 발생한다.

파일 이벤트의 경우 select 콜의 결과가 모든 이벤트의 파일 디스크립터를 준비하지 못할 수 있다. 그래서 리스트의 중간 이벤트만 처리해야 하는 경우가 있다.

 

마찬가지로 타임 이벤트의 경우, 리스트의 일부 이벤트는 당장 처리하지 않아도 되는 경우가 있다.

따라서, 각각의 리스트의 시작점으로 되돌아간 뒤, 처리할 이벤트들을 탐색한다.

AE_DONT_WAIT

이벤트 루프에서 특이한 점은 AE_DONT_WAIT flag를 통해 select 시스템 콜을 non-blocking 방식으로 처리할 수 있다.

하지만 매크로 코드를 보면 AE_DONT_WAIT는 형식적으로만 있고, 다른 코드를 보더라도 여기에 대해선 flag를 적용하지 않는다.

 

AE_ALL_EVENTS 에 AE_DONT_WAIT는 포함되지 않았다.

개인적인 생각으로는 초기 버전이기 때문에 정의만 해둔 게 아닐까라고 생각을 한다.