这取决于您的配置。
对于需要强一致性的操作，如控制器选举（决定分区领导者）、代理注册、动态配置、acl-s等，kafka由cp zookeeper提供支持。
至于您发送给kafka的数据，可以在生产者级别、每个主题或/或更改代理默认值上配置担保。
带默认配置的开箱即用( min.insync.replicas=1 , default.replication.factor=1 )您正在获取ap系统（最多一次）。
如果你想达到cp，你可以设置 min.insync.replicas=2 主题复制因子为3-然后生成一条消息 acks=all 将保证cp设置（至少一次），但（如预期）在没有足够的副本（<2）可用于特定主题/分区对的情况下将被阻止(见设计（ha，生产商配置文件）
Kafka管道可以进一步精确地调整一次方向。。
cap和pacelc
在pacelc方面，一些改善延迟的决定已经变成了默认。例如，Kafka在默认情况下不会 fsync 每一条消息都会写入到磁盘，并让操作系统处理刷新。默认情况下，为了持久性，首选使用复制。它也是可配置的-请看 flush.messages , flush.ms 代理/主题配置。
由于它接收的消息的一般性（它只是一个bytestream），它不能进行任何分区后合并，也不能使用crdts技巧来保证分区期间的可用性，并最终恢复一致性。
我不知道你怎么做 give up 期间延迟的一致性 normal operation 在kafka-s泛型bytestream中。您可能会放弃强一致性（线性化）并尝试获得“更高的一致性”（覆盖更多的故障场景，或减少数据丢失的大小），但这实际上是调整ap系统以获得更高的一致性，而不是调整cp以获得更低的延迟。
您可能会看到ap/cp权衡和配置以至少一次、最多一次和恰好一次的形式呈现。
测试
为了理解这些参数如何影响延迟，我认为最好的方法是用不同的参数测试你的设置。以下命令将生成1gb的数据：

kafka-producer-perf-test --topic test --num-records 1000000 --record-size 100 --throughput 10000000 --producer-props bootstrap.servers=kafka:9092 acks=all`

然后尝试使用不同的producer参数：

acks=1  
acks=all  
acks=1 batch.size=1000000 linger.ms=1000  
acks=all batch.size=1000000 linger.ms=1000

它很容易启动集群和启动/停止/杀死节点来测试一些失败场景，例如使用compose
链接和引用
您可能会检查（不幸的是过时了，但仍然与主题相关）jepsen测试和后续工作，只是为了添加一些关于这是如何随时间发展的上下文。
我强烈建议查看一些论文，这将提供更多的视角：
对cap定理的批判。马丁·克莱普曼
12年后：规则是如何改变的。埃里克·布鲁尔