카프카 이론

ㅁ 개요/디자인/프로듀서와컨슈머/응용/운영가이드
*도구: yum 리눅스 패키지 관리자

*카프카 : 오픈소스 분산 이벤트 스트리밍 플랫폼
-분산
카프카가 실행중인 서버를 브로커.
브로커들은 하나의 클러스터를 구성.
동적으로 늘리거나 줄이는 것이 가능.

*메시징시스템 : 비동기 통신 프로토콜을 지닌 즉각적인 응답이 필요하지 않은 큐 시스템. AMQP프로토콜 사용.
- pub ,sub 모델: 메시지에 수신자가 정해져있지 않다. 구독을 신청한 수신자에게 전달. =>카프카가 사용하는 모델.

※카프카는 AMQP를 사용하지 않고 별도 프로토콜을 정의해서 사용. 신뢰성보다 < 처리량에 포커싱한 시스템

*주키퍼: 코디네이션 애플리케이션. 카프카의 데이터를 관리. 주키퍼 없으면 카프카 동작은 불가. 앙상블. 과반수방식
-분산시스템의 저장소(브로커, 토픽정보)
-리더(write), 팔로워(read); read는 로컬에서 처리하고 write는 리더가 처리
-주키퍼의 데이터저장: key-value형태로 저장. (컴퓨터:파일 = 주키퍼:지노드)

*오프셋<세그먼트<파티션<토픽<브로커<카프카 클러스터

*MQ는 컨슈머가 메시지를 꺼내가면 삭제됨/ 카프카는 컨슈머가 꺼내가도 일정시간**가지고 있음
 - **server.properties에서 log.retention.hours값으로 세팅

*카프카는 OS가 관리하는 페이지캐시를 이용해 굉장히 빠른 read/write를 한다. (메모리의 available에 있는 메모리를 사용)
-가능하면 카프카 별도 서버를 사용하는 것이 좋다

*카프카의 비효율성 해소 방법
- 잦은 청크발생 =>배치로 합쳐서 한번에 보낸다
- byte copying => 프로듀서, 컨슈머가 표준화된 형식  사용. 
  * kernel에서 applicaation context로 가지 않고(context switching없이) 바로 소켓버퍼에 보내는 명령어 : send file systemcall

*토픽: 카프카 클러스터내에서메시지를 전송 또는 가져오기위해 구분하는 단위. 메일주소같은 역할.
-249자 미만. prefix추천

*파티션: 토픽을 분할하여 병렬처리에서 성능을 높이기 위해 사용. 늘릴수는 있지만 줄일수는 없다. 0부터 오름차순. 
-토픽내의 파티션들은 서로 독립적. 파티션에 저장하는 방식은 append only, 저장된 데이터는 변경 불가능.(immutable)

*at most/ at lease(처리한 뒤에 다음읽을 메시지 번호값 저장. 유실없이처리)

*Replication : 토픽의 파티션 로그를 브로커들로 복제. 
모든 읽기쓰기는 리더가 담당. 복제 단위는 토픽이 아닌 파티션.
ISR로 묶여있고. 리더가 죽으면 팔로워중 하나가 리더로 선정됨.

*컨트롤러 : 리더선출하는 역할

*프로듀서 :파티션의 리더로 직접 메시지 전송. 배치크기 지연시간 설정 가능
- 카프카에 저장하는 메시지 형태는 다양(로그, 통신데이터, 데이터베이스..) 
- 프로듀서 레코드- 토픽, value : 필수 / 파티션, key: 선택
※key값을 해시해서 파티션에 넣음. 파티션수가 바뀌면 로직이 바뀔수있으므로 주의
- Ack옵션:0(빠르나 리더가 받았는지 알수 없음). 1(추천값.리더가받았는지 확인. 받고나서 Ack). ALL(느리지만 손실없음. 복제까지 하고 ack)


*컨테이너(도커)

*컨슈머 : 파티션의 리더에게 fetch요청하는 역할. 위치를 기록하고 있는 offset으로부터 메시지를 받아온다
-pull방식. 일시적인 컨슈머 멈춤도 가능.단점은 데이터가 없으면 무한루프..->를 방지하기 위해 poll 파라미터있음