Question

我们一直在开发团队和环境支持团队之间就融合平台上的Kafka rest-proxy面临一些麻烦和不同的理解。

首先，我们拥有 5 Kafka经纪人的环境， 64个分区和复制因子3 。

我们对rest-proxy的调用现在都使用以下结构：

curl -X POST \
  http://somehost:8082/topics/test \
  -H 'content-type: application/vnd.kafka.avro.v1+json' \
  -d '{  
   "value_schema_id":1,   
   "records":[  
      { "foo":"bar" }]}'

此类通话适用于98.4％的通话，我注意到当我尝试拨打这个电话超过2k次时，我们没有从分区62收到任何OK响应（确切 1.6％< / strong>的分区）。当我们在支持团队回收模式注册表之前有7个分区返回错误时，此错误率曾经 10.9％。

现在，当呼叫转到分区62时，我们收到以下答案：

{ "offsets": [ { "partition": null, "offset": null, "error_code": 50003, "error": "This server is not the leader for that topic-partition." } ], "key_schema_id": null, "value_schema_id": 1 }

当我尝试将消息发送到特定分区添加＆＃34; / partitions / 62＆＃34;时，错误是相同的。到URL。

支持说rest-proxy不够智能（＆＃34;它只是一个代理＆＃34; ，他们说）选择一个有效的分区并将其发布给领导者该分区的经纪人。他们说它随机选择分区，然后随机选择经纪人发布它（这可以导致它发布到副本甚至没有分区的经纪人）。他们建议我们在发布消息之前更改我们的调用以获取主题元数据，然后通知分区和代理并在应用程序端处理循环分配，这对我没有意义。

在开发方面，我的理解是，rest-proxy使用apache kafka-client将消息发布给代理，因此足够聪明，可以将前导代理发布到给定分区，并且它还处理圆形 - 在未通知分区时，在kafka-client lib中执行robin。在我看来，这个问题就像是与该分区相关的环境问题而不是调用应用程序本身（因为它在具有相同配置的其他环境中没有问题）。

总结一下，我的问题是：

当我说rest-proxy足够智能处理分区循环并发布给领导者时，我是否正确？

应用程序是否应该处理问题1中的逻辑？（在这种情况下，我没有看到使用rest-proxy而不是kafka-client的原因）

对于您来说，它在环境编排中是否也会出现问题？

希望你能给我一些帮助，这一切都很清楚！

提前致谢！

Answer 1

我不使用rest-proxy，但此错误可能表示在调用期间发生了NotLeaderForPartitionException。此错误表示分区的领导者已更改，但生产者仍使用过时的元数据。当由于Kafka服务器中的内部错误而导致代理之间的复制失败时，会发生此错误。这可以在服务器日志中检查。

在我们的案例中，我使用./kafka-topics.sh --describe --zookeeper zookeeper_ip:2181 --topic test检查了主题，并显示代理中的一个副本不同步（ISR列）。重启这个经纪人帮助，复制品变得同步，错误消失了。

发送给Kafka REST-Proxy的消息被＆＃34拒绝;该服务器不是该主题分区的领导者＆＃34;错误

1 个答案: