09 | CAP定理：三选二，架构师必须学会的取舍
该思维导图由 AI 生成，仅供参考
CAP 定理
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
CAP定理是分布式系统设计中的重要定理，指出在分布式系统中，一致性、可用性和分区容错性最多只能同时存在两个属性。文章介绍了Kafka Replication在Kafka系统中的应用，通过数据复制增强了系统的持久性和可用性。系统设计中，领导者节点负责维护同步数据副本，确保数据写入和查询的正确性。在讨论CAP属性时，系统需要权衡选择哪两个属性保留，以满足特定需求和架构思想。读者通过本文了解了CAP定理的重要性和在实际系统中的应用，以及在设计分布式系统时需要考虑的取舍。文章以技术案例为例，生动展示了CAP定理的实际应用，为读者提供了深入理解分布式系统设计的思路和方法。
《大规模数据处理实战》，新⼈⾸单¥59
全部留言(77)
- 最新
- 精选
王燊 شن ون置顶我的理解：A是机器挂掉仍可用，P是网络挂掉仍可用。如果我的理解正确，那老师您说Kafka不支持P的解释，即当Kafka leader挂掉整个系统不可用，其实是不是表明Kafka是不支持A，而不是不支持P的？作者回复: 谢谢你的留言！你的理解非常正确，A就是指集群中即便挂掉几个机器但是集群对外还是正常运行的，P就是指即便机器间无法通讯了但是集群对外还是正常运行。 我对于Kafka Replication pick CA这种设计的理解是，设计师只考虑了在Replication的集群里对CA的保证而放弃了对P的保证。所以当发生Network Partition的时候，系统有可能可以工作，有可能不能继续工作。例如说C的保证是因为Kafka Replication要求了领导者节点的数据一定要同步数据副本节点上，否则不会返回这个数据；A的保证是因为无论有多少数据副本节点挂了，只要领导者节点不挂，这个Replication集群都可以返回数据，但是当领导者挂了，这整个Replication集群就不能再用了，而没了这个集群也就没有CAP属性可言了。希望这能帮助你理解，如果有不明确的地方也欢迎你继续留言提问，一起学习进步。
2019-05-10314
常超置顶关于大家出现很多疑问的Kafka是否有P属性的问题，上网搜了一下，找到一个可以说明Kafka不具备P属性的例子，不知道理解对不对，请老师和大家批评指正。 比如：在以下的场景序列下，会出现数据写入丢失的情况，所以不能说kafka是有P属性 前提：leader和两个slave 1、2 序列： 1.机器leader跟两个slave之间发生partion 这是leader成为唯一服务节点，继续接受写入请求w1,但是w1只保存在了leader机器上，无法复制到slave1和2 2.leader和zookeeper之间发生partition，导致kafka选取slave 1为新leader，新leader接受新写入w1 这时候，上面1的w1写入丢失了。即使之后旧leader复活，w1的写入数据也不会被恢复出来。 参考：https://bit.ly/2VGKtu1作者回复: 常超您好，又看到了您的留言！其实归根结底P属性还是说当Network Partition发生后，无论后面网络分区是否会恢复，分离出来的子系统都可以正常运行。您所说这几个例子确实是讲到了在Kafka Replication中，有的节点在分区后就无法再使用了，所以设计的时候并没有考虑P属性。另外还多加一句，并不是Kafka没有P属性，而是Intra-cluster Kafka Replication没有P属性。 谢谢你的参考资料，这对我和其他读者们来说都非常有帮助！
2019-05-0627
锦置顶AP，发微博保证最终一致性就可以。 疑问一，mongodb采用CP，那么它在可用性方面有做什么事情吗？ 疑问二，kafka这种通过选举leader的方式不就是分区容错性吗？为什么说放弃了P呢？作者回复: 谢谢你的答案。 关于疑问一：MongoDB的设计默认是希望读写有strong consistency的。当然MongoDB也有自身的Replica Set来保证可用性：https://docs.mongodb.com/manual/replication/#replication-in-mongodb 关于疑问二：你说的没有错，作为多个data clusters来说，Kafka系统是不可能放弃P的，不然一旦leader挂掉系统就没有任何结果可以返回了。但是我在这一讲中所讲述的Intra-cluster Kafka Replication Design是对于一个cluster来说。就像我回答其他有同样疑问的读者一样，之所以我在文中说Kafka Replication选择了CA，是因为Kafka的作者之一Jun Rao在设计Kafka Replication的时候，明确说明了“All distributed systems must make trade-offs between guaranteeing consistency, availability, and partition tolerance. Our goal was to support replication in a Kafka cluster within a single datacenter, where network partitioning is rare, so our design focuses on maintaining highly available and strongly consistent replicas.”，这一点是在Linkedin的官方文档上publish的。而在2013年的Apachecon上，Kafka Replication的技术演讲上也明确说明了“Kafka Replication: Pick CA”。 学习之后提出疑问是一个很好的习惯，也希望后面继续看到你的留言！
2019-05-0622- 常超置顶老师您好，文中说kafka放弃了P属性。 但是从后面的解释来看，即使出现分区（领导者节点和副本1无法通讯），整个系统也能正常工作，这种行为难道不是保持了P属性吗。您能否举一个P属性被放弃的例子？
作者回复: 常超您好，感谢您的提问！ 关于这个问题我是这么看的。当我们在分布式环境中讨论CAP属性的时候，P属性可以说是当任意节点断开后，系统还是可以正常的运行。对于整个Kafka系统来说，P当然是必须要保留的。可当你只从Kafka Replication来看的时候，如果一个cluster里面领导者挂掉了，单单就这个cluster来说有再多的副本存在也是无法运行了，所以就Kafka Replication来说，它没有保留P属性。 而在Kafka Replication的设计中为什么说P被放弃了呢，引用Kafka的作者之一Jun Rao在设计Kafka Replication的说法，是因为“All distributed systems must make trade-offs between guaranteeing consistency, availability, and partition tolerance. Our goal was to support replication in a Kafka cluster within a single datacenter, where network partitioning is rare, so our design focuses on maintaining highly available and strongly consistent replicas.”，这一点是在Linkedin的Engineering官方文档上publish的。而在2013年的Apachecon上，Kafka Replication的技术演讲上也明确说明了“Kafka Replication: Pick CA”。 不知道我的解释能否让您更好地理解，也欢迎您继续留言提问，我们一起学习进步！
2019-05-06314 - Codelife严格来说,CAP理论是针对分区副本来定义的，之所以说kafka放弃P，只支持CA，是因为，kafka原理中当出现单个broke宕机，将要出现分区的时候，直接将该broke从集群中剔除，确保整个集群不会出现P现象
作者回复: 谢谢你的留言！你的理解非常正确，就是因为这样Kafka Replication的设计中不需要考虑到P的存在，让整个Replication Design成为CA系统。
2019-05-06219 
coldpark有一个形象的比喻不知道恰当不恰当，一个系统相当于一个团队，有C属性说明这个团队每次都能保质保量完成任务，A属性说明这个团队每次都能及时完成任务，P属性相当于这个团队内部偶尔会犯一些小错误。犯错是很常见的，所以一般都具有P属性。 CP类型的团队对外的形象相当于：我的团队不是完美的，但我的产品绝对不会出问题，只要你给我足够的时间让我们把问题排查清楚。 AP类型的团队给人的感觉就是：人非圣贤，孰能无过，我的队员会犯错，我的团队也有估计不足的时候，但是客户的需求我们总会最快响应。 CA类型的团队有个强人领袖（leader节点）：任何事务无论大小都过问一遍，一旦发现手下有人犯错，立马剔除出团队，如果自己犯错，让出领袖地位，整个团队一定要保证最快最好完成任务。作者回复: 是有一定道理
2019-08-118
桃园悠然在另外，增加一个评论：蔡老师的文章头图每张都跟内容强相关（不知是否自己P图或者照相的），而且右上角有文章序号很用心，点赞！作者回复: 谢谢你的支持，哈哈！
2019-05-063
王聪 Clairekafka 的replication机制，即使出现分区这样的错误，系统也能够通过领导者节点返回消息。怎么算放弃了P呢？谢谢。作者回复: 谢谢你的提问！我的理解是如果仅仅就一个Kafka Replication cluster来说，如果领导者挂了我们就不会再从这个cluster拿到内容了，所以在Intra-cluster Replication这个设计点上，他们是不考虑P的。 之所以我在文中说Kafka Replication选择了CA，是因为Kafka的作者之一Jun Rao在设计Kafka Replication的时候，明确说明了“All distributed systems must make trade-offs between guaranteeing consistency, availability, and partition tolerance. Our goal was to support replication in a Kafka cluster within a single datacenter, where network partitioning is rare, so our design focuses on maintaining highly available and strongly consistent replicas.”，这一点是在Linkedin的官方文档上publish的。而在2013年的Apachecon上，Kafka Replication的技术演讲上也明确说明了“Kafka Replication: Pick CA”。 所以你会发现，他们的设计思路是仅仅就Intra-cluster的data replication出发的。当然，如果从整个Kafka系统来说，是不可能放弃P的。
2019-05-063
J.M.Liu老师，我好像懂了。kafka replication不保证p，指的是当网络出现分区后，和主有一台副本比如replicatin1和leader失联了，那replication1就会被踢出去，相当它于宕机了。在这里，分区导致replication1不可用了，所以说不保证p。 是这样理解吗？作者回复: 谢谢你的再次留言！是的，理解正确！既然replication1对于集群来说现在以及以后都不可用了，也就相对于集群没有了这个replication1，那也就不存在说网络分区后replication1还是否在集群正常运行的问题了。
2019-05-122
LaimanYeungA：集群某个或某几节点挂掉时，客户端仍然可以访问服务端. C：客户访问集群中任一服务端，返回的状态都是一致的. P：集群内部机器通讯出现问题导致服务A的数据无法同步到其他节点时，客户端访问服务A，服务A扔能返回未同步到其他节点的数据.作者回复: 谢谢你的总结！非常棒！
2019-05-1222
