석수코딩교육

질문)
특정종목의 호가를 읽어올때는, 종목의 호가를 어떻게 redis에 쓰는게 가장 효과적일까요?

답변)

Redis를 **“실시간 주식 호가 시스템”**의 캐시 또는 저장소로 사용할 때,
특정 종목의 호가 정보를 어떻게 구조화할지는 다음과 같은 기준에 따라 결정됩니다:

✅ 설계 시 고려사항

🧩 Redis 구조 설계 예시

아래는 실무에서 자주 사용되는 구조입니다.

✅ (1) 최신 1건만 저장: String 타입

Key 예시:

Value:
바이너리 구조체 / JSON 문자열 / CSV 등

Set 명령 (C 구조체 직접 저장):

특징:

• 최신 1건만 유지
• GET만으로 간단하게 조회 가능
• 만료 설정 가능 (EXPIRE 또는 SETEX)

추천 용도: 실시간 화면에서 “현재가”, “현재 호가”만 빠르게 보여줄 때

✅ (2) 최근 N건을 저장: List 타입

Key 예시:

쓰기 (왼쪽에 넣기):

읽기:

특징:

• FIFO 구조
• 최근 N개를 효율적으로 조회 가능
• 정렬 필요 없음 (시간순)

추천 용도: “최근 호가 변화 내역” 조회 (5초 간격 등)

✅ (3) 시간 기준 정렬 저장: Sorted Set 타입

Key 예시:

쓰기 (timestamp를 score로):

읽기 (범위 조회):

특징:

• 시간 기반 정렬
• 특정 시간 범위 조회 가능
• 오래된 데이터 삭제 용이 (ZREMRANGEBYSCORE)

추천 용도: 과거 10초/1분 단위 호가 변화 분석, 거래소 수신 이력 로그

✅ (4) 한 종목에 다양한 필드를 넣고 싶다면: Hash 타입

Key:

필드: "ask1", "bid1", "ask2", ..., "volume", "time" 등

특징:

• 사람이 보기 쉽고 디버깅 쉬움
• 필드 단위 접근 가능
• 구조가 유연

추천 용도: 웹서버, 모니터링 시스템과 연동할 때 직관적 처리에 유리

🔍 실무 추천 조합

📌 정리

질문)
redis는 일반적으로 메모리에서 데이타를 쓰고 읽어오는걸로 알고 있습니다. redis에 쓰여진 데이타를 파일로 만들어서 파일에서 읽고 쓰고를 할수 있나요?

답변)

Redis 는 “메모리 DB”이지만 디스크에 파일로 남길 수 있어요

중요 !
Redis 는 항상 메모리에 올려 놓고 처리합니다.
RDB·AOF·DUMP 파일은 “백업/복구” 용도로만 사용되고, 실행 중에는 Redis 가 데이터를 RAM 에 유지합니다.

C# 예제 : DUMP 로 파일에 저장 → RESTORE 로 다시 읽기

아래 코드는 StackExchange.Redis(nuget 설치)로 “mykey”를 백업‑복구하는 가장 간단한 흐름을 보여 줍니다.

여러 키를 한번에 백업하려면?

언제 이 방식을 쓰면 좋을까요?

기억해 두세요

• Redis 의 파일 포맷(RDB·AOF·DUMP)은 Redis 전용이라 사람이 직접 편집하거나 파일로 직접 읽고‑쓰기 하는 DB 로 사용하기엔 적합하지 않습니다.
• “파일에서 바로 읽고 쓰는 Redis”는 존재하지 않으며, 항상 메모리에 적재한 뒤 디스크에 주기적으로 동기화하는 구조입니다.
• 코드로 백업/복원할 땐 네트워크·디스크 I/O 예외 처리와 키 수·자료형에 따른 성능 영향을 고려하세요.

이렇게 하면 Redis 데이터를 필요한 시점에 파일로 안전하게 보관하고, 다시 메모리 DB로 신속하게 복구할 수 있습니다!

TCP/IP수신 - REDIS수신 시간비교

공통파일)

1)

A0011.dat 파일을 읽어서 TCP/IP 송신하면, TCP/IP  수신프로그램에서 시간이 어느정도 걸리는지 측정한다.

2)

A0011.dat 파일을 읽어서 REDIS에 송신하면, REDIS 수신프로그램에서 시간이 어느정도 걸리는지 측정한다.

BLPOP과 BRPOP은 Redis의 blocking list operations으로, 특정 리스트에서 데이터가 들어올 때까지 기다리는 명령어입니다. 하지만 두 명령어 사이에는 중요한 차이가 있습니다.

🔹 BLPOP (Blocking Left Pop)   (우리가 원하는것)

• 왼쪽(head)에서 요소를 꺼냅니다.
• 데이터가 없으면 지정된 시간(초) 동안 블로킹(대기)합니다.
• 여러 개의 리스트를 지정하면 먼저 데이터가 들어온 리스트에서 값을 꺼냅니다.

📌 사용 예제:

• mylist의 왼쪽(head) 에서 데이터를 가져오며, 없으면 10초 동안 대기합니다.

🔹 BRPOP (Blocking Right Pop)

• 오른쪽(tail)에서 요소를 꺼냅니다.
• BLPOP과 동일하게 데이터가 없으면 지정된 시간 동안 대기합니다.
• 여러 개의 리스트를 지정하면 먼저 데이터가 들어온 리스트에서 값을 꺼냅니다.

📌 사용 예제:

• mylist의 오른쪽(tail) 에서 데이터를 가져오며, 없으면 10초 동안 대기합니다.

✅ BLPOP vs. BRPOP 차이 정리

• BLPOP은 큐(FIFO) 방식과 유사
• BRPOP은 스택(LIFO) 방식과 유사

🛠 실전 예제 (Python)

Redis의 BLPOP과 BRPOP을 Python에서 실행하는 예제입니다.

BLPOP 예제 (왼쪽에서 꺼내기)

BRPOP 예제 (오른쪽에서 꺼내기)

🔥 BLPOP, BRPOP 사용 시 주의할 점

1. 리스트가 비어 있으면 블로킹되므로, timeout을 설정하는 것이 좋습니다.
2. 멀티 리스트 지원: 여러 개의 리스트를 지정하면 가장 먼저 데이터가 들어온 리스트에서 값을 꺼냅니다.
    

   BLPOP list1 list2 list3 10
   • list1, list2, list3 중 가장 먼저 데이터가 들어온 리스트에서 값을 꺼냄
3. 비동기 처리: BLPOP과 BRPOP은 블로킹 호출이므로, 비동기 처리가 필요한 경우 BRPOPLPUSH나 XREADGROUP을 고려하세요.

🚀 언제 BLPOP과 BRPOP을 사용할까?

✅ 요약:

• FIFO 방식이 필요하면 BLPOP 사용
• LIFO 방식이 필요하면 BRPOP 사용
• Blocking(대기) 방식으로 비동기 처리를 원할 때 유용함

결론)
REAL Version을 사용하지 않아도 REDIS 버퍼를 활용한, 데이타 저장후 처리는 정상적으로 처리되어짐

TRIAL Version 사용시)
2023-10-28  오전 07:44           553,984 ServiceStack.dll
2023-10-28  오전 07:44            33,792 ServiceStack.Interfaces.dll
2023-10-28  오전 07:44            20,480 ServiceStack.ServiceInterface.dll

Exception 발생경우)

정상적인 Insert로직 실행
Exception발생하지 않는 경우는) REDIS로 전송

결론)
REAL Version을 사용하지 않아도 REDIS 버퍼를 활용한, 데이타 저장후 처리는 정상적으로 처리되어짐

C#에서 byte[] 데이터를 Redis에 전송하는 것은 가능합니다. 하지만 Redis는 문자열 기반 저장소이기 때문에, byte[] 데이터를 저장하려면 적절히 직렬화(serialize)하거나 Base64 인코딩을 적용해야 합니다. 다음은 이를 처리하는 방법입니다.

AddItemToList 메서드를 사용할 경우

만약 Redis 클라이언트 라이브러리의 AddItemToList 메서드를 사용하려는 경우, byte[] 데이터를 문자열로 변환해야 합니다. 아래는 Base64 인코딩 방식으로 이를 수행하는 예제입니다.

Redis에서 데이터를 복원할 때

간단한 Redis AddItemToList 및 복원

만약 간단히 데이터를 추가하고 문자열 기반으로 저장하려면 다음과 같이 구현할 수 있습니다.

- BRPop을 사용시에 해결방법

1. data 배열이 byte[][] 형식으로 반환되었을 가능성이 높습니다.
   • data[0]: Redis 키 이름 (byte 배열로 반환됨)
   • data[1]: Redis 값 (Base64 인코딩된 byte 배열)
2. Encoding.UTF8.GetString() 및 Convert.FromBase64String() 메서드는 입력 값이 적절하지 않을 경우 오류를 발생시킵니다.

주요 고려사항

1. 직렬화 사용:
   • byte[] 데이터를 직렬화하여 Redis에 저장할 수 있습니다.
   • 직렬화된 데이터는 나중에 Redis에서 가져올 때 역직렬화(deserialize)하여 원래 데이터로 복원해야 합니다.
2. Base64 인코딩 사용:
   • byte[] 데이터를 Base64로 변환하여 문자열로 저장한 후, 복원 시 Base64 디코딩을 수행할 수 있습니다.

주의사항

1. 데이터 크기:
   • Redis는 데이터 크기에 제한이 있습니다. (일반적으로 하나의 값당 최대 512MB)
   • 데이터 크기가 큰 경우 압축을 고려하세요.
2. 성능:
   • Base64 인코딩은 약 33%의 데이터 크기 증가를 초래합니다.
   • 데이터를 효율적으로 처리하려면 직렬화 방식이 적합합니다.
3. 호환성:
   • 저장된 데이터는 다른 언어/플랫폼에서 접근해야 할 경우 호환성을 고려하세요. Base64는 플랫폼 독립적이지만, 직렬화는 언어/플랫폼 종속적일 수 있습니다.

이제 필요에 따라 Base64 인코딩 또는 직렬화를 선택하여 Redis에 데이터를 저장하고 복원할 수 있습니다!

1. ServiceStack.dll: 1.0.0.0
2. ServiceStack.Interfaces.dll: 1.0.0.0
3. ServiceStack.ServiceInterface.dll: 1.0.0.0

Real)

Trial)

위의 에러는 ServiceStack.Redis 라이브러리를 사용하여 Redis에 요청을 보내는 애플리케이션이 무료 라이선스 제한을 초과했기 때문에 발생합니다.

에러 원인

1. 무료 라이선스 제한 초과:
   • 무료 버전의 ServiceStack.Redis는 한 시간에 최대 6,000개의 Redis 요청을 처리할 수 있습니다.
   • 이 제한을 초과하면 InvalidOperationException이 발생하며, 추가 요청은 차단됩니다.
2. 과도한 Redis 요청:
   • 애플리케이션이 짧은 시간에 너무 많은 Redis 요청을 보낸 경우입니다.
   • Redis에 연결하거나 데이터를 읽고/쓰기 위해 호출한 횟수가 누적되어 제한을 초과했을 가능성이 큽니다.
3. ServiceStack 버전 문제:
   • 무료 버전의 ServiceStack(버전 4 이상)은 상용 라이선스가 필요합니다.
   • 버전 3은 무료로 사용 가능하지만, 제한된 기능만 제공되며 유지 관리되지 않습니다.

해결 방안

1. 라이선스 업그레이드:
   • ServiceStack의 상용 라이선스를 구매하여 요청 제한을 제거합니다.
   • ServiceStack 라이선스 페이지를 방문해 적합한 요금제를 선택하세요.
2. ServiceStack V3로 다운그레이드:
   • 무료로 사용 가능한 ServiceStack V3를 사용하면 요청 제한 없이 작업할 수 있습니다.
   • 다운그레이드 가이드: ServiceStack V3 GitHub
3. Redis 요청 최적화:
   • 애플리케이션에서 Redis 요청을 줄이는 방법을 고려하세요:
     • Batching: 여러 요청을 한 번의 요청으로 묶어 처리.
     • Caching: 자주 조회하는 데이터를 Redis 외부에서 캐싱.
     • Connection pooling: Redis 연결 관리 개선.
   • 예를 들어, Redis에 데이터를 저장하기 전에 중복된 요청이 있는지 확인하세요.
4. 대안 라이브러리 사용:
   • ServiceStack 외에 다른 Redis 클라이언트를 사용하는 것도 고려할 수 있습니다. 예를 들어:
     • StackExchange.Redis
     • CSRedis
5. 제한 우회 (임시):
   • 요청이 집중적으로 발생하지 않도록 로직을 수정하여 요청 간 딜레이를 추가하거나, Redis 사용량을 분산시킵니다.

필자.내용)

Redis(Message Queue)를 사용하면, 데이타를 안정적으로 처리할수 있습니다.
데이타를 파싱.즉 구조체변환후에 데이타입력하는 처리과정은 생각보다 많은 소요시간이 필요합니다.

Request To CHAT.GPT) 위를 전산용어를 이용해서 표현해 주세요
필자.내용의 Request에 대한 CHAT.GPT.Response)

Redis(Message Queue)를 사용하면, 데이터의 안정적인 처리와 비동기적인 작업 분배가 가능합니다. 데이터 파싱 및 구조체 변환 후 실제 데이터 입력 과정은 많은 시스템 자원과 시간이 소요되는 복잡한 처리 단계로, 이는 종종 CPU 집약적인 작업 또는 I/O 대기 시간이 발생하는 데이터 변환 처리라고 할 수 있습니다.

따라서, 이러한 처리 시간을 효율적으로 관리하기 위해 비동기 메시지 큐를 사용하여 워크로드 분배 및 병렬 처리를 최적화할 수 있습니다. 이 방식은 처리 과정에서 발생할 수 있는 병목 현상을 완화시키고, 스케일링을 통해 시스템의 안정성을 높이는 데 기여합니다.