자습노트

amqp producer - exchange - queue - consumer producer가 exchange에 보내는 것 : 퍼블리싱 exchange가 메시지를 queue 로 전달, consumer는 queue에서 빼서 메시지 사용 복잡한 어플에선 q와 컨슈머가 여럿임. 익스체인지는 선택 된 큐로 메시지들을 날림 익스체인지와 큐는 바인딩키를 통해서 바인드됨 프로듀서는 메시지를 보내기 위해서는 메시지와 같이 라우팅 키를 보냄 익스체인지는 바인딩키와 라우팅키를 보고 어떤 큐에 메시지를 던질지 결정 팬아웃이란 모든 큐에 메시지를 던지는 것 다이렉트는 바인딩키와 라우팅키가 동일한 큐에게 메시지를 던지는 것 토픽은 메시지와 바인딩키를 partially 비교하고 부분적으로 일치하는 큐에게 메시지 던 헤더는 라우팅 키 대신에 메시지 헤더를 사용하는 것 래빗엠큐엔 신기한 exchange가 있음. (디폴트(네임리스) 익스체인지) 이 익스체인지는 라우팅 키와 큐 이름을 비교함 (바인딩 키가 아니라) 라우팅키와 큐 이름이 같으면 메시지를 전달함 정리하면, 프로듀서는 익스체인지로 보낼 메시지를 방출하고 컨슈머는 큐로부터 메시지를 받고 바인딩은 익스체인지와 큐를 바인딩 키를 이용해 바인딩하는 것을 의미함 익스체인지는 라우팅키와 바인딩키를 이용해 비교 메시지 분배는 방식에 따라 다르게 동작 (팬아웃, 다이렉트, 토픽, 헤더, 특별한 놈은 네임리스)

정규화 정규화란  잉여 데이터의 최소화  하도록 정리하는 것 . (organizing the data into multiple related tables to minimize data redundancy) 1. data redundancy란? 의미없는 데이터들이 테이블에서 여러번 중복해서 많은 row에 있는 경우를 의미한다. 예를 들어 student 라는 테이블에 department 와 department_phone_number 라는 칼럼이 있다면 student의 row가 추가될 때마다 두 칼럼엔 아마 같은 데이터들이 계속해서 쌓일 것이다. 이는 DB의 용량을 차지하는 문제를 야기할 뿐더러 다른 문제들도 야기한다. 아래 3가지의 문제를 수반한다. 1) insertion anomaly - student를 추가할 때 마다 (별 필요도 없는) department 정보도 저장이 된다. 2) deletion anomaly - student를 지우면 department 정보도 날아가게 된다. - 만약 모든 student를 지우면? 모든 department도 날아가게 되는 것이다! 3) update anomaly - 만약 department가 새로운 이름으로 개명했다면? 모든 row의 department를 바꿔줘야 한다. 하지만 정규화란, eliminating data redundancy가 아니다. minimizing redundancy다. 만약 department_phone_number 칼럼은 존재하지 않고 department만 존재한다면? 여전히 department 정보가 필요없다고 날려버릴 것인가? 안 된 다 이 때는 department 칼럼을 제거할 수 없다. 왜냐면 이 때 department는 외래키 역할을 하며 다른 정보를 불러오는데 필수인 다리 역할도 할 것이기 때문이다. 보시다시피, 이 때는 department라는 칼럼은 redundant하지만 그렇다고 eliminate할 수 ...

ROA(Resource Oriented Architecture), REST(Representational State Transfer) REST는 ROA를 위한 패턴? 스타일이라고 할 수 있다. RESTful하다는 것은 여러 의미를 가진다 (URI가 자원자체를 표현하는 등등) RESTful하다는 것의 특징엔 Stateless하다는 것이 포함된다. REST(상태를 이전시키는) -> (상태를 이전시킨다는 것은 즉 늘상 Holding하고 있는 상태가 딱히 없다는 것) -> 고로 RESTful하다는 것은 stateless하다는 것으로 이어진다. stateless한 상태는 scalability와 trade-off가 있다. stateless할수록 scalability는 올라간다. (제약이 없으니 확장과 스케일링에 대한 이점을 얻는 것) 반면에 stateful은 스케일링을 할 경우 passive, active 경우에 따라 나눠줘야 한다는 단점이 있다.

1. RPC   보통의 procedure call 은 caller->callee->caller 흐름으로 compile time에 진행된다. 하지만 RPC는 Caller가 호출하는 사항(아규먼트, call trap등)을 Kernal에 두고, 서버는 실행할 때 커널에 있는 스택을 참조해서 실행한다.  Kernal엔 각각 call trap, return trap이 있는데 client가 호출하는 call stack은 call trap에, 서버가 반환하는 결과값은 return trap에 저장되고 커널은 여기에 저장 된 정보들을 복사해서 양쪽으로 중개해주는 것이다.  프로시져콜은 모두 컴파일타임에 실행이 되지만 RPC는 '런타임중에' 호출이 되면 실행하기 때문에 성능면에서 좋다.  이 흐름에서 kernal이 하는 역할을 보자면 1) Caller의 호출을 validate한다. 권한은 있는지, call을 잘 보낸건지.. 2) caller의 스택(아규먼트들)을 kernal의 calltrap으로 복사한다. 3) Server로 컨텍스트를 바꾸고 일을 처리하고.  2. SOAP  - 어플리케이션들의 커뮤니케이션 프로토콜이다. - XML 기반으로 메시지 송수신 프로토콜이며, 플랫폼/언어등에 독립적이다. - Envelope, Header, Body, Fault 로 구성된 XML이다. - 서버 서버간의 통신에는 데이터 정합성이 중요하기 때문에 REST방식 보다는 무겁더라도 SOAP로 통신하는게 좋은 경우도 있다. 장점 - XML이기 때문에 extensible하다 - 다양한 프로토콜에서 사용할 수 있다 (HTTP뿐만 아니라 SMTP FTP등등) 단점 - 늘 SOAP 방식의 스키마를 쓰도록 강요한다. 어떤 스키마가 있다는 것은 형식이 일정하다는 장점도 있지만 스키마 때문에 익히거나 채택하기 어려운 경우도 있다. - XML이기 때문에 파싱하는데 꽤 오래 걸려서 네...