항해 99 42일 차

Redis

1. Redis & Cache

• Cache : 나중에 요청할 결과를 미리 저장해둔 후 빠르게 서비스 해주는 것. 미리 결과를 저장하고 나중에 요청이 오면 그 요청에 대해서 DB 또는 API를 참조하지 않고 Cache에 접근해서 요청을 처리한다.

[progress]

1) Client로부터 요청을 받는다.

2) Cache에서 이미 들어왔던 작업인지 확인한 후 만약 참이면 Cache 내용을 리턴한다.

3) 거짓이라면 DB or Server에 접근해서 작업한다.

4) DB를 접근했기 때문에 한번 들어온 내용은 Cache에 저장이 되고 따라서 다시 Cache와 작업한다.

• Redis(Remote Dictionary[key,value] Server, 원격 사전 서버)

[properties]

1) In-Memory database로 read/write가 빠른 NoSQL이다.

2) Persistence(영속성)를 지원하므로 서버가 꺼지더라도 다시 data를 불러들일 수 있다.

3) key-value 형태로 data를 저장하기 때문에 별도의 쿼리 없이 key로 value를 찾을 수 있다.

4) Data Collection : String, List, Set, Sorted Set, hash

5) Memory 기반의 DB이므로 get, put을 이용해서 데이터를 넣고 빼는 것이 가능하다.

💡 Redis Collection(자료구조)와 명령어

 

1) String(key-value : One-To-One Mapping)

• get : key에 해당하는 value 리턴
• set : key에 value 저장
• del : key 삭제

2) List(순서가 있는 String 묶음으로 array형식의 데이터 구조이다. 자바의 linked list와 유사하다. 처음과 끝에 데이터를 삽입/삭제는 빠르지만, 중간에 데이터를 삽입하는 것이 어렵다.)

• lpush <key><value> : left, 첫번째(index:0)에 데이터 삽입
• rpush <key><value> : right, 마지막(index:-1)에 데이터 삽입
• lpop <key><value> : left, 첫번째(index:0)에 데이터 삭제
• rpop <key><value> : right, 마지막(index:0)에 데이터 삭제
• lrange <key><s><e> : s부터 e index의 데이터 반환

3) Sorted Set(Set과 마찬가지로 순서가 없는 String의 묶음. 다른점은 score를 통해 순위를 매겨 오름차순으로 정렬이 가능하다. 만약, score값이 같으면 value로 정렬한다. 여기서 set의 value는 member이다. value는 중복이 불가능하지만, score 값은 중복이 가능하다.)

• zadd <key><score><member> : key에 score와 member 추가
• zcard <key> : member count 조회
• zcard <key><s><e> : s부터 e까지 index의 member 반환
• zrangebyscore <key><min><max> : min부터 max까지 해당하는 score 값을 갖는 member 반환
• zrem <key><member> : member 삭제

4) Hash(key내부에 key-value가 존재하는 자료구조이다. key의 Filed는 subkey로 갯수에 제한이 없다. 여러가지 Object type을 저장할 수 있다.)

 

• hset <key><field><value><field><value>.. : 하나의 key에 여러 field-value 저장
• hget <key><field> : key와 field에 해당하는 value 리턴
• hdel <key><field> : field 삭제
• hlen <key> : field count 리턴
• hgetAll <key> : 모든 field-value 쌍 반환
• hkeys <key> : 모든 field 리턴
• hvals <key> : 모든 value 리턴

[Reference]

[Redis] 레디스와 캐시 그리고 데이터구조

2.pub/sub Model

<aside> 💡 Kafka VS Redis Cluster에서 Pub/Sub 동작원리

</aside>

*차이점 요약: pub/sub을 다루는데 있어서 kafka가 훨씬 무겁다.

 

1) pub/sub 모델에 대한 이해

2) Kafka pub/sub model

kafka 는 producer/consumer(publisher/subscriber)가 있는데 producer가 Topic에 이벤트를 보내고 이 이벤트는 Topic의 각 Partition에 분산되어 저장된다. Topic을 구독하고 있는 Consumer group 내의 Consumer는 각각 1개 이상의 partition으로부터 이벤트를 가져온다. 만약 partition 개수보다 consumer개수가 많다면 아무 일도 하지 않는 consumer가 생기기 때문에 항상 partition의 수를 consumer의 수 이상으로 해주는게 좋다.

3) Redis pub/sub model

Redis의 pubsub은 그룹이라는 개념이 존재하지 않고 각 subscriber가 channel을 구독하고 있다. 여기서 kafka와의 가장 큰 차이점으로 channel은 이벤트를 저장하지 않는다. 이벤트가 도착했을때 채널의 subscriber가 없다면 이벤트는 증발한다. 또한 응답을 받지 못하기 때문에 완벽한 이벤트의 성공을 보장하지는 못한다.

 

Kafka는 redis보다 더 다양한 기능이 있고 세밀하게 성능 및 기능을 조정할 수 있다. 그러나 Redis도 kafka처럼 사용할 수 있으므로 Event queue가 무겁고 core하게 pub/sub 기능이 필요하다면 kafka를 추천하고 단순한 이벤트큐로 가볍게 사용하려고 한다면 redis를 권장한다.

 

💡 Back to Redis(Kafka는 이후에 다뤄보도록 하겠다.)

 

1) server.pubsub_channels → server측에서 channel을 저장하는 구조

 

pubsub_channel는 채널을 저장하는 dict 구조체를 가리킨다. dict 구조체는 여러개의 dictEntry를 가지고 있고 각 Entry는 key:robj channel, value:list 타입인데 list는 linked list로 이루어져 있다.

public 동작 과정은 다음과 같다. PUBLISH channel_name message → dict(hash table)에서 channel을 찾고 그 value에 있는 linked list를 돌면서 client들에게 메세지를 보낸다.

 

2) server.pubsub_patterns → server 측에서 pattern을 저장하는 구조

 

PUBLISH channel_name message → 일단 pubsub_channels 에서 처럼 channel 명으로 클라이언트에 메시지를 보낸 다음  를 돌며 패턴에 맞는 client에게 메시지를 보낸다. (pattern을 보면 robj 라는 단어가 붙어있는데 저건 redis object라고 생각하면 된다. 참고로 redis는 C언어로 개발되어있다.)

1. STOMP & Redis

[INTRO]

💡 Why using Redis?

 

1) 채팅방의 메인 저장소가 없어 server의 memory에 적재된 채팅방은 server을 재시작 할때마다 초기화된다. 따라서 DB를 이용하거나 저장소가 필요한데 Redis를 저장소로 사용할 수 있다.

2) STOMP에서 지원해주는 pub/sub 기능을 사용하면 pub/sub이 발생한 server 내에서만 메세지를 주고받는 것이 가능하다. 즉, subscribe 대상인 topic(채팅방)이 생성된 server안에서만 유효하므로 다른 서버로 접속한 client는 해당 채팅방이 보이지 않고, 구독도 불가능하다. 이는 Redis에서 지원하는 pub/sub을 이용해서 해결할 수 있다.