Kafka的主要开发人员表示Kafka是CA而CAP是CAP定理。但我很困惑，卡夫卡不是分区容忍的吗？我认为确实如此，当一个复制失败时，另一个将成为领导者并继续工作！
另外，我想知道如果Kafka使用P怎么办？ P会伤害C还是A？
CAP定理指出，任何分布式系统最多可以提供三种保证中的两种：一致性，可用性和分区容差。
根据Engineers at LinkedIn（Kafka最初成立的地方），Kafka是一个CA系统：
所有分布式系统必须在保证一致性，可用性和分区容差（CAP定理）之间进行权衡。我们的目标是支持在单个数据中心内的Kafka群集中进行复制，其中网络分区很少，因此我们的设计侧重于维护高可用性和高度一致性的副本。强一致性意味着所有副本都是字节到字节相同的，这简化了应用程序开发人员的工作。
但是，我会说这取决于你的配置，更准确地说，取决于变量acks，min.insync.replicas和replication.factor。根据docs，
如果主题仅配置了两个副本且一个失败（即，同步副本中只有一个仍然存在），则指定acks = all的写入将成功。但是，如果剩余的副本也失败，则这些写入可能会丢失。虽然这确保了分区的最大可用性，但对于喜欢耐用性而非可用性的一些用户来说，这种行为可能是不合需因此，我们提供了两种主题级配置，可用于优先考虑消息的持久性和可用性：
- 禁用不洁的领导者选举 - 如果所有副本都不可用，则分区将保持不可用，直到最近的领导者再次可用。这有效地优先于消息丢失风险的不可用性。请参阅上一节关于不洁领导人选举的部分以获得澄清。
- 指定最小ISR大小 - 如果ISR的大小高于某个最小值，则分区将仅接受写入，以防止丢失仅写入单个副本的消息，该副本随后变为不可用。此设置仅在生产者使用acks = all时生效，并保证至少通过此许多同步副本确认消息。此设置提供了一致性和可用性之间的权衡。最小ISR大小的更高设置保证了更好的一致性，因为保证将消息写入更多副本，这降低了它将丢失的可能性。但是，它会降低可用性，因为如果同步副本的数量低于最小阈值，则分区将无法进行写入。
如果你read CAP如何定义C，A和P，“CA但不是P”只是意味着当任意网络分区发生时，每个Kafka主题分区将停止提供请求（丢失A）或丢失一些数据（丢失C） ）或两者，取决于其设置和分区的细节。
如果网络分区从Zookeeper拆分所有ISR，并使用默认配置unclean.leader.election.enable = false，则不能选择副本作为领导者（丢失A）。
如果至少有一个ISR可以连接，它将被选举，因此它仍然可以提供请求（保留A）。但是对于默认的min.insync.replicas = 1，ISR可以落后于领导者大约replica.lag.time.max.ms = 10000。因此，通过选举它，卡夫卡可能会抛弃由前领导人确认给制片人的作品（输掉C）。
Kafka可以为一些有限的分区保留A和C.例如。您有min.insync.replicas = 2和replication.factor = 3，并且当网络分区发生时，所有3个副本都是同步的，并且它最多分裂1个ISR（单节点故障，或单DC故障或单个交叉直流链路故障） ）。
要为任意分区保留C，您必须设置min.insync.replicas = replication.factor。这样，无论选择哪个ISR，都可以保证获得最新数据。但与此同时，在分区恢复之前它将无法提供写请求（丢失A）。
CAP是一个证明定理，因此没有分布式系统在故障期间可以完全具有特征C，A和P.如果Kafka使用P，即当群集分成两个或更多个孤立部分时，它可以继续运行，应该牺牲其中一个C或A.
也许如果我们将Kafka和Zookeeper节点视为整个集群，因为Kafka需要zookeeper节点，在丢失与zookeeper节点的连接的情况下我们不能认为它是分区容忍的。