2017-09-14 6 views
0

Confluent Rest proxy을 모든 사용자 이벤트를 수신하기위한 플랫폼 계층으로 사용하려고합니다 (&). 다양한 유형의 이벤트 생성기가있는 마이크로 서비스 모델 &에서 작업하면서 API/이벤트 생성기를 이벤트 수신/처리에서 분리해야합니다. 또한 이벤트 리스닝 레이어에서는 이벤트 의 탄력성이 중요합니다.Confluent Rest Proxy API (제작자) 재시도 이벤트가 실패시 게시

  1. 내가 알기로, Rest Proxy 계층이 어떤 이유로 Kafka에 게시하지 못하면 다시 시도하지 않습니다. 이 기능은 호출자 (클라이언트 계층)가 처리해야하며, 동기 호출 &이 실패하면 다시 시도해야합니다. 그러나 제품 설명서에서 이에 대한 세부 정보를 찾을 수 없습니다. 누군가가 같은 것을 확인해 주시겠습니까?
  2. Confluent Rest 프록시 개발자는 적절한 Rest Proxy 클러스터 설정을 사용하여 클라이언트가 올바른 일괄 처리를 수행하도록 설정 했으므로 기본 제작자만큼 우수한 성능을 얻을 수 있다고 주장합니다. 어떤 예외/(긍정적/부정적인) 생각이 여기 있습니까?
  3. 나머지 프록시 프로듀서 API에 대한 호출이 차단됩니다. 클라이언트가 오프셋 & 오프셋 정보를 알아야 할 필요가 없으면 이러한 호출을 비 블로킹으로 구성하여 요청을 받으면 휴식 프록시 계층 자체에서 복원력을 관리 할 수 ​​있습니다. 클라이언트는 메시지 생성 요청이 수신 될 때마다 확인 메시지로 200 HTTP 상태를 수신합니다.

답변

0
  1. 는 REST 프록시는 보통의 카프카 프로듀서와 카프카 소비자이며 다른 모든 카프카 생산자 할 수있는, 또는 활성화 시도없이 구성 할 수 있습니다.
  2. REST 프록시를 통해 게시하는 단일 제작자는 단일 원시 Java Producer와 동일한 처리량을 얻지 못합니다. 그러나 많은 REST 프록시와 많은 HTTP 프로듀서를 확장하여 전체적으로 높은 성능을 얻을 수 있습니다. 또한 여러 메시지를 통합 HTTP 요청으로 일괄 처리하여 HTTP에서 발생하는 성능 저하를 완화하여 전 송에서 HTTP 왕복 횟수를 최소화 할 수 있습니다.