kombu messaging library for Python
homepage: http://docs.kombu.me/en/latest/
kombu(다시마)?
홈페이지 들어가보면 파이썬 메시징 라이브러리이고
메시지 브로커를 쉽게 사용할 수 있는 솔류션이라 소개하고 있다.
특징
1. 다양한 메시지 브로커를 지원한다.
2. 자동으로 인코딩과 정규화를 해준다.
3. 메시지 전송 관련해서 예외처리가 잘되어 있다.
4. 커넥션이나 채널 오류가 있을때도 정상적으로 동작하게끔 구현되어 있다.
5. amqplib 사용에 불편했던 점들이 수정되었다.
6. 마지막으로 carrot 을 사용하고 있는 프로젝트는 쉽게 포팅할수 있다.
참고
rabbitmq 에서 Exchange 를 간단하게 설명한다면 메시지가
Queue 에 전송되기 전에 거쳐가는 라우터라 할 수 있다.
그리고 어떤 방식으로 메지시를 전달하냐에 따라서 type 이 나뉜다.
1. fanout
bind 된 모든 큐에 메시지를 전달
2. direct
routingkey 를 설정하여 같은 routingkey를 갖은 큐에만 선택적으로 메시지를 전달
3. topic
direct type 과 비슷하고 대신 routingkey 에 패턴을 설정 할수 있다.
패턴에는 *, # 를 사용하는데 * 는 모든단어, #은 공백을 포함한 모든단어이다.
단어의 구분은 . 으로 한다.
보통 topic 을 많이 쓰므로 이해를 돕기 위해 예를 추가한다.
news 라는 Exchange 의 bind 설정이다.
메시지의 라우터키가 political.news 로 들어오면 political_news 큐에만 전송된다.
메시지의 라우터키가 sience.news 로 들어오면 science_news 큐에만 전송된다.
메시지의 라우터키가 단어.news 패턴으로 들어면 즉 political.new, sience.news
가 해당 되므로 total_news 큐에는 political_news, science_news 큐에 전송된
메시지가 동일한게 전송된다.
4. header
헤더에 key 와 value 를 설정하여 선택적으로 메시지를 전달
Producer 테스트
Producer 에서 메시지를 publish 하는 순서는 아래와 같다.
Exchange 선언 -> Queue 선언 -> Producer 선언 -> publish 메시지 전달
publish 할때 declare 옵션에 따라 Exchange, Queue 의 존재여부를 확인하여
생성을하거나 에러를 발생할 수 있다.
rabbitmq 에 Exchange, Queue 가 있다면 그대로 사용이 된다.
코드
Consumer 테스트
exchange 생성 → queue 생성 → binding 정보업데이트
코드
기타
channel ?
하나의 물리적인 connection 안의 논리적인 connection
보통 비동기 작업을 할때 consumer(worker) 를 프로세스나 쓰레드 형태로 여러개를
생성하여 작업을 처리하는데 이때 각 프로세스나 쓰레드들이 물리적인 connection을
맺는다면 자원도 낭비되고 작업처리의 일관성도 떨어질것이다.
10개의 worker 중에 1개의 worker 에서 물리적 connection 이 끊어졌다면?
9개의 worker 는 열심히 일하고 있겠지만 1개는 계속 에러를 발생하고 있을것이다
물론 ack 옵션과 재연결 로직을 구현하면 어느정도 작업의 일관성은 유지 할수 있겠지만... 편리함과 리소스낭비 그리고 일관성을 생각한다면 한개의 물리적인 connection 으로 여러개의 worker 를 관리 할수있는 쪽이 보다 효율적일것이다.
그래서 나온것이 channel 인거 같다. 한개의 물리적인 connection 안에 논리적인
connection 을 만들어서 사용 할수 있게끔...
그냥 channel 에 대한 설명이 너무 난해 한거 같아서 생각해봤다.
channel 을 이용한 publish 테스트 코드