Redis ‐ Redis Cluster Mode - woojin-playground/Backend-PlayGround GitHub Wiki

Master Node는 쓰기 요청을 처리한다.
Replica Node는 주로 읽기 요청을 처리한다.
Replica Node가 Master Node에 처음 연결을 시도하면, 전체 데이터 동기화(Full Resynchronization)가 수행된다.
Master Node는 현재 메모리 데이터를 기반으로 RDB 스냅샷을 생성한다.
이 과정에서 발생하는 쓰기 요청은 별도의 replication buffer에 저장된다.
생성된 RDB 파일을 네트워크를 통해 Replica Node로 전송한다.
Replica Node는 해당 RDB 파일을 받아 메모리에 로드한다.
이후 Master Node는 replication buffer에 저장된 쓰기 명령들을 Replica Node에 전달하고, Replica Node는 이를 순차적으로 적용하여 데이터 동기화를 완료한다.
동기화 이후에는 Master Node의 모든 쓰기 명령이 Replica Node로 실시간 전파된다.

모니터링(Monitoring) : 각 센티널은 마스터와 복제본 노드들에 주기적으로 PING 메시지를 보내서 살아있는지 확인한다.
자동 장애 조치(Failover) : 마스터의 다운이 확정되면 센티널들은 다음 과정을 수행한다.
- 리더 선출 : 센티널 중 하나가 장애 조치를 주도할 리더가 된다.
- 새 마스터 선정 : 살아있는 Replica들 중 데이터 복제 상태가 가장 최신인 노드를 골라 새로운 Master로 승격시킨다.
- 복제 재설정 : 나머지 Replica들이 새로운 마스터를 바라보도록 설정을 변경한다.
- 클라이언트 통보 및 재접속 : 센티널은 새로운 마스터의 정보를 업데이트한다. 클라이언트는 센티널을 통해 바뀐 마스터 정보를 받아와서 중단 없이 서비스를 계속 이어갈 수 있다.

16384개의 슬롯 : Redis 클러스터는 전체 데이터를 총 16,384개의 가상 슬롯으로 나눈다.
데이터 분산 : 사용자가 데이터를 저장할 때, 키(Key)를 해싱하여 나온 결과값에 따라 특정 슬롯에 할당된다.
수평 확장 : 데이터가 너무 많아지면 Master 4를 추가하고 슬롯을 쪼개서 나눠주면 된다.
Gossip 프로토콜(노드 간 통신)
- 별도의 관리자(Sentinel)없이 Master Node들끼리 클러스터 전체 상태 파악과 장애 감지를 스스로 수행한다.
클라이언트 접근
- Sentinel 방식과 달리 클라이언트는 어느 Master Node에든 직접 붙을 수 있다.
자체 장애 조치(Failover)
- Master 1이 죽으면 이를 감시하던 다른 Master Node들이 투표를 시작해 Master 1의 짝꿍인 Replica 1을 새로운 마스터로 승격시킨다.
- 이 과정이 노드들 간의 합의로 이루어지기 때문에 별도의 감시 서버를 필요로 하지 않는다.