为什么Kafka不是cap定理中的p

ryevplcw  于 2021-06-08  发布在  Kafka
关注(0)|答案(3)|浏览(432)

Kafka的主要开发者说,Kafka在cap定理中是ca而不是p。但我很困惑,Kafka不能容忍吗?我想是的,当一个复制失败时,另一个将成为领导者并继续工作!
另外,我想知道如果Kafka用p怎么办?p会伤害c还是a?

s1ag04yj

s1ag04yj1#

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

mtb9vblg

mtb9vblg2#

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

mgdq6dx1

mgdq6dx13#

如果您阅读了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当选,都能保证拥有最新的数据。但同时,在分区恢复之前,它将无法提供写请求(丢失一个)。

相关问题