개인프로젝트 7일차

강한결합하면 안되는 이유!!

강한결합을 사용하게 되면 A가 에러가 나면 B가 영향을 받기 때문에

즉!! 느슨한 결합을 이용해야한다.

 

느슨한 결합을 하기위해 middleware가 필요하다!!

(* 큰 -> 작은)

MOM(Message Oriented Middleware -> MessageQueue -> kafka,RqbbitMQ

Kafka는 대용량 처리에 특화되어있고, 데이터가 날아가지 않은 비휘발성

RqbbitMQ는 각각의 메시지별 로 다르게 처리 라우팅키가 있어서 어떤 서버에 어떤 메시지를 보낼건지 결정할수있다.

 

linkedin 에서 kafka를 만듬

 

Kafka는 offset별로 메시지를 구분할수있음

 

Message Queue를 사용하는 이유(장점)

 

1. Asynchronous 비동기

2. Decoupling 결합도 낮춤

3. Scaleability 큐사이즈의 scale up down

 

종류

point to point

pub/sub

 

RqbbitMQ

publisher -> publish -> exchange -> routes -> queue -> consumer

 

kafka 파티션 간에는 순서가 보장이 안되지만 파트션 내부에선 queue로 구성되어있기때문에 순서가 보장됨

 

한 topic에 patition 에 대수가 있을수도있고 한개가 있을수도있음.

 

카프카의 구조

https://engkimbs.tistory.com/691

 

카프카의 권장사항

broker안에 topic과 patition들이 잇다 그러므로 broker 하나가 죽어버리면 안에있는 topic과 partition들이 죽으므로

3개이상의 broker들을 사용해서 topic과 partition들을 만들자!!

 

Leader 브로커에있는 Partition에게만 read와 write를 하고 Follew가있는 브로커에 patition에는 replicate한다.

replicate하는 이유는 서버가 장애가 있을때 Leader partition을 넘겨줘야함.

 

controller는 broker들의 장애를 감지, 리더 지휘 넘겨줌

cordinator는 consummer의 장애를 감지하고 장애감지한 consummer를 제외한 다른 consummber에 넘김.

 

ack 0인경우

producer -> leader partition에 전송 후 응답값 받지 않음

 

ack 1인경우

producer -> leader partition에 전송 후 Leader partition의응답 받음

 

ack all인경우

producer -> leader partition에 전송 후 Replication 정상 응답까지 기다림

 

Disk I/O

Page Cache를 통하여 성능 개선

데이터 전송을 배치 처리

 

zookeeper 카프카의 매타데이터들을 관리해줌