기술 및 인프라 → Redis: 메모리 내 솔루션

Redis: 메모리 내 솔루션

1) Redis가 적절한 곳

• 캐시 (읽기/제외, TTL, SWR) 및 세션.
• 카운터 및 할당량: 요율 제한, 사기 방지, 캠페인 제한.
• 리더 보드/등급 (ZSet), "상위 N" 권장 사항.
• 이벤트 대기열/버스 (스트림/PubSub), 아웃 박스/받은 편지함, 배송.
• Idempotence (TTL이있는 키), 디 덤업 웹 후크.
• 지오 (가장 가까운 지점 검색), 비트 맵 (플래그, DAU).
• 별칭/토큰 및 단기 승인 캐시.

2) 데이터 구조 및 적용 시점

문자열: 값/카운터 ('INCRŁ'), demempotent 키.
해시: 프로파일/구성 요소 집계, "경량" 객체 저장.
목록: 간단한 대기열 (그러나 재생/오프셋 의미론은 없음).
고유 한 요소, 중복 제거.
ZSet: 속도별로 정렬 (리드 보드, TTL 캘린더- "지연된" 이벤트).
스트림: 소비자 그룹, 'XREADGROUP '/재생-웹 후크, CDC, 배상을위한 안정적인 대기열.
지오: 'GEOADD/GEORADIUS' -가장 가까운 포인트/판매자.
Bitmap/Bitfield: 일련의 플래그 (일별 로그인, DAU/WAU).
HyperLogLog: 대략적인 Unique (UU) 는 메모리가 저렴합니다.
Bloom/Cuckoo (모듈): 빠른 가용성 검사, "MISS" 소스를 줄입니다.

• RedisJSON (JSON 문서), RediSearch (인덱싱/검색), RedisBloom (확률 구조), TimeSeries (메트릭/집계).

3) 키, TTL 및 메모리 정책

tenant:{t}:domain:{d}:{entity}:{id}:v{schema}    region={R}    currency={C}    lang={L}

Versioning ('vN') 에는 의미있는 차원 (지역/통화/언어/테넌트) 만 포함됩니다.
임차인 당 키 공간을 분리하십시오.

• TTL 매트릭스 (sec/min/hr) 를 사용하고 각인을 피하기 위해 지터 (λ10-20%) 를 추가하십시오.
• 핫 키의 경우-새로 고침 및 단일 비행 (하나의 리더 업데이트).

• 'allkeys-lru/lfu' 는 TTL 종속성이없는 공유 캐시입니다.
• '휘발성 -lru/lfu' -TTL이있는 키 만 있습니다.
• 'noverse' -오버플로시 쓰기 실패 (중요한 대기열/카운터에 안전).
• (PHP 3 = 3.0.6, PHP 4)

4) 거래, 파이프 라인 및 스크립트

파이프 라인: RTT, 그룹 10-100 팀을 줄입니다.
트랜잭션 (MULTI/EXEC) -읽기를 분리하지 말고 배치를 원자 적으로 실행하십시오.
최적의 잠금: 'WATCH key' → MULTI/EXEC → 확인.
Lua 스크립트: 서버 측의 원자 논리 (속도 제한, 잠금 장치, 복합 작업).

5) 대기열 및 버스: List vs Stream

목록 + 'BRPOP' -간단하지만 소비자 그룹, 오프셋/재생, 방울에 대한 약한 저항은 없습니다.
스트림: 'XADD → XREADGROUP → XACK', 재 시도-데드 레터 (N 분 안에 가져 가지 않음), 키로 분할. PSP/KYC 웹 후크, 지연된 지불/알림에 대해 권장됩니다.

우선 순위 대기열: 우선 순위별로 여러 스트림, 소비자는 처음부터 "빨리" 빠집니다.
연기 된 작업: ZSet 여기서 점수 = 타임 스탬프; 주기적인 'ZRANGEBYSCORE' λ는 이제 → 스트림으로 옮겨졌습니다.

6) 높은 가용성 및 확장 성

복제: 마스터 → 복제본 (읽기 규모).
센티넬: 자동 장애 마스터, 발견, 클라이언트 URI.
Redis 클러스터: 16384 슬롯 샤딩, 수평 스케일 아웃. '{순서: 123}' 해시 태그로 여러 구조를 사용하는 랩 키.

• 캐시/세션-클러스터/복제본, '클라이언트 측 해싱' SDK 지원.
• 대기열/스트림의 경우-크로스 슬롯 작업을 최소화합니다. 도메인 키로 파티션.

7) 지속성: RDB, AOF 및 백업

RDB (스냅 샷): 더 빠르고 경제적 인; 마지막 초/분의 손실 위험.
AOF (저널): 손실 감소; 'Everysec/항상' 모드. AOF 압축 및주기적인 재 포장.
하이브리드: RDB + AOF → 빠른 복구 + 중간 손실.

백업: 오브젝트 스토리지에 대한 스냅 샷 및 AOF 사본; 정기적으로 회복을 확인

중요한 대기열/dedempotency의 경우 AOF 'everysec' + 복제를 선택하십시오.

8) 안전 및 준수

λH/ACL: 응용 프로그램 당 역할, "위험한" 명령 금지 ('FLUSHALL', 'KEYS').
클라이언트-서버 및 노드 간 링크에 대한 TLS; 고정 출구 IP.
네트워크 세분화: 개인 서브 넷, SG/NACL; 필요한 서비스/네임 스페이스에서만 액세스하십시오.
비밀을 기록하지 마십시오. Redis의 PAN/PII - 토큰/파생 상품 만 해당.
주요 명령: 'KEYS' 를 피하십시오-' SCAN '을 사용하십시오.

9) 관찰 및 SLO

• 대기 시간 (P95/P99), '순간 _ ops _ sec', '연결된 _ clients'.
• (PHP 3 = 3.0.6, PHP 4)
• 메모리: 사용, 단편화 비율, RSS, 할당자 통계.
• 복제 지연, AOF/RDB 주파수 및 크기, 포크 시간.
• 스트림: PEL (보류중인 항목 목록), 배송 대기 시간, 재 시도 카운트.

• Redis P99 연산은 5-10ms입니다.
• 퇴거는 시간당 1% (캐시 공간) 입니다.
• 스트리밍 전달 P99

10) FinOps 및 자원 계획

메모리는 비싸다: $/GB 월간 RAM과 원산지/DB 저장 요청 측정.
값 압축> 1-2KB를 사용하십시오 (CPU 참조).
LFU는 볼륨이 적을수록 더 나은 타격을 줄 수 있습니다.
Redis가 아닌 이미지/큰 얼룩의 경우 CDN+ 객체 저장소를 사용하십시오.

11) iGaming/fintech 패턴

11. 1 요율 제한 (루아)

아이디어: 창 키 + TTL의 'INCRŁ'; Lua는 원자 적으로 한계를 점검하고 증가합니다.

lua
-- KEYS[1]=key ARGV[1]=limit ARGV[2]=ttlSec ARGV[3]=inc local cur = redis. call('INCRBY', KEYS[1], ARGV[3])
if cur == tonumber(ARGV[3]) then redis. call('EXPIRE', KEYS[1], ARGV[2]) end if cur > tonumber(ARGV[1]) then return {0, cur} else return {1, cur} end

11. 2 요청 demmpotence

키 'idemp: TTL 24h, 값-결과/상태를 갖는 {요청 _ id}'. 작업을 수행하기 전에 존재를 확인합니다.

11. 리더 보드 3 개

'ZINCRŁ리더 보드: 게임: {g} 점수 사용자: {u}' → 'ZREVRANGE... WITHSCORES '.
지역/테넌트 별 상위 N-개별 ZSet 또는 접두사.

11. 4 PSP 웹 후크 큐

'XADD psp: 웹 후크... '→ 소비자 그룹' XGROUP CREATE psp: webhooks g1 $ '.
PEL 스캔 ('XPENDING' → 'XCLAIM') 을 통한 "고정 된" 메시지 배열.

11. 5 지불 연기

ZSet 'payout: due' (score = epoch) → 작업자는 정기적으로 완성 된 아이템을 중복 제거하여 Stream 'payout: exect' 로 이전합니다.

11. 6 사기 방지 미터

'PFADD' (고유) + 'INCR' (강도) + 지리/ASN 태그의 조합; 수동 검증을위한 트리거.

12) 메모리 및 성능 작업

클라이언트 연결 풀; RTT 감소 (유지).
명령 팩에 파이프 라인을 선호하십시오.
큰 키 ('MEMORY USAGE', 'SCAN') 를보십시오. 물체를 나누는 것이 좋습니다.
필드가 적은 해시는 많은 개별 키보다 경제적입니다.
테스트로 이익을 확인하면 io 스레드 (읽기 무거움) 를 사용하십시오.
prod에서 빈번한 'FLUSHDB/ALL' 을 피하십시오. 안전한 삭제를 위해 접두사 및 'UNLINK' 를 통해 관리하십시오.

13) 다중 임차인 및 격리

개별 클러스터/인스턴스 또는 테넌트 당 논리적 DB (부하가 작은 경우).
키/메모리 할당량, 분할 ACL.
네임 스페이스별로 키 및 메트릭의 접두사.

14) 잠금 및 일관성

SET 키 발 NX PX = ttl-간단한 돌연변이.
Redlock: 신중하게 사용하십시오 분산 중요 거래의 경우 "진실의 원천" (DB/원장) 및 dem 등원 작업에 의존하는 것이 좋습니다.
"긴" 잠금 장치 대신 원자 작업 및 Lua를 선호합니다.

15) 반 패턴

대형 블롭/이미지 저장-RAM 및 네트워크의 과부하.
Redis에서만 재무 불변량 (대차 대조표).
'KEYS' 와 '세계를 스캔' 하십시오.
TTL/지터 없음-만료시 도그 파일.
중요한 대기열에 대한 '모두-' 정책 → 압력시 데이터 손실.
할당량과 우선 순위없이 대기열, 캐시 및 세션을 혼합합니다.
클러스터의 다른 슬롯 키에서 작동하는 Lua 스크립트.

16) 구현 점검표

1. 역할 정의: 캐시/세션, 대기열/스트림, 카운터/제한-인스턴스/클러스터에 게시합니다.

2. 작업에 대한 최대 메모리 정책을 선택하십시오. 제한을 설정하고 퇴거를 모니터링

3. 키 이름 지정, 회로 버전, TTL 행렬 + 지터; 최고 키를위한 단일 비행.
4. 대기열의 경우 - 스트림 (그룹, retrays, DLQ), 지연된 - ZSet + 전송.

5. HA: 복제 + Sentinel 또는 Redis Cluster; 클라이언트 장애를 확인하십

6. 지속성: 스크립트에 따른 RDB/AOF; 정기적 인 백업 및 복구 테스트.
7. 보안: ACL, TLS, 개인 네트워크, 위험한 명령 금지.
8. 관찰 가능성: 대기 시간, ops/sec, 메모리, 퇴거, 복제 지연, 스트림 PEL.
9. FinOps: 메모리 프로파일, 큰 키, 압축, LFU; 큰 얼룩은 Redis를 피하십시오.
10. 패턴 문서 (속도 제한, demotency, 리드 보드) 및로드 테스트.

결과

Redis는 캐시, 대기열, 카운터, 리드 보드, 지리 및 확률 구조와 같은 속도의 "다기능 스위스 나이프" 입니다. 그 강점은 올바른 데이터 구조 선택, TTL/장애 분야, 운영 원자 성, 잘 생각 된 HA/지속성 및 관찰 성에 있습니다. 밀리 초 및 높은 RPS가 중요한 경우 Redis를 사용하고 중요한 불변량 (돈, 회계) 을 "진리의 원천" 에 남겨 두십시오. 이러한 방식으로 플랫폼은 빠르고 신뢰할 수 있습니다.