반응형
 Cache 란 무엇인가부터 개념을 잡아야 한다.
 Cache는 빠른 속도를 위해서 사용하게 된다.

 Cache를 사용하게 되면, 보통 Key-Value 타입을 사용하게 되면, 쿼리를 파싱하는 시간도 없어지고, 훨씬 접근 속도가 빠른 메모리에서 읽어오게 되기 때문에, 거기서 많은 속도 차이가 나게 됩니다. 다음은 DB 서버의 CPU 사용량입니다. Cache를 적용한 이후부터, 전체적으로 Wait I/O가 많이 떨어지는 것을 볼 수 있습니다.

Select와 Qcache_hits 는 거의 1/10 수준으로 줄어버립니다. DB서버로의 요청이 줄어버려서, 전체 서비스가 좀 더 큰 요청이 들어와도 버틸 수 있게 해줍니다.

캐싱(Caching)은 말 그대로 미리 읽어두었다가 요청이 올 경우 빠르게 응답하기 위한 목적으로 사용할 수 있다. 이 경우 전체 데이터가 필요없고 데이터 역시 계속 유지될 필요가 없기에 Redis처럼 적은 공간의 데이터베이스에 최적이다.

Redis - REmote DIctionary System
여러 솔루션 중 하나로 메모리를 사용하는 키, 밸류 형식의 데이터베이스

-  DB 종류에는 RDBMS, NOSQL, IN-memory  방식이 있다.

1)  RDB
- 관계형 데이터베이스, 둘의 관계를 나타내줄 수 있는 무엇인가가 필요한다.
추가적으로 RDB에서는 근본적으로 null값을 허용하지 않음
- 해당 데이터의 모델의 정의가 확실해야 한다.
- 트랜젝션이라고 하는 처리 단위를 중요시 여김.
-데이터의 모델이 확실하고 하나하나의 처리가 확실해야 한다

2) NOSQL
데이터를 막 저장을 하자 다만 데이터의 고유성을 알아야 하니 키값만 만들어 두자

3) IN-MEMORY
하드 기반이 아닌 메모리 기반의 디비
- 말 그대로 데이터를 HDD가 아닌 memory에 저장하는 기술
- get, put을 이용하여 데이터를 넣고 뺄 수 있다.
인 메모리 기반의 디비는 key:value의 형태로 저장이 되지만 redis의 경우 value가 단순한 objet가 아닌 자료구조를 갖는 점에서 다른 인 메모리 기반의 디비와 큰 차이를 보입니다.
- 메모리는 휘발성 - 캐싱 서버로 사용하기 위해 나왔지만, 하드 저장이 가능해짐


대부분 Redis를 보조 데이터베이스 역할로 그 가치를 최대한 끌어내어 활용하고 있다. 그 중 Redis에 가장 적합한 것이 바로 데이터베이스 캐싱(Caching)이다.

Redis는 별도 서버로 구축되어 주서버와 지속적인 서비스를 주고 받는 방법이 효과적이다. 요즘은 하나에 모든 것을 관리 운영하기 보다 각각의 기능, 필요에 따른 마이크로 서비스(Micro Service) 형태로 많이 운영되어진다. 


Redis의 내부구조

영속성을 지원하는 인메모리 데이터 저장소다.
레디스는 고성능 키-값 저장소로서 문자열, 해시, 셋, 정렬된 셋 형식의 데이터를 지원하는 NoSQL이다
장점은 익히기 쉽고 직관적인 데 있고, 단점은 저장된 데이터를 가공하는 방법에 제한이 있다는 데 있다.


1) key/value Store
기본적으로 Key/Value Store이다. 특정 키 값에 값을 저장하는 구조로 되어 있고 기본적인 PUT/GET Operation을 지원한다.

2) 다양한 데이타 타입
Value가 단순한 Object가 아니라 자료구조를 갖는다고 앞서 언급하였다.  redis가 지원하는 데이타 형은 크게 아래와 같이 5가지가 있다.


** 각 타입의 명령어는 해당 링크를 통해 진입 가능 하다. 사용할때 참고할 것.

(1) String
일반적인 문자열로 최대 512mbyte 길이 까지 지원한다.
Text 문자열 뿐만 아니라 Integer와 같은 숫자나 JPEG같은 Binary File까지 저장할 수 있다.

(2) Set
set은 string의 집합이다. 여러개의 값을 하나의 Value 내에 넣을 수 있다고 생각하면 되며 블로그 포스트의 태깅(Tag)등에 사용될 수 있다.
재미있는 점은 set간의 연산을 지원하는데, 집합인 만큼 교집합, 합집합, 차이(Differences)를 매우 빠른 시간내에 추출가능하다

(3) Sorted Set
set 에 "score" 라는 필드가 추가된 데이타 형으로 score는 일종의 "가중치" 정도로 생각하면 된다.
sorted set에서 데이타는 오름 차순으로 내부 정렬되며, 정렬이 되어 있는 만큼 score 값 범위에 따른 쿼리(range query), top rank에 따른 query 등이 가능하다.

(4) Hashes
hash는 value내에 field/string value 쌍으로 이루어진 테이블을 저장하는 데이타 구조체이다.
RDBMS에서 PK 1개와 string 필드 하나로 이루어진 테이블이라고 이해하면 된다.

(5) List
list는 string들의 집합으로 저장되는 데이타 형태는 set과 유사하지만, 일종의 양방향 Linked List라고 생각하면 된다. List 앞과 뒤에서 PUSH/POP 연산을 이용해서 데이타를 넣거나 뺄 수 있고, 지정된 INDEX 값을 이용하여 지정된 위치에 데이타를 넣거나 뺄 수 있다. 

출처:



http://develop.sunshiny.co.kr/1001



반응형
반응형

Producer(생산자)가 Message를 Queue에 넣어두면, Consumer가 Message를 가져와 처리하는 방식입니다.

굳이 이런 시스템이 필요할까..? 한번 더 거치게 되면 더 느려지는게 아닌가? 라는 의문이 들 수 있습니다. 위에서도 언급한바 있지만 다시 한번 말씀드리자면, Client와 동기방식으로 많은 데이터 통신을 하게 되면 병목현상이 생기게되고, 서버의 성능이 저하됩니다. 이런 현상을 막고자하여 또 하나의 미들웨어에 메시지를 위임하여 순차적으로 처리를 하는 것 입니다.



일반적으로 메시징 시스템이나 RabbitMQ 에서 사용하는 컴퓨터 용어

Producing : 메시지를 전송한다는 의미
producer : 메시지들을 전송하는 프로그램을 producer 라 부릅니다. 
Queue: mailbox를 의미하며 RabbitMQ 시스템 내에 위치. consumer 대신에 RabbitMQ가 보관하는 메시지 버퍼
외부연동 서버에서 이 비동기 처리를 쉽게 구현하기 위하여 MQ(Message Queuing)를 사용한다.


AMQP

인스턴스가 데이터를 서로 교환할 때 사용하는 방법
MQ를 오픈 소스에 기반한 표준 프로토콜이 AMQP(Advanced Message Queuing Protocol)이다.
AMQP 자체가 프로토콜을 의미하기 때문에 이 프로토콜을 구현한 MQ제품들은 여러가지가 있으며 그 중 하나가 RabbitMQ이다.

AMQP의 구성요소와 라우팅 알고리즘

Exchange : Publisher(Producer)로부터 수신한 메시지를 큐에 분배하는 라우터의 역할
Queue : 메시지를 메모리나 디스크에 저장했다가 Consumer에게 메시지를 전달하는 역할
Binding : Exchange Queue의 관계를 정의

 Exchange Type 
 메시지를 어떠한 방법으로 라우팅할지 결정하는 일종의 알고리즘

1) Direct exchange
1:1 관계로 Unicast 방식에 적합, 운드 로빈 방식으로 여러 workers(Consumer) task를 분리
Exchange에 바인딩 된 Queue 중에서 메시지의 라우팅 키와 매핑되어 있는 Queue로 메시지를 전달한다

2) Fanout exchange
메시지의 라우팅 키를 무시하고 Exchange에 바인딩 된 모든 Queue에 메시지를 전달한다
1:N 관계로 메시지를 브로드캐스트하는 용도로 사용된다.

3) Topic exchange

Exchange에 바인딩 된 Queue 중에서 메시지의 라우팅 키가 패턴에 맞는 Queue에게 모두 메시지를 전달, Multicast 방식에 적합하다.


4) Headers exchange
라우팅 키 대신 메시지 헤더에 여러 속성들을 더해 속성들이 매칭되는 큐에 메시지를 전달한다.

RabbitMQ AMQP를 구현한 오픈 소스 메시지 브로커 소프트웨어로 Publisher(Producer)로부터 메시지를 받아 Consumer에게 라우트하는 것이 주된 역할이다이를 이용하면 작업 큐발행 및 구독라우팅주제원격 프로시저 호출 등의 모델을 구현할 수 있으며이 글에서는 작업 큐를 구현하는 방법을 다룬다.

RabbitMQ의  Exchange Type 

RabbitMQ AMQP를 구현하였기 때문에 아래의 표와 같이 Exchange Type이 미리 선언된 이름으로 정의되어 있다참고로 작업 큐는 Direct exchange가 적합하다

1) Direct exchange - (Empty string) and amq.direct
 참고) AMQP 정의 : 바인딩 된 Queue 중에서 메시지의 라우팅 키와 매핑되어 있는 Queue로 메시지를 전달(1:1)
2) Fanout exchange - amq.fanout
 참고) AMQP 정의 : 메시지의 라우팅 키를 무시하고 Exchange에 바인딩 된 모든 Queue에 메시지를 전달(1:N)
3) Topic exchange -amq.topic
 참고) AMQP 정의 : Exchange에 바인딩 된 Queue 중에서 메시지의 라우팅 키가 패턴에 맞는 Queue에게 모두 메시지를 전달(Multicast)
4) Headers exchange - amq.match (and amq.headers in RabbitMQ)
 참고) AMQP 정의 : 라우팅 키 대신 메시지 헤더에 여러 속성들을 더해 속성들이 매칭되는 큐에 메시지를 전달

https://www.evernote.com/shard/s479/sh/ddbec3f0-84fd-45c6-87d7-952a672341f1/ce289238f23c99a9b2e1a45b41c770a9
출처: http://itstory.tk/entry/Message-Queue-RabbitMQ란 [덕's IT Story]
출처: http://heowc.tistory.com/35 [허원철의 개발 블로그]
출처: https://m.blog.naver.com/tmondev/220419853534


반응형

'개발공부 > RabbitMq' 카테고리의 다른 글

RabbitMq(2)  (0) 2018.07.11

+ Recent posts