Redis 특징

-In-Memory : 모든 데이터를 RAM 에 저장 (백업/ 스냅샷 제외)
-Single Threaded : 단일 thread에서 모든 task 처리
-Cluster Mdoe : 다중 노드에 데이터를 분산 저장 -> 안전성,고가용성 제공
-Persistence : RDB(Redis Database) +AOF(Appen only file) 통해 영속성 옵션 제공
-Pub/Sub : Pub/Sub패턴 지원을 통한 손쉬운 어플리케이션 개발(채팅,알람)

Redis 사용사례

1.캐싱

• 임시비밀번호
• 로그인세션

2.Rate Limiter

• Fiexed-Window / Sliding-Window Rate Limiter (비율 계산기)
• API 요청 횟수 제한

3. Message Broker

• 메시지 큐

4. 실시간 분석 /계산

• 순위표
• 반경 탐색
• 방문자 수 계산

5. 실시간 채팅

• Pub/Sub 패턴

Redis 알아보기

1. Persistence(영속성)

• 주로 캐시로 사용되지만 SSD와 같은 영구적인 저장 장치에도 저장할 수 있다

2. RDB(Redis Database)

• 특정시간에 스냅샷 만드는 기술
• 장애발생 -> 특정시간 스냅샷으로 이동 (최근 스냅샷으로 가는 도중 데이터 유실 발생 가능성 있음)
• 스냅샷 생성중 전체 Redis 성능저하 특징

3. AOF(Append Only File)

• Redisd에 적용되는 Write를 모두 Log로 저장
• 데이터 유실 위험 적지만 장애 복구시 Write 작업을 다시 적용해야 하기 때문에 RDB보다 느림

Cache Hit / Cahche Miss

• 특정 key에 대한 데이터가 있어서 정상적으로 응답하는 경우 cahce Hit, 그 반대로는 Cache Miss

Cache-Aside pattern

• 캐쉬에서 먼저 찾고 없으면 실제 DB 들어가서 데이터 가져오는 패턴

Redis CRUD

Redis 데이터타입 (String)

• SET key value

• MSET price 100 language ko -> 다수의 string 값 한번에 저장(key,value,key,value)

• MGET lecture 100 language -> 다수의 값 반환

• INCR price -> 별도의 Integer 타입 없이 String으로 저장, 더하기 빼기 가능 (1더하기)

• INCR price 10 -> 특정 숫자만큼 저장 가능

• SET lecture '{"key": 100 , "language" : "ko"}' -> Stinrg으로 저장한뒤에 사용할때
  는 Json으로 바꿔줘야함

• SET key:ko:price 200. -> redis에서는 : 로 의미단위 부여

Redis 데이터타입 (List)

• String을 Linked List로 저장 -> push/pop에 최적화(양끝에 데이터 추가삭제)
• Queue(FIFO) / Stack(FILO) 구현에 사용함

• LPUSH queue job1 job2 job3
• RPOP queue

• LPUSH stack job1 job2 job3
• LPOP stack

• job 2 순으로 -1 -> -2 -> ...

• job5 순으로 0 -> 1 -> 2

• LPUSH queue job1 job2 job3

• LRANGE queue -2 -1 -> 인덱스로 여러 데이터 조회가능

• LTRIM queue 0 0 -> 남기고 싶은 인덱스 지정후 나머지는 삭제

Redis 데이터타입 (set)

• Unique String을 저장하는 정렬되지 않은 집합
• 중복불가,순서보장 x 교집합, 합집합 출력 가능

• sadd 로 저장 / smembers 로 조회
• 중복 데이터(orange) 저장 불가

• scard key
• scard 로 value몇개 들어있는지 확인

• sismember key 확인하고싶은value
• sismember 로 해당 키값에 value가 있는지 확인

• sinter key key 로 교집합(value) 확인

• sdiff key key
• 앞에있는 키값에만 있는 value 출력

• sunion key key
• 합집합

Redis 데이터타입 (Hashes)

• hset key field1 값1 field2 값2
• 하나의 키값에 키벨류 , 키벨류 형태로 저장

• hmget key field1 field2 field3
• 한번에 여러 필드 값 출력

• hincrby key field 원하는값
• 원하는 값만큼 증가

Redis 데이터타입 (Sorted Sets)

• Set 특성 + score를 통해 정렬된 집합
• 내부적으로 Skip List + Hash Table로 이루어져 있고, score값에 따라 정렬 유지

• 같이 전달한 값에 따라 정렬됨, 그것에 따라 각 멤버의 인덱스가 정해져 있음

• zrank key target
• 해당하는 target이 sorted set에서 몇번째인지 알수 있음(=index)

Redis 데이터타입 (Stream)

• field-value로 추가가능 (이벤트 스트림)

• append-only log(수정,삭제가 없고 추가만 있는)에 consumer groups과 같은 기능을 더한 자료구조

• unique id를 통해 entry를 읽을 때, 0(1) 시간 복잡도를 가지게 된다

• Consumer Group를 통해 분산 시스템에 다수의 consumber가 event처리

• 동일한 메세지 여러번 처리 방지

• xadd 를 통해 events 라는 스트림을 만들며 * 를 통해 unique_id생성

• id 값은 entry가 추가된 시간 - 그시간대에 동일하게 event가 발생할수 있기때문에 몇번째인지 나타냄

• user_id 1 인 유저가 product_id 1 좋아요를 누른 이벤트를 생성한것

• xrange 스트림이름 - +

• 가장 처음 이벤트부터 마지막 이벤트 까지 조회

• xdel 스트림이름 고유Id
• 이벤트가 끝나고 삭제시

Redis 데이터타입 (Geospatials)

• 좌표를 저장하고 검색하는 데이터 타입
• 거리 계산, 범위 탐색 등 지원

Redis 데이터타입 (BitMap)

• 실제 데이터 타입은 아니고, String에 binary operation을 적용한 것

• 최대 42억개 bianry 데이터 표현

• setbit 키 value

• bitcount 키 -> 해당 1이 몇개인지 카운트

• bitop and result 키1 키2 -> 키1 ,키2 에 공통 결과값 출력
• 결과값이 바로 나오는게아니라 result 위치 변수(?)에 담아준다

Redis 데이터타입 (HyperLoglog)

• 집합의 cardinality(높으면 중복 적음)를 추정할 수 있는 확률형 자료구조(= 결과값이 실제와 오차가 발생할 수 있다)

• 정확성을 일부 포기하는 대신 저장공간을 효율적으로 사용, 근사치만 필요할때 사용

• Set에 비해 실제 값을 저장하지 않기 때문에 매우 적은 메모리지만 모든 아이템을 다시 출력 해야하는 경우에는 사용 불가

Redis 데이터타입 (BloomFilter)

• element가 집합 안에 포함되어 있는지 확인할 수 있는 확률형 자료 구조 (=membership test)

• 실제 값을 저장하지 않기 때문에 매우 적은 메모리 사용

• element가 집합에 실제로 포함되지 않는건 정확히 나오지만, 실제로 포함되지 않았는데 포함되었다고 잘못 예측하는 경우(=false positive)

• 하지만 그 반대의 경우, 집합에 실제로 있는건 무조건 있다고 나옴

  

• apple, orange가 추가되고 grape같은 경우 오른쪽 해쉬키는 표시되어있지 않아 포함되어 있지 않다는건 알수 있지만 키위같은 경우에는 false positive 발생

Redis 특수 명령어

1.Expiration

• 데이터를 특정시간 이후에 만료 시키는 기능

2.TTL(Time To Live)

• 데이터가 유효한 시간(초 단위)

3.특징

• 데이터 조회 요청시에 만료된 데이터는 조회 x

• 데이터가 만료되자마자 삭제하는게 아니라 만료로 표시했다가 백그라운드에서 주기적으로 삭제

• TILL 로 유효시간 초단위로 확인

• -1이면 설정되지 않았다는뜻, -2면 만료

• setex 로 저장과 동시에 만료시간 설정 가능

4 NX/XX

1.NX

• 해당 key가 존재하지 않는 경우에만 SET

2.XX

• 해당 key가 이미 존재하는 경우에만 SET

-> SET이 동작하지 않은 경우 (nil) 응답

5.Pub/Sub

• Publisher와 Subscriber가 서로 알지 못해도 통신이 가능하도록 decoupling된 패턴

• Publisher는 Subscriber에게 직접 메세지를 보내지 않고, Channel에 Publish

• Subscriber는 관심이 있는 Channel을 필요에 따라 Subscribe하며 메세지 수신

• Redis Stream은 메세지가 보관되지만, Pub/Sub은 Subscribe하지 않을때 발행된 메세지는 수신불가

6. Pipeline

• 다수의 명령어를 한 번에 요청하여 네트워크 성능을 향상 시키는 기술

• Round-Trip Times 최소화(= Request/Response 모델에서 발생하는 네트워크 지연 시간)

• 대부분 레디스 클라이언트 라이브러리에서 지원

7. Transaction

• 다수의 명령을 하나의 트랜잭션으로 처리 -> 원자성 보장

• 중간에 에러가 나면 롤백

• 하나의 트랜잭션이 처리되는 동안 다른 클라이언트 요청 x

• pipeline 은 네트워크 퍼포먼스 향상을 위해 여러 명렁어 한번에, Transcation은 작업의 원자성 보장을 위해 다수의 명령을 하나처림 처리하는 기술 -> 둘다 동시에 사용 가능

• multi : 트랜잭션 시작
• incr foo : foo 1증가
• discard : 롤백
• exec : 반영

데이터 타입 활용

OTP

분산락

• 분산 환경의 다수의 프로세스에서 동일한 자원에 접근할 때, 동시성 문제 해결
• 보통 DB에서 락을 걸고 사용하는게 안전하지만 성능저하 이슈나 락을 사용하지 못하는 환경일 경우 사용

Rate Limiter

• 시스템 안정성/보안을 위해 요청의 수를 제한하는 기술
• Fixed-window Rate Limiting -> 고정된 시간안에 요청 수를 제한하는 방법

SNS Activity Feed

• activityy Feed -> 사용자 또는 시스템과 관련된 활동이나 업데이트를 시간순으로 정렬하여 보여주는 기능
• Fan-out -> 단일 데이터를 한 소스에서 여러 목적지로 동시에 전달하는 메시징 패턴

Shopping Cart

• SADD 명령어를 통해 저장하고 상품 리스트를 볼때 SMEMBERS 로 조회

Login Session

• login session -> 사용자의 로그인 상태를 유지하는 기술
• 동시 로그인 제한 -> 로그인시 세션의 개수를 제한하여, 동시에 로그인 가능한 디바이스 개수 제한

Sliding Window Rate Limiter

• 시간에 따라 Window를 이동시켜 동적으로 요청수를 조절하는 기술

• fixedWindow는 고정시간이 지나면 초기화

• sortedSet에 score대신 unixtime 저장해 구현

Geofencing

• 위치를 활용하여 지도 상의 가상의 경계 또는 지리적 영역을 정의하는 기술

• GEOADD 명령어를 통해 좌표값을 value로 저장해주고 GEORADIUS 명령어로 특정범위 안에 있는 value출력 가능

Online Status

• 사용자의 현재 로그인 상태 표시

• bitmap 활용

Visitors Count

• 방문자수 제공시, 정확한 횟수말고 대략적인 데이터만 알고자 하는 경우

• hyperloglog사용

• 값을 저장할때 같은 유저 중복을 한번만 카운팅할수도 있고 unixtime 초당요청을 다르게 카운팅 할수도있다.

BloomFilter

• Unique Events -> 동일 요청이 중복으로 처리되지 않기 위해 빠르게 해당 item이 중복인지 확인하는 방법

• 처음 조회시 bloomfilter에서 찾고 없으면 db조회 후 bloomfilter 체크

• 조회시 bloomfilter 체크상태이면 false positive 일수도 있기때문에 원본 데이터 소스를 한번 더 조회하고 데이터 처리

Redis 주의사항!

1.기본

• Redis는 싱글쓰레드 이기 때문에 오래걸리는 O(N)명령어 수행시 전체적 어플리케이션 성능 저하

• KEYS 명령어는 모든키를 조회하기 때문에 성능저하 발생, -> SCAN 명령어를 사용하자

• SMEMBERS도 SET의 모든 값들을 반환하기때문에 느림 -> 하나의 set에 만개이상 저장 x 또는 SET 분리

• HGETALL 도 hash의 모든 field를 반환하기때문에 느림 -> Hash 분리

• SORT 도 정렬해서 반환하기 때문에 주의해야함!

2. Thundering Herd Problem

• 병렬 요청이 공유 자원에 대해서 접근할때, 급격한 과부하가 생기는 문제

• 캐쉬가 없어지고 그 요청들이 한번에 DB에 가버리는 문제(캐쉬만료로 인한 문제)

• 세밀한 캐쉬 조정 필요(크론잡을 통해 캐쉬 데이터 항상 최신화 시켜주기)

• 레디스 사용시 캐시 관리도 잘 해야함!

3. Statle Cachec Invalidation

• 캐시의 유효성이 손실되었거나 변경되었을 때, 캐시를 변경하거나 삭제하는 기술