[DB] Redis(Remote Dictionary Server) 이해하기 -1 : 구조 및 특징, 아키텍처

해당 글에서는 Redis의 이해를 돕기 위해 작성한 글이며 Redis의 구조, 특징, 아키텍처에 대해 알아봅니다

💡 [참고] Redis 관련해서 구성 내용에 대해 궁금하시면 아래의 글을 참고하시면 도움이 됩니다.

분류	링크
Redis(Remote Dictionary Server) 이해하기 -1 : 구조 및 특징, 아키텍처	https://adjh54.tistory.com/447
Redis(Remote Dictionary Server) 이해하기 -2 : MacOS 로컬 환경 구성 및 명령어	https://adjh54.tistory.com/448
RedisTemplate API Document	https://adjh54.tistory.com/462
ValueOperations API Document	https://adjh54.tistory.com/460
HashOperations API Documnet	https://adjh54.tistory.com/461

 

 

 

 

1) Redis(Remote Dictionary Server) 및 구조

---

💡 Redis(Remote Dictionary Server)

- NoSQL 데이터베이스 중 하나이며 오픈소스 소프트웨어입니다. 주요한 특징은 ‘키-값(Key-Value)’ 형태로 데이터를 저장하고 데이터를 ‘인-메모리 데이터 저장소’에 저장하는 형태를 가지는 데이터베이스입니다.

- ‘키-값(Key-Value)’ 형태로 데이터를 저장을 하며 ‘다양한 종류의 값’을 지정 가능합니다. 값으로는 문자열, 리스트, 셋, 정렬된 셋, 해시 등을 지원합니다.
- ‘인 메모리 데이터 저장소’를 사용하기에 서버의 메인 메모리에 모든 데이터를 저장하므로, 디스크 I/O를 거치는 다른 데이터베이스 시스템보다 훨씬 빠른 성능을 보여줍니다.
- 메모리에 저장되는 데이터 베이스는 디스크에 저장하여 휘발성으로 사용되는 데이터를 영구적으로 저장하는 기능을 제공하여 서버가 다운되더라도 데이터를 복구할 수 있습니다.
- 주로 데이터베이스, 캐시, 메시지 브로커 등 다양한 용도로 사용될 수 있습니다.

Redis

https://www.sunjesoft.co.kr/faq/__faq/in-memory-dbmswa-disk-dbms-yi-caijeomi-mueosingayo

 
 

[ 더 알아보기 ]

💡 NoSQL

- ‘Not Only SQL’ 또는 ‘Non-Relational SQL’이라는 의미를 가지며 관계형 데이터베이스 관리 시스템(RDBMS)이 아닌 다른 형태의 데이터 저장소를 의미하며 스키마가 없거나 유연한 스키마를 가지고 있어 데이터 구조가 고정되어 있지 않습니다. 이로 인해 다양한 형태의 데이터를 저장하고 관리할 수 있습니다.
- NoSQL은 대용량 분산 데이터 처리를 위해 개발되었으며 데이터의 구조적 유연성과 확장성을 제공합니다.


💡 Redis 서버를 내리고 다시 서버를 올리면 데이터가 모두 사라질까?

- Redis는 기본적으로 인-메모리 데이터 구조 저장소이기 때문에, 서버가 종료되면 메모리에 저장된 데이터는 사라집니다.
- 그러나 Redis는 디스크에 데이터를 저장하는 영구 저장 기능을 제공합니다. 이 기능을 사용하면, 서버가 종료되어도 데이터를 복구할 수 있습니다. 이 영구 저장 방식은 RDB (Redis DataBase)와 AOF (Append Only File) 두 가지 방법이 있습니다.

 
 

1. NoSQL 데이터 베이스 구조의 종류

---

💡 NoSQL 데이터 베이스 구조의 종류

- Redis는 NoSQL의 종류 중 하나입니다. 그렇기에 전반적인 NoSQL의 종류 및 특징에 대해 알아봅니다.

https://learn.microsoft.com/ko-kr/dotnet/architecture/cloud-native/relational-vs-nosql-data

 

구분	정의	특징	종류
문서 저장소(Doucment Store)	데이터 및 메타데이터는 데이터베이스 내의 JSON 기반 문서에 계층적으로 저장됩니다.	유연한 데이터 구조를 가질 수 있음	MongoDB, Couch DB
키-값 저장소(Key-Value Store)	NoSQL 데이터베이스 중 가장 간단하며, 데이터가 키-값 쌍 컬렉션으로 표시됩니다.	단순하고 빠른 읽기/쓰기가 가능	Redis, Riak
열 지향 데이터베이스(Wide-Column Store)	관련 데이터가 단일 열 내부에 중첩 키/값 쌍 세트로 저장됩니다.	대량의 데이터를 빠르게 처리할 수 있음	Cassandra, HBase
그래프 저장소(Graph Store)	데이터가 그래프 구조에 노드, 에지 및 데이터 속성으로 저장됩니다.	복잡한 관계를 가진 데이터를 저장하고 조회할 수 있음	Neo4j, ArangoDB

 

 💡 [참고] NoSQL의 종류 중 문서 저장소(Document Store) 방식을 이용하는 MongoDB에 대해 궁금하시면 아래의 글을 참고하시면 도움이 됩니다.

[DB/mongo] Document DB 이해하기 -1 : MongoDB 이론 및 주요 메서드

 
 
 

2. Redis 데이터 저장구조 : Collection Type

---

💡 Redis 데이터 저장구조 : Collection Type

- ‘키-값(Key-Value)’ 형태로 데이터를 저장하는 Redis 내에서는 ‘키(key)’는 문자열 형태로 고정되어 있지만, ‘값(Value)’는 Strings, Bitmaps, Bit field, Hashes, Lists, Sets, Sorted Sets, Geospatial Indexes, Hyperloglogs, Streams 형태로 다양한 데이터 저장이 가능합니다.

https://velog.io/@tilsong/Redis%EC%9D%98-%EC%A3%BC%EC%9A%94-%EA%B8%B0%EB%8A%A5-1-%EC%9D%B8-%EB%A9%94%EB%AA%A8%EB%A6%AC-%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4

 

💡 값(Value)로 사용되는 데이터 타입들입니다. 각각의 형태로 데이터 저장이 가능합니다.

데이터 타입	설명	예시
Strings	텍스트 또는 숫자 등의 문자열을 저장할 수 있는 기본 타입입니다.	"Hello, World!"
Bitmaps	각각의 비트 위치에 0과 1 값을 저장하여 사용하는 비트 단위의 연산을 지원하는 데이터 타입입니다.	0101
Bit field	Bitmap과 유사하지만, 더 큰 크기의 비트 필드를 다룰 수 있습니다.	00010011
Hashes	키-값 쌍을 저장하는 데이터 타입으로, 객체를 표현하기에 적합합니다.	{name: "John", age: 30}
Lists	순서가 있는 문자열의 집합을 나타내는 데이터 타입으로, 새로운 요소는 앞이나 뒤에 추가할 수 있습니다.	["apple", "banana", "cherry"]
Sets	순서가 없는 유일한 문자열의 집합을 나타내는 데이터 타입입니다.	["apple", "banana", "cherry"]
Sorted Sets	Sets와 유사하지만 각 멤버는 점수를 가지며, 이 점수에 따라 정렬됩니다.	[(1, "apple"), (2, "banana"), (3, "cherry")]
Geospatial Indexes	지리적 위치 정보를 다루는 데 사용되는 데이터 타입입니다.	{"latitude": 37.7749, "longitude": 122.4194}
Hyperloglogs	크기가 큰 데이터 세트의 카디널리티를 추정하는데 사용되는 중복된 요소를 세는데 유용한 구조입니다.	["apple", "apple", "banana", "cherry", "cherry", "cherry"]
Streams	메시지 큐 시스템에 사용되는 데이터 타입으로, 메시지는 키-값 쌍으로 구성되며, 각 메시지는 유일한 ID를 가집니다.	{"id": 1, "message": "Hello"}

 
 
 

3. 인 메모리 데이터 구조(In-Memory Data Storage)

---

 💡 인 메모리 데이터 구조(In-Memory Data Storage)

- ‘컴퓨터 메모리’ 내에서 데이터를 저장하고 조작하는 방식입니다. 이는 디스크에 데이터를 저장하고 검색하는 대신 ‘RAM과 같은 메모리에 데이터를 저장’하여 훨씬 빠른 속도로 데이터에 접근할 수 있게 해 줍니다.

- 이러한 구조는 특히 대량의 데이터를 빠르게 처리해야 하는 애플리케이션에서 유용합니다. 단, 데이터가 메모리에 저장되므로 컴퓨터가 꺼지거나 재시작되면 데이터가 사라질 수 있습니다. 따라서, 인-메모리 데이터 구조를 사용할 때는 이러한 특성을 고려하여 데이터 유실을 방지하는 방안을 마련해야 합니다.

 

https://blog.naver.com/shakey7/221310751665

 

💡 [참고] RDBMS와 In Memory DB의 비교

구분	RDBMS	In Memory DB
데이터 저장 위치	디스크	메모리(RAM)
속도	상대적으로 느림(디스크 I/O가 발생하기 때문)	매우 빠름(메모리에서 직접 데이터를 읽고 쓰기 때문)
데이터 유실	트랜잭션이 완료된 시점에서의 데이터는 안전하게 보존됨	전원 공급이 중단되거나 시스템이 다운될 경우 데이터 유실 가능성 있음
용도	대용량 데이터 저장 및 관리	빠른 응답 시간이 필요한 실시간 처리, 캐싱, 임시 데이터 처리 등에 적합
데이터 복구	디스크에 데이터가 저장되므로 시스템 장애 후에도 데이터를 복구할 수 있음	추가적인 조치(예: 디스크에 스냅샷 저장, 복제 등)가 없는 경우 데이터 복구가 어려움
비용	하드웨어 비용이 상대적으로 적게 듦	대용량의 메모리가 필요하므로 하드웨어 비용이 높을 수 있음

 
 
 

4. Redis Disk 저장 방식: RDB(Snapshot), AOF(Append On File), No Persistence, RDB + AOP

---

💡 Redis Disk 저장 방식

- ‘컴퓨터 메모리’ 내에서 데이터를 저장하고 조작하는 방식이기에 컴퓨터가 꺼지거나 재시작되면 데이터가 사라질 수 있습니다.
- 그렇기에 데이터의 지속성을 위해 메모리에 저장된 데이터를 디스크에 저장하는 방식에 대해서 알아봅니다.

Redis persistence

 
 

4.1. 요약

---

방식	설명	장점	단점
RDB(Redis Database)	설정한 시간 간격에 따라 데이터의 스냅샷을 일정한 시점에 디스크에 저장	빠른 백업 가능, 백업 파일 크기 작음	스냅샷 이후의 데이터 손실 가능, 데이터의 일관성이 중요한 애플리케이션에는 적합하지 않음
AOF(Append On File)	모든 write or update 연산을 로그 형태로 저장	데이터 복구 시점에서 최신의 데이터 상태 유지 가능	로그 파일 크기가 커질 수록 디스크 공간을 많이 차지, 디스크 I/O 부하 큼
No Persistence	디스크에 데이터를 저장하지 않음	디스크 공간을 절약함	서버가 다운되면 모든 데이터가 손실됨
RDB + AOF	RDB와 AOF를 결합한 방식	RDB의 빠른 백업과 AOF의 데이터 일관성 장점을 모두 가짐	디스크 공간과 I/O 부하가 많이 필요함

 
 

4.2. RDB(Redis Database)

---

💡 RDB(Redis Database)

- 설정한 시간 간격에 따라 데이터의 스냅샷을 일정한 시점에 디스크에 저장합니다. 이렇게 하면 빠른 백업이 가능하며 크기가 작아 백업 파일을 다른 서버로 이동하는 것이 용이합니다.

- 그러나 스냅샷을 수행한 이후에 발생한 데이터 손실이 발생할 수 있기 때문에, 데이터의 일관성이 중요한 애플리케이션에는 적합하지 않을 수 있습니다.

https://server-talk.tistory.com/489

 
 
 

4.3. AOF(Append On File)

---

💡 AOF(Append On File)

- 모든 write or update 연산을 로그 형태로 저장하는 방식입니다. 이 방식은 모든 데이터 변경 작업을 디스크에 기록하기 때문에, 데이터 복구 시점에서 최신의 데이터 상태를 유지할 수 있습니다.

- 그러나 로그 파일 크기가 커질수록 디스크 공간을 많이 차지하게 되고, 또한 많은 데이터 변경 작업을 기록하기 때문에 디스크 I/O 부하가 RDB 방식보다 크게 될 수 있습니다.

https://server-talk.tistory.com/489

 

 [더 알아보기 ]

💡 .aof 파일이 로그파일을 의미하는가?

- Redis에서 AOF(Append Only File)는 데이터 변경 작업을 기록하는 로그 파일을 의미합니다. 이 방식은 모든 데이터 변경 작업을 디스크에 기록하기 때문에, 데이터 복구 시점에서 최신의 데이터 상태를 유지할 수 있습니다.

 
 

4.4. No Persistence

---

💡 No Persistence

- 데이터를 디스크에 저장하지 않는 방식입니다. 이 방식은 메모리에만 데이터를 저장하기 때문에 빠른 응답 시간을 제공할 수 있습니다.

- 그러나 서버가 다운되면 데이터가 모두 손실됩니다. 따라서, 데이터의 지속성이 중요하지 않은 일시적인 캐시 등에 사용됩니다.

 
 
 

4.5. RDB + AOF

---

💡 RDB + AOF

- RDB와 AOF의 장점을 결합한 방식입니다. 스냅샷 방식의 RDB와 로그 형태로 데이터를 저장하는 AOF를 동시에 사용함으로써, 빠른 백업 및 데이터 복구 능력을 모두 갖출 수 있습니다.
- RDB는 정기적인 백업을 위해, AOF는 데이터 복구를 위해 사용됩니다. 이 방식은 데이터의 일관성과 복구 능력을 중요시하는 애플리케이션에 적합합니다.

 
 
 

2) Redis 주요 특징 및 사용 목적

---

1. Redis의 주요 특징

---

특징	설명
인-메모리 데이터 구조 저장소	데이터를 컴퓨터 메모리에 저장하여 빠른 속도로 데이터에 접근할 수 있습니다.
키-값 형태의 데이터 구조	다양한 종류의 값(문자열, 리스트, 셋, 정렬된 셋, 해시 등)을 지원합니다.
영구적인 데이터 저장	데이터를 디스크에 저장하는 방식을 사용하면 휘발성 데이터를 영구적으로 저장할 수 있습니다.
고성능	인-메모리 저장, 단순한 데이터 모델, 비동기 복제 등으로 높은 성능을 제공합니다.
다양한 용도	데이터베이스, 캐시, 메시지 브로커 등 다양한 용도로 사용될 수 있습니다.
데이터 복제	비동기식 복제를 지원하여 데이터의 안정성과 가용성을 높입니다.
지속성	RDB와 AOF 방식을 통해 데이터를 디스크에 저장하므로 서버가 다운되더라도 데이터를 복구할 수 있습니다.
싱글 스레드	모든 요청을 순차적으로 처리합니다. 이로 인해 동시성 문제를 피하며, 복잡한 동기화 기법이 필요 없습니다.
클라이언트 샤딩	데이터를 여러 노드에 분산시키는 기법으로, 더 높은 수준의 가용성과 성능을 제공합니다.
Pub/Sub 지원	발행/구독 모델을 지원하여, 메시지 통신이나 이벤트 기반 아키텍처를 구현하는데 이용됩니다.

 
 
 
 

2. Redis의 사용용도

---

사용 사례	설명
캐싱	데이터를 메모리에 저장하여 빠른 읽기/쓰기 작업을 제공합니다. 데이터베이스로부터 반복적으로 데이터를 가져오는 대신, Redis를 사용하여 캐시로서 데이터를 저장하고 조회하는 데 사용됩니다.
세션 저장	웹 애플리케이션에서 사용자 세션 정보를 저장하는 데 주로 사용됩니다. 빠른 응답 시간을 제공하며, 세션 정보를 실시간으로 공유해야 하는 환경에서 유용합니다.
실시간 분석	빠른 읽기/쓰기 성능과 다양한 데이터 구조를 지원하기 때문에 실시간 분석에 사용될 수 있습니다. 웹사이트 방문자 수, 주식 가격 등을 실시간으로 추적하고 분석하는데 사용됩니다.
메시지 큐	발행/구독 및 리스트 데이터 구조를 지원하기 때문에 메시지 큐 시스템으로 사용될 수 있습니다. 서비스 간에 비동기 메시징을 처리하는 데 사용됩니다.
대기열	작업 요청 등을 순서대로 처리하기 위해 사용됩니다. 사용자가 요청을 보내면 이를 대기열에 추가하고, 시스템은 대기열에서 요청을 꺼내서 처리합니다.
속도 제한	특정 시간 동안의 요청 수를 제한하여 서비스의 과부하를 방지합니다. 이는 API 호출 수 제한이나 로그인 시도 횟수 제한 등에 사용될 수 있습니다.

Redis란 무엇입니까? – Amazon Web Services(AWS)

 
 

3) Redis 고 가용성(HA: High Availability) & 확장성(Scalability)

---

💡 Redis 고 가용성(HA: High Availability) & 확장성(Scalability)

- Redis에서 고가용성(High Availability)을 유지하기 위한 방법으로 Redis 서버가 어떠한 장애 상황에서도 계속하여 서비스를 제공할 수 있게 하는 기능을 말합니다. 이를 유지하기 위한 방법으로 ’Master-Slave Replication'과 'Sentinel’의 두 가지 주요 기능을 통해 제공합니다.

- 또한 확장성을 가지기 위해 클러스터(Cluster)를 이용하는 방법으로 확장성을 높입니다.

 
 

💡 Redis 고 가용성(HA: High Availability) & 확장성(Scalability)

- 이를 고려하지 않는 다면 단일 Redis만 존재하는 ‘Standalone’ 형태를 사용하지만 고려한다면 Replication, Sentinel, Cluster를 사용합니다.

 
 

1. 복제(Replication)

---

 💡 복제(Replication)

- 마스터-슬레이브 모델을 사용하여 데이터를 여러 Redis 노드로 복사하는 프로세스입니다. 이를 통해 데이터의 내구성을 향상하고, 읽기 쿼리의 성능을 높이며, 시스템의 가용성을 높일 수 있습니다.

- 마스터 노드에서 시작되며, 슬레이브 노드는 마스터에 연결하여 데이터를 복제하라는 명령을 보냅니다. 마스터 노드는 자신의 데이터 세트를 슬레이브에게 전송하고, 이후에는 모든 새로운 명령(데이터 변경을 일으키는 명령)을 슬레이브에게 전송하여 슬레이브의 데이터 세트를 최신 상태로 유지합니다.

- 슬레이브 노드는 복제된 데이터를 사용하여 읽기 쿼리를 처리할 수 있으므로, 전체 시스템의 읽기 성능이 향상됩니다. 또한, 마스터 노드에 문제가 발생한 경우 슬레이브 노드는 마스터의 역할을 수행할 수 있으므로 시스템의 가용성이 높아집니다.

Redis replication

 
 

💡 Redis 복제(Replication) 방식

- 해당 아키텍처에서는 ‘Master Node’를 기준으로 복제(Replication)를 통해서 ‘Slave Node’를 구성합니다.

- Master node와 Slave node의 동기화 시점은 ‘복제(Replication)’가 수행된 이후 마스터 노드에서 새로운 명령(데이터 변경을 일으키는 명령)을 수행하면 슬레이브 노드에서 데이터를 최신 상태로 유지합니다.
- 데이터 쓰기 작업 : App에서는 Master Node에 데이터를 Write 합니다.
- 데이터 읽기 작업 : App에서는 Slave Node에서 데이터를 Read 합니다.

http://russellluo.com/2018/07/redis-replication-demystified.html

 

[ 더 알아보기 ]

💡 Master Node를 기준으로 Slave Node가 생성되는 시점은 언제인가?

- Slave 노드가 Master에 연결하고 데이터 복제를 요청하는 시점입니다.
- 이 시점에 Master 노드는 자신의 데이터 세트를 Slave 노드에게 전송하고, 이후 모든 새로운 명령(데이터 변경을 일으키는 명령)을 Slave에게 전송하여 Slave의 데이터 세트를 최신 상태로 유지합니다.


💡 Master Node와 Slave Node 동기화가 수행되는 시점은?

- Slave Node가 Master Node에 연결하고 데이터 복제를 요청하는 시점에 시작됩니다.
- Master Node는 자신의 데이터 세트를 Slave Node에 전송하고, 모든 새로운 명령(데이터 변경을 일으키는 명령)을 Slave Node에 전송하여 Slave Node의 데이터 세트를 최신 상태로 유지하게 됩니다. 따라서, Master Node와 Slave Node의 동기화는 지속적으로 이루어지며, 이는 새로운 데이터가 Master Node에 기록될 때마다 발생합니다.


💡 그럼 사실상 복제(Replication) 과정이 수행되면 동기화 작업도 자동으로 이뤄지는 거네?

- 복제(Replication) 과정에서 마스터 노드는 자신의 데이터 세트를 슬레이브 노드에 전송하고, 이후 모든 새로운 명령(데이터 변경을 일으키는 명령)을 슬레이브 노드에 전송하여 슬레이브 노드의 데이터 세트를 최신 상태로 유지합니다. 따라서, 복제 과정이 지속적으로 이루어지면서 동기화도 같이 이루어집니다.


💡 복제(Replication)를 수행하면 메모리를 두 배 사용하는 거 아닌가?

- 복제를 수행하면 각 슬레이브 노드가 마스터 노드의 데이터를 복제하기 때문에, 전체적으로 봤을 때 메모리 사용량은 증가하게 됩니다.
- 그러나 이는 데이터의 내구성을 높이고, 읽기 쿼리의 성능을 향상하며, 시스템의 가용성을 높이는 데 기여합니다. 이러한 이점을 고려하면 메모리 사용량 증가는 투자 대비 효과가 높다고 볼 수 있습니다.

 
 
 
 

2. 보초(Sentinel)

---

💡 보초(Sentinel)

- 주로 마스터- 슬레이브 모델에서 사용되며 Redis 서버의 모니터링, 알림 및 자동 장애 복구를 수행하는 데 사용이 됩니다.
- 기본적으로 분산 시스템에서 "관찰자" 역할을 수행하며, 여러 Redis 서버 또는 인스턴스를 지속적으로 확인하고, 문제가 발생했을 때 알려주며 필요한 경우 자동적으로 복구 작업을 수행합니다.

 
 

💡 보초(Sentinel) 구성 과정

- 해당 구성은 Replication + Sentinel 형태로 구성합니다.
- Replication 내에서는 Master Node와 Slave Node로 구성된 형태로 구성이 되어 있습니다. 해당 과정에서 Sentinel을 두어서 각각 Master Node와 Slave Node를 모니터링합니다.

https://www.stevenchang.tw/blog/2020/12/06/redis-notes-redis-sential

기능	설명
장애 감지(Monitoring)	Sentinel은 Redis 인스턴스(마스터 또는 슬레이브)가 다운되었는지 네트워크 분할이 발생했는지 등을 감지합니다.
자동 장애 복구(Auto Failover)	마스터가 다운된 경우, Sentinel은 슬레이브 중 하나를 새로운 마스터로 승격시키며 나머지 슬레이브들에게 새로운 마스터를 알립니다.
구성 제공(Configuration)	Sentinel은 클라이언트에게 현재의 마스터와 슬레이브에 대한 정보를 제공합니다. 이를 통해 클라이언트는 항상 업데이트된 서버 구성을 알 수 있습니다.
알림 (Notification)	Sentinel은 구성 변경, 서버 다운 등의 이벤트 발생 시 사용자에게 알림을 제공합니다.

[ 더 알아보기 ]

💡 Sentinel을 사용하는 경우 master, slave에 각각 하나씩 가지고 있는 건가?

- 하나의 Sentinel 인스턴스는 여러 Redis 서버(마스터와 슬레이브 모두)를 모니터링할 수 있습니다.
- 일반적으로는 여러 Sentinel 인스턴스를 사용하여 고가용성을 보장하고, 서로 다른 Sentinel 인스턴스들은 서로 통신하여 투표 메커니즘을 통해 마스터 서버의 장애를 감지하고 슬레이브 중 하나를 새로운 마스터로 승격시킵니다. 따라서, 마스터와 슬레이브에 각각 하나의 Sentinel을 두는 것이 아니라, Sentinel 인스턴스는 전체 Redis 아키텍처를 모니터링하는 역할을 합니다.

 
 
 

3. 클러스터(Cluster)

---

💡 클러스터(Cluster)

- 클러스터 구성은 여러 노드로 구성되며, 키 공간은 노드 간에 자동으로 분할됩니다. 이를 통해 높은 성능과 스케일링을 달성할 수 있습니다.

- 데이터는 해시 슬롯을 사용하여 노드 간에 분배되며, 이는 데이터를 균등하게 분산시키고, 노드 추가 또는 제거 시 데이터 재분배를 용이하게 합니다.
- Redis 클러스터는 마스터-슬레이브 복제를 지원하여 데이터 안정성을 보장합니다. 각 마스터 노드는 하나 이상의 슬레이브 노드를 가질 수 있으며, 마스터 노드가 실패할 경우, 슬레이브 노드가 마스터 노드의 역할을 수행하게 됩니다. 이를 통해 장애 시 데이터 손실을 방지하고 서비스의 연속성을 유지합니다.

 
 
 
 

💡 [참고] 종합적으로 Redis를 설명하는데 이해가 잘되는 이미지가 있어서 참고하였습니다.

https://architecturenotes.co/redis/

 
 

 

 

💡 [참고] 해당 글은 다음 글에서 이어집니다.

[DB] Redis(Remote Dictionary Server) 이해하기 -2 : MacOS 로컬 환경 구성 및 명령어

 
 
오늘도 감사합니다. 😀