cap是一个经过证明的定理，因此在故障期间，没有一个分布式系统可以同时具有c、a和p特征。如果Kafka使用p，也就是说，当集群分裂成两个或多个孤立的部分，它可以继续运作，其中一个c或a应该牺牲。
如果我们把kafka和zookeeper节点看作一个完整的集群，由于kafka需要zookeeper节点，所以不能考虑在失去与zookeeper节点连接的情况下它的分区容错性。

cap定理指出，任何分布式系统最多只能提供三个保证中的两个：一致性、可用性和分区容限。
根据linkedin（Kafka的最初创始地）的工程师说，Kafka是一个ca系统：
所有分布式系统都必须在保证一致性、可用性和分区容限（cap定理）之间进行权衡。我们的目标是在单个数据中心内的kafka集群中支持复制，在这个集群中，网络分区很少，因此我们的设计侧重于维护高可用性和强一致性的副本。强一致性意味着所有副本都是字节到字节相同的，这简化了应用程序开发人员的工作。
但是，我想说，这取决于您的配置，更确切地说取决于变量 acks , min.insync.replicas 以及 replication.factor . 根据文件，
如果一个主题只配置了两个副本，而其中一个失败（即，只剩下一个同步副本），那么指定acks=all的写入将成功。但是，如果剩余的复制副本也失败，则这些写操作可能会丢失。尽管这确保了分区的最大可用性，但对于某些喜欢持久性而不是可用性的用户来说，这种行为可能是不可取的。因此，我们提供了两种主题级配置，可用于优先选择消息持久性而不是可用性：
禁用不干净的引线选择-如果所有副本都不可用，则分区将保持不可用，直到最近的引线再次可用。这实际上更倾向于不可用性而不是消息丢失的风险。请参阅上一节关于不洁领导人选举的说明。
指定最小isr大小—只有当isr的大小大于某个最小值时，分区才会接受写入，以防止仅写入单个副本的消息丢失，而这些消息随后将变得不可用。此设置仅在生产者使用acks=all并保证消息将被至少这么多同步副本确认时生效。此设置提供了一致性和可用性之间的权衡。最小isr大小的更高设置可确保更好的一致性，因为可以保证将消息写入更多副本，从而降低消息丢失的可能性。但是，它会降低可用性，因为如果同步副本的数量下降到最小阈值以下，分区将不可用于写入。

如果您阅读了cap如何定义c、a和p，“ca而不是p”仅仅意味着当任意网络分区发生时，每个kafka主题分区将停止服务请求（lose a），或丢失一些数据（lose c），或两者兼而有之，这取决于它的设置和分区的具体情况。
如果网络分区使用默认配置从zookeeper中拆分所有ISR unclean.leader.election.enable = false ，没有副本可以被选为领导者（lose a）。
如果至少有一个isr可以连接，它将被选中，因此它仍然可以服务于请求（保留一个）。但是违约了 min.insync.replicas = 1 isr可以落后于领导者大约 replica.lag.time.max.ms = 10000 . 因此，通过选举，Kafka有可能丢掉前领导人（lose c）向制片人确认的作品。
Kafka可以为一些有限的分区同时保留a和c。e、 g.你有 min.insync.replicas = 2 以及 replication.factor = 3 ，并且当网络分区发生时，所有3个复制副本都是同步的，并且最多分离1个isr（单个节点故障、单个dc故障或单个交叉dc链路故障）。
要为任意分区保留c，必须设置 min.insync.replicas = replication.factor . 这样，无论哪个isr当选，都能保证拥有最新的数据。但同时，在分区恢复之前，它将无法提供写请求（丢失一个）。