카프카 session.timeout.ms heartbeat.interval.ms 매개 변수뿐만 아니라 데이터 저장에 대한 몇 가지 생각의 차이

종종 우리는 컴퓨터 세계의 데이터를 처리해야하고, 이것은 우리가 CURD 엔지니어 농담 이유 중 하나입니다. 2 년 동안의 코드를 작성, 스토리지 시스템의 많은 접촉, 레디 스는, MySQL은, 카프카, Elasticsearch은 ... 일부는 이러한 시스템 뒤에 숨겨진 찾을 수 있습니다, 천천히 항상 익숙한 뒤에 몇 가지 일반적인 디자인 철학을 찾은 다음 바닥에 도착 수학적 이론.

삶에서 발생하는 많은 양의 데이터는 컴퓨터 처리, 다른 치료의 응용 프로그램에 따라 두 가지 범주로 나누어 OLTP와 OLAP에 인도 될 필요가있다. 이러한 메시징 미들웨어 (카프카)를 수집 던져진 로그인 절차, 시스템 로그 정보를 일정 같은 일부 데이터 일부 데이터와 같은 사용자 기록 특성에 대한 설명으로서, 인덱스를 작성하는 일에 의해, MySQL을 저장하기에 적합하다. 즉 : 많은 양의 데이터의 얼굴, 데이터는 단지 작은 단계를 저장, 함께 이러한 데이터가 얼마나 중요 편리한 있는가 : 스토리지 시스템이 반영 쿼리 쉽고 빠르게 발견 할 수있는 인터페이스 우리는 데이터를합니다. 데이터가 카프카에 있으면, 그것은 조사 방법에 달려있다? MySQL의상의 데이터 경우 이상적 TF-IDF에있어서, 상기 ES, 데이터 구조에 기초하여 상기 역 색인 배치 높은 카디널리티 칼럼 B + 트리 인덱스 질의 구조 및 텍스트 데이터 유형에 적합한, BM25 등 문서 유사성 알고리즘의 계수 빠르게 원하는 데이터를 얻었다.

이것에서 당신은 그들 뒤에 "쿼리"저장 원칙 (고용 데이터 구조) 다른를 충족하기 위해, 서로 다른 스토리지 시스템을 볼 수 있습니다. 높은 신뢰성과 고 가용성 : 그리고 이러한 스토리지 시스템에 대한 두 가지 문제에 직면하고 있습니다. 신뢰성, 내 의견으로는, 신뢰할 수있는 데이터를 확인하는 방법을 논의하기 위해 스토리지 시스템 자체, 일반적으로 단일 인스턴스에 서있다. 예를 들어, MySQL의 인스턴스가 이중 쓰기 버퍼뿐만 아니라, 내구성을 보장하기 위해 리두 로그 파일을 통해 체크 포인트 메커니즘을 따라 실행, 데이터 페이지가 신뢰할 수 있도록 작성됩니다. 마찬가지로, 데이터의 신뢰성을 확보하는 데에도 Elasticsearch TRANSLOG기구가있다. 그래서, 나는 그들 사이에 다양한 체크 포인트 메커니즘을 비교하실 수 있습니다, 더 많은 스토리지 시스템을 배우고 싶다.

왜 신뢰성 데이터가 필요했다? 근본 원인 메모리는 폰 노이만 아키텍처 긴급에 따르면, 휘발성 메모리이며, 작업을 할 수있는 CPU에 메모리에서 데이터를 가져옵니다 프로그램. 데이터가 손실되지 않을 경우 데이터가 디스크, 시스템 다운 타임에 fsync를하지 않을 경우?

클라이언트의 관점에서 가용성하십시오. 나는 당신이 레디 스의 레디 스 인스턴스 또는 클러스터 뒤에 상관 없어, 당신은 일반적으로 단지 나에게 잘 좋은 독자 서비스를 제공합니다. 여기에 SPOF를 방지하기 위해, 분산 된 클러스터가 편리, 기계는 상단에, 또 다른 기계를 끊었어요. 분산 시스템에서 각 스토리지 인스턴스를 관리 할 필요가, 캐릭터는 우리는 콜 마스터 노드 컨트롤러 노드 등의 노드를 분할 할 필요가있다. 결국, 관리가 잘, 우리 역할이 동일한 수준을 가지고있다, 어떻게 관리 하는가? 이 시점에서, 레디 스 클러스터 또는 클러스터와 카프카 Elasticsearch 클러스터는 주 Elasticsearch와 카프카 모델에서 채택하면서, 본질적으로 P2P 구조 인 레디 스 클러스터에 구현 된 매우 다른, 왜 말합니까? 레디 스 노드 포인트 마스터 및 슬레이브 노드하지만, 각각의 마스터 노드 사이의 평등, 데이터가 각 마스터 노드 방식 레디 스의 hash16384 슬롯 분산이 있지만, 각각의 마스터 노드는 탱크 폭포를 처리하기위한 책임이있다 에서있는 데이터, 분산 데이터 마스터 노드 각도가 정의되고 카프카의 컨트롤러 노드는 마스터 노드는 데이터의 분포의 측면에서 정의되지 않은 elasticsearch하지만, 클러스터 관리의 정의의 관점에서 클러스터 메타 정보를 보존 할 수 있습니다. 내에서 그들 사이의 구체적인 차이에 대한 기사 도 몇 가지 설명을했다. 또한, MySQL은 관계형 데이터베이스로, 주제 분산 클러스터 약한 능력에 대한 데이터 무결성 제약, 트랜잭션 지원 제한.

최근에 나는 카프카 주제, 일부 대기업, 중소 기업 뉴스 어느 정도의 소비에 메시지를 보내 문제가 더 많은 서비스를 가로 질러왔다. 뉴스 카프카는 물론 일부 비즈니스 지출 문제의 지연의 결과로, 소비자에게 우선 순위의 메시지가 지원되지 않았기 때문에. 간단한 해결책은 레거시 시스템이 가져 주제 소비자 프로세싱 로직 복잡도의 생산 증가, 몇 가지 문제에 직면 여러 항목에 추가하는 것이다. 한 가지 방법은 사용하는, 카프카 독립 소비자를 사용하는 것입니다 consumer.partitionFor("TOPIC_NAME")후 사용 주제 아래에있는 모든 파티션 정보를 consumer.assign(partitions)명시 적으로 지정 소비 파티션 소비자를. 또 다른 방법은 파티션 할당 전략 소비자 그룹 사용자 정의 카프카 소비자에 따라,이 시간 당신은 카프카의 이해가 이미 파티션 할당 전략을 기존의, 그리고 한, 무슨 장면 시간의 균형을 트리거 무엇인지 이해한다?

카프카 소비자는 소비자 뉴스 소비자 파티션이 할 수있는 메시지를 소비하는? 범위, 라운드 로빈, 끈적 :이 세 가지가 기본적으로 소비자의 파티션 할당 정책이다. 라운드 로빈 알고리즘의 말하기, 정말 모든 곳에서, 종종 어떤 장면에서 사용되는 부하 분산이 필요합니다. 각 노드는 ES 코디네이터 노드로 사용할 수 있기 때문에 이러한 Elasticsearch 클라이언트, ES 서버에 검색 요청을 보낼 때 기본적으로 사용자 쿼리 요청을 수신하고, 코디네이터 노드에서 쿼리 결과를 많이 소비하는 모든 조각을 요약 필요 메모리와 CPU는 ES 클라이언트는 라운드 로빈 선택 알고리즘은 ES하는 노드에 질의를 보낸다. 주의 깊게 보면, 내부 레디 스에서 알고리즘의 그림자가있을 것입니다 찾을 수 있습니다. 다른 예 : 기능의 일부와 키 액세스 빈도가 다른 키보다 훨씬 더 큰, 예컨대 액세스 특성으로서 : 액세스 패턴 레디 스 LRU 캐시 키는 일반적으로 전력 분배 수단 (지수 법칙 분포) 이하 , LRU 캐시는 좋은 결과를 달성했다. 또한, 레디 스 소트 설정 유형 skiplist 새로운 skipNode 노드에 기초가 속하는 층 그것? 이것은 또한 지수 법칙 분배 문제, 소스 코드 주석입니다 :

우리가 만들어가는 새로운 skiplist 노드에 대한 임의의 레벨을 돌려줍니다. 이 함수의 리턴 값은 높은 레벨이 리턴되기 어렵게된다 powerlaw 흡사 분포 1과 ZSKIPLIST_MAXLEVEL (모두 포함) 사이에있다.

사실, 나는 몇 가지 아이디어를 표현하고자하는 또는 더 나은 시스템 뒤에 원리를 이해하기 위해서는이 둘을 비교합니다, 다양한 다른 스토리지 시스템에서 사용, 다목적, 솔루션입니다.

때마다 최근에 몇 가지 메모를 작성, 내 마음의 생각의 다른 종류의 일부는 항상 존재합니다. 이는 주로이 두 가지 구성 매개 변수를 쓰기 카프카 싶어했을 : 처음에 session.timeout.ms 결과의 heartbeat.interval.ms의 차이는 데이터 저장과 관련된 패스 무언가를 당깁니다.

계속하자 :

주제는 종종 여러 개의 파티션이 있고, 우리는 더 많은 소비 지출을, 따라서 소비자 그룹에서이 주제를 만들 것이기 때문에 : 질문이있다 : 여기에 메시지를 분할 소비자 소비를? 소비자 그룹, 소비자, 소비자 그룹 내부의 소비자 그룹, 각 그룹 코디네이터 :이 세 가지 개념을 포함한다. 그룹 관리 프로토콜에 의해 할당 된 conusmer 파티션이 구현은 다음과 같습니다 :

그룹 코디네이터되어 joinGroup 요청에 전송되는 각 소비자 소비자 그룹은 모든 소비자 정보의이 그룹 코디네이터의 멤버가있을 것입니다, 그래서 소비자와 리더 소비자를 선택하는 것입니다, 그리고 리더 소비자가 말했다 말 : 당신은 정보와 그 구성원을 나는 당신에게 그것을 분할 소비자의 소비에 대한 책임 파티션 정보를 배열하는 주제를주지

다음에, (파라미터에 의해 지정된 partition.assignment.strategy) 우리의 구성, 각 파티션을 계산하는데있어서 소비자 리더 할당 전략은 각 사용자에 대한 소비한다. 따라서, 각 소비자 그룹 코디네이터 SyncGroup는 요청을 보내고 있지만 소비자는 파티션 그룹 코디네이터 리더 소비자의 수령 후, 리더 파티션 할당 정책을 요청하고이 계획에 소비자에게 배포했다. 지도 그리기, 이는 다음과 같다 :

정상적인 상황에서, 소비자 그룹 중 소비자가 재조정을 트리거 할 때,이 파티션의 생각을 다시 수립하기 위해 호출된다 균형. 그리고 파티션의 좋은 아이디어를 개발, 다음을 수행해야합니다 즉시 매개 변수 및 heartbeat.interval.ms에 관련된 각 소비자를 알려줍니다. 구체적으로는 다음과 각 사용자는 주기적으로 시간 파라미터에 따라 송신한다 heartbeat.interval.ms는 재조정이 발생하면 그룹 코디네이터 hearbeat 그룹 코디네이터가 각 소비자 응답 각 소비자 응답 수신한다 포함 지정 REBALANCE_IN_PROGRESS 정체성, 각 소비자는 이미 그룹 코디네이터가 각 소비자의 알 동안, 균형 일어난 알 수 있도록 생존을 .

왜 heartbeat.interval.ms 및 session.timeout.ms는 비교해야합니까? session.timeout.ms 의미 : 소비자 충돌에 필요한 그룹 코디네이터 검출 시간이 발생합니다. 소비자 그룹은 두 번째, 소비자 안에 걸어 감지 session.timeout.ms을 차지합니다. 예를 들어, = 10, = 3 heartbeat.interval.ms session.timeout.ms

session.timeout.ms이 임계 값을 지정하는 "논리"인덱스이다 ---이 임계 조정자 내의 10초 어떤 메시지가 수신되지 않은 경우, 소비자가 소비자 간주 코디네이터 끊었다. heartbeat.interval.ms가 코디네이터로 하트 비트 패킷을 전송하기 위해 소비자에게 3 초마다 알려주는 "실제"표시이다, 작은 heartbeat.interval.ms는 경향 하트 비트 패킷, 그것은 전송 TCP 패킷의 수에 영향을 미칠 것 그리고 그것은 한 실제적인 영향을 내가 불리는 이유입니다, 은 "실제" 지표 이유.

기간의 heartbeat.interval.ms 소비자 내의 그룹 코디네이터가 하트 비트를 수신하지 않는 경우, 그룹은 소비자의 넣어, 그것은 정당화. 소비자가 만든 것처럼 막대기에 작은 실수를 죽였다. 사실, 네트워크 지연 할 수 있고, 이것은 하트 비트 패킷이 정상으로, 아마도 다음 응답 도착 영향 장시간 소비자 GC가 발생할 수있다.

에 소비자 그룹이 균형 발생한 경우 heartbeat.interval.ms 확실히 REBALANCE_IN_PROGRESS 내부 하트 비트 패킷에 의해, session.timeout.ms 미만, 소비자는 수있을 것입니다 적시에 알고함으로써 소비자 소모품 파티션을 업데이트 균형 일어났다. session.timeout.ms보다 더 많은 경우, 그룹 코디네이터는 소비자가 걸려 있음을, 즉 재조정 소비자에게 정보를 말하지 확실히 믿습니다.

원본 : https://www.cnblogs.com/hapjin/p/10926882.html

최근 특정 ES 분석기 플러그인 기호 검색을 충족하기 위해 맞춤형 중국어 단어 (사용자 지정 단어를 생성하는 단어)의 결과의 일부 정상화, 단어 정확도를 만나 중국 산업의 용어 문제가를 작성하는 시간이 필요 검색 ... .