11

我开始了解 Apache Kafka。这篇https://engineering.linkedin.com/kafka/intra-cluster-replication-apache-kafka文章指出 Kafka 是 CAP 定理中的 CA 系统。因此，它关注副本之间的一致性以及整体可用性。

我最近听说了一个名为 PACELC 的 CAP 定理的扩展（https://en.wikipedia.org/wiki/PACELC_theorem）。这个定理可以这样形象化：

在此处输入图像描述

我的问题是如何在 PACELC 中描述 Apache Kafka。我认为 Kafka 在发生分区时关注一致性，但如果没有发生分区怎么办？关注的是低延迟还是强一致性？

谢谢！

4

1 回答 1

12

这将取决于您的配置。

Kafka 由 CP ZooKeeper 支持，用于需要强一致性的操作，例如控制器选举（决定分区领导者）、代理注册、动态配置、acl-s 等。
至于您发送到 kafka 的数据 - 保证可在生产者上配置级别，每个主题的基础或/和更改代理默认值。

开箱即用的默认配置（min.insync.replicas=1, default.replication.factor=1）您将获得 AP 系统（最多一次）。

如果您想实现 CP，您可以将min.insync.replicas=2主题复制因子设置为 3 - 然后生成一条消息acks=all将保证 CP 设置（至少一次），但（如预期）在没有足够副本（<2 ) 可用于特定主题/分区对。（参见design_ha，生产者配置文档）

Kafka 流水线可以进一步向精确一次方向调整。

CAP 和 PACELC
就 PACELC 而言，一些延迟改进决策已被默认为默认值。例如，kafka 默认情况下不会将fsync每条消息都写入磁盘 - 它会写入页面缓存并让操作系统处理刷新。默认值更喜欢使用复制来实现持久性。它也可配置 - 请参阅flush.messages代理flush.ms/主题配置。

由于它接收到的消息的通用性（它只是一个字节流） - 它不能进行任何分区后合并，或使用 CRDT 技巧来保证分区期间的可用性，并最终恢复一致性。

我看不到/不知道在 kafka-s通用字节流案例中如何give up保持延迟的一致性。您可能会放弃强一致性（线性化）并尝试具有“更高的一致性”（涵盖更多的故障场景，或减少数据丢失的大小），但这有效地调整 AP 系统以获得更高的一致性，而不是调整 CP 以获得更低的延迟.normal operation

您可能会看到 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`

然后尝试使用不同的生产者参数： 

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

它很容易启动集群和启动/停止/杀死节点来测试一些故障场景，例如使用compose

链接和参考
您可能会检查（遗憾的是已过时，但仍与主题相关）jepsen test and follow-up，只是为了添加一些关于它如何随着时间演变的上下文。

我强烈建议查看一些论文，这将提供更多视角：
A Critique of the CAP Theorem。Martin Kleppmann
CAP 十二年后：“规则”如何改变。埃里克·布鲁尔

于 2018-01-17T16:11:36.320 回答