"파란색을 클릭 세계의 눈 케어 제품 "우려 나에게 요
깊이 값 시스템 전송
카프카의 메시지가 저장되거나 디스크에 캐시, 일반적으로 더 많은 시간이 소요 있지만, 사실은, 카프카의 특징 중 하나는 높은 처리량이 될 것입니다 해결하기 때문에 디스크의 읽기 및 쓰기 데이터가 성능이 저하됩니다 것으로 생각된다.
심지어 일반 서버, 카프카 쉽게 메시징 미들웨어의 대부분보다, 두 번째 레벨 당 쓰기 요청의 수백만 지원할 수있는이 기능은 카프카가 널리 장면으로 엄청난 양의 데이터를 처리하는 로그에 사용한다.
카프카의 경우 벤치 마크를 참조 할 수 있습니다 :
아파치 카프카 벤치 마크 : 초당 쓰기 200 만 (세 저가의 컴퓨터에서)
ifeve.com/benchmarking-apache-kafka-2-million-writes-second-three-cheap-machines/
왜 카프카 너무 빨리 쓰기와 읽기 모두의 분석에서 다음과 같은 데이터.
데이터 쓰기
카프카는 잃게 데이터하지 않습니다, 하드 디스크에 기록 된 메시지가 나타납니다. 쓰기 속도를 최적화하기 위해 카프카는 두 가지 기술, 순차 쓰기 및 MMFile를 사용합니다.
순차 쓰기
디스크 읽기 및 쓰기 속도는 연속 읽기 및 쓰기 또는 임의 읽기 및 쓰기입니다, 사용 방법에 따라 달라집니다. 순차 읽기 및 쓰기의 경우, 읽기 및 쓰기 속도 최적화 시나리오가 일부 메모리 디스크가 평평 할 수 있으며,
참고 : 질문이 여기가 아닌 정제 된 세부 사항 참조있다
http://searene.me/2017/07/09/Why-is-Kafka-so-fast/
주소가 "기계적 작용"이 소모 대부분의 시간 인 것을 특징> 쓰기 - 하드 디스크가 기계 구조이기 때문에, 각각의 읽기 및 쓰기 주소입니다.
하드 디스크는 대부분의 순차적 I / O를 같은 랜덤 I / O를 싫어 그래서 읽고 하드 디스크의 쓰기 속도를 개선하기 위해, 카프카는 순차적 I / O를 사용하는 것입니다
리눅스와 최적화 디스크에 대해 미리 읽기 및 쓰기 뒤, 디스크 캐싱을 포함하여, 읽기 및 쓰기는 더 될 것입니다.
시간이 메모리, 좋은 메모리 오버 헤드 자바 객체에서 이러한 작업을 수행하는 경우, 다른 하나는 데이터의 증가에 힙 메모리이다가, GC의 자바는 매우 오랜 시간이 될, 디스크 작업이 다음과 같은 이점이 있습니다 사용 :
순차 읽기 및 쓰기 디스크는 랜덤 액세스 메모리를 초과
낮은 효율, 큰 메모리 용량의 JVM GC. 사용 디스크는이 문제를 방지
콜드 스타트 시스템 후, 디스크 캐시는 계속 사용할 수 있습니다
카프카 방법을 실제로 각 파티션 문서에 기록 데이터로 메시지 데이터를 수신 한 후도에 도시 한 카프카 파일의 끝 (허부 블록)에 삽입된다.
이 방법은 단점이있다 - 삭제 데이터에 대한 방법이 없습니다, 카프카는 삭제 된 데이터는, 모든 데이터가 유지됩니다, 사용되는 오프셋 한 각 주제에 대한 각 소비자 (소비자)을 표시하지 않습니다 처음 몇 데이터를 읽습니다.
두 소비자 Consumer1 두 (토픽 파티션 각 가정) partition0을, 대응 개의 파티션 오프셋 Consumer2가 Partition2에 대응하는 오프셋.
이것은 클라이언트 SDK를 유지할 책임이 오프셋, 카프카의 Broker는 완전히이 일을 무시하고, 정상적인 상황은 사육사의 내부에 저장됩니다 SDK에서. (소비자에 주소 사육사를 제공 할 필요가있다).
제거하지 않으면 Kakfa 데이터를 삭제하는 두 가지 전략을 제공하므로 하드 디스크는 확실히 전체 될 것입니다. 하나는 시간을 기준으로, 두 번째는 파티션의 파일 크기를 기반으로합니다. 구체적인 구성은 구성 파일에서 찾을 수 있습니다.
메모리 매핑 된 파일
순서가 하드 디스크 액세스 속도에 기록 된 경우에도 여전히 캐치 메모리 불가능하다. 카프카는 데이터가 디스크에 기록되는 실시간되지 않도록, 그것은 메모리 I / O 효율의 사용을 증가시키기 위해 최신 운영 체제 페이징 메모리를 최대한 활용합니다.
파일 (나중에 mmap를라고도 함) 매핑 된 메모리도로 번역되어 메모리 매핑 된 파일 , 64 비트 운영 체제는 일반적으로 데이터 파일 20G를 나타낼 수 있습니다, 그 작동 원리는 페이지가 물리적 메모리에 파일을 직접 매핑을 달성 운영 체제의 직접 사용은 .
당신은 실제 메모리의 매핑 작업이 하드 드라이브에 동기화됩니다 완료하면 (적절한 경우 운영 체제).
mmap에 의해, 읽기, 읽기 - 쓰기 메모리 (물론, 가상 머신 메모리)와 같은 하드로 작성하는 과정은, 우리가 모든 세부 사항을 공개하기위한 가상 메모리의 메모리 크기에 대해 걱정할 필요가 없습니다.
당신은 내가 많이 얻을 수있는이 방법 / O 업그레이드, 복사에 커널 공간에 사용자 공간의 오버 헤드를 제거 (읽기 데이터는 커널 메모리 공간에 첫 번째 파일을 호출 한 다음 사용자 메모리 공간에 복사합니다 인치 )
명백한 결함도 있습니다 - 프로그램이 자동으로 만 호출 데이터를 플러시 할 때 mmap를 작성 신뢰할 수없는 데이터는 정말 하드 디스크에 기록되지 않은 운영 체제가 하드 리얼 씁니다.
; 카프카 카프카 생산자라는 동기화 (싱크)에 반환하기 전에 mmap를 즉시 다량 후에 기록하는 경우 컨트롤 파라미터는, 활성 --producer.type 플러시 아니다 제공 창을 즉시 mmap를 생산자 비동기 호출을 작성 후 (플러시를 호출하지 않는다 비동기).
데이터 읽기
디스크를 읽을 때 카프카는 어떤 최적화를 했습니까?
제로 복사를 달성 sendfile을 바탕으로
파일이 전송 될 필요가 전통적인 모드는 특정 프로세스 세부 사항은 다음과 같습니다 :
읽기 함수를 호출, 파일 데이터는 커널 버퍼를 복사하는 것입니다
사용자 버퍼를 커널 버퍼에서 함수가 반환, 파일 복사 데이터를 읽고
쓰기 함수 호출은에 대한 사용자 버퍼에서 파일 복사 데이터는 소켓과 관련 된 버퍼 커널.
관련 프로토콜 엔진에 소켓 버퍼에서 데이터를 복사합니다.
자세한 내용은 네트워크 파일 전송에 대한 읽기 / 쓰기 모드의 전통적인 방법입니다, 우리는이 과정에서 것을 볼 수 있으며, 데이터 파일은 4 개 개의 동작을 통해 사본은 실제로 :
하드 드라이브 -> 커널 buf-> 사용자 buf-> 소켓 버퍼 관련 -> 프로토콜 엔진
에 sendfile 시스템 호출은 위의 반복, 복사 파일 전송 방법의 성능을 향상 줄이는 방법을 제공한다.
버전 2.1 커널은 sendfile을 시스템 호출은 네트워크와 두 로컬 파일 사이의 데이터 전송을 단순화하기 위해 도입된다. sendfile을 또한 컨텍스트 스위칭을 줄뿐만 아니라, 데이터의 복제를 감소 도입.
sendfile(socket, file, len);
다음과 같이 실행 프로세스는 다음과 같습니다
sendfile을 시스템 호출, 파일 데이터는 커널 버퍼를 복사하는 것입니다
그리고 커널 버퍼 사본에서 커널 소켓 버퍼 관련
마지막으로 관련 프로토콜 엔진에 사본을 버퍼 소켓
기존의 읽기 / 쓰기 모드에 비해 커널 sendfile을 커널 버퍼의 2.1 버전의 도입은 소켓 버퍼에 관련 파일을 복사하기 위해 사용자, 사용자 버퍼에 다음 버퍼를 감소되었다
그리고 커널 버전 2.4 이후, 파일 기술자 결과는 sendfile을 다시 한 번 복사 작업을 줄이고, 좀 더 간단한 방법을 달성하기 위해 변경됩니다.
아파치, nginx를, lighttpd를 웹 서버 등 중에서, sendfile을 관련 구성을 가지고 사용 sendfile을 크게 파일 전송 성능을 향상시킬 수 있습니다.
소비자 요구, 읽기 - 쓰기 모드 mmap에있는 파일로, 소비자에게 직접 카프카 파일을 데이터를 전송 직접 sendfile을 전달할 때 카프카 모든 메시지가하는 파일에 저장됩니다.
일괄 압축
대부분의 경우, 병목 현상이 CPU 나 디스크가 아니라 네트워크 IO, 데이터 센터 사이의 전송 메시지에 특히 필요가 데이터 라인을 WAN.
데이터 압축은 CPU 자원의 작은 금액을 소비하지만, 카프카를 들어, 네트워크 IO가 고려되어야한다.
각 메시지는 압축되지만 카프카 배치 압축을 사용하므로 압축률이 상대적으로 낮은 경우, 압축은 단일 메시지 압축보다는 함께 여러 메시지 오는
카프카 소비자가 해결 될 때까지 압축되고, 메시지 세트 재귀 메시지 볼륨이 로그에 의해 압축 된 형태로 전송 될 수 있으며, 압축 된 포맷으로 유지 될 수 있도록
카프카는 Gzip 압축 프로토콜과 뭐 이따위 등 다양한 압축 프로토콜을 지원합니다
개요
모든 배치 파일에 메시지 및 합리적인 대량의 압축 적 mmap을 개선하여, 네트워크 IO 손실을 줄일 수 있다는 카프카 속도의 비밀 I / O 속도, 쓰기 데이터 인해 하나의 partion을에 마지막에 추가 될 때 따라서, 최적의 속도, 폭력 때 sendfile을 직접 출력 데이터를 판독한다.
저자 : 빙 더
공원 블로그 글 주소 :
cnblogs.com/binyue/p/10308754.html
