Apache kafka 如何最小化kafka消息传递框架中涉及的延迟？
场景：我有一个小容量的主题（~150msgs/秒），我们希望有一个 从生产者到消费者的低传播延迟 我添加了一个来自生产者的时间戳，并在消费者处读取它以记录传播延迟，在默认配置下，msg（20字节）显示了1960ms到1230ms的传播延迟。不涉及网络延迟，因为我在同一台机器上尝试了1个生产者和1个简单消费者 当我尝试将主题刷新间隔调整为20ms时，它会下降 到1100ms到980ms。然后我试着将consumersApache kafka 如何最小化kafka消息传递框架中涉及的延迟？,apache-kafka,Apache Kafka,场景：我有一个小容量的主题（~150msgs/秒），我们希望有一个 从生产者到消费者的低传播延迟 我添加了一个来自生产者的时间戳，并在消费者处读取它以记录传播延迟，在默认配置下，msg（20字节）显示了1960ms到1230ms的传播延迟。不涉及网络延迟，因为我在同一台机器上尝试了1个生产者和1个简单消费者 当我尝试将主题刷新间隔调整为20ms时，它会下降 到1100ms到980ms。然后我试着将consumers“fetcher.backoff.ms”调整到10ms，它下降到1070ms-86
“fetcher.backoff.ms”更新： 尝试调整日志刷新策略的持久性和延迟。
以下是配置：
# The number of messages to accept before forcing a flush of data to disk
log.flush.interval=10
# The maximum amount of time a message can sit in a log before we force a flush
log.default.flush.interval.ms=100
# The interval (in ms) at which logs are checked to see if they need to be
# flushed to disk.
log.default.flush.scheduler.interval.ms=100
有几个重要的权衡：
因此，我认为没有办法将其降至150ms-250ms的水平。（没有硬件升级）。我不想回避这个问题，但我认为对于这个用例来说，卡夫卡是一个糟糕的选择。虽然我认为卡夫卡很棒（我一直大力支持在我的工作场所使用它），但它的优势并不在于低延迟。它的优势在于高生产商吞吐量和对快速和慢速消费者的支持。虽然它确实提供了耐用性和容错性，但像rabbitMQ这样的通用系统也是如此。RabbitMQ还支持各种不同的客户端，包括node.js。与Kafka相比，rabbitMQ的不足之处在于，您需要处理极高的容量（比如150K msg/s）。在这一点上，兔子的耐用性开始崩溃，卡夫卡真的脱颖而出。rabbit的耐用性和容错能力在20K msg/s（以我的经验）下表现出色 此外，为了实现如此高的吞吐量，卡夫卡成批处理消息。虽然批处理很小，并且它们的大小是可配置的，但是如果不产生大量开销，就不能使它们太小。不幸的是，消息批处理使得低延迟非常困难。虽然您可以在Kafka中调整各种设置，但我不会在延迟需要始终小于1-2秒的情况下使用Kafka 此外，如果要启动新应用程序，Kafka 0.7.2也不是一个好的选择。现在所有的焦点都集中在0.8上，所以如果你遇到问题，你将依靠自己，我绝对不会期望有任何新功能。对于未来的稳定版本，请点击这里的链接
再一次，我认为卡夫卡对于一些非常具体但很流行的用例来说是非常好的。在我的工作场所，我们使用兔子和卡夫卡。虽然这似乎是无缘无故的，但它们确实是互补的。卡夫卡可以通过使用同步消息传递实现大约毫秒的延迟。使用同步消息传递，生产者在发送消息之前不会将消息收集到修补程序中
bin/kafka-console-producer.sh --broker-list my_broker_host:9092 --topic test --sync
--batch-size 1
我知道这个问题已经问了一年多了，但我刚刚为开发目的构建了一个Kafka集群，我们看到现代版本的Kafka似乎有非常小的延迟，如以下结果所示： 2毫秒（中位数） 3毫秒（第99百分位）
14毫秒（99.9个百分位数）是否存在使用卡夫卡的限制？我之所以这么问，是因为卡夫卡的优势在于它拥有大量的慢速和快速消费者。折衷是，它的延迟不如其他消息传递系统那么可调。消费者配置中的
fetch.message.max.bytes获取请求的大小必须至少与服务器允许的最大消息大小一样大，否则生产者可以发送比消费者能够获取的消息大的消息。