189 8069 5689
本篇文章给大家分享的是有关微服务架构中的CAP原理是什么，小编觉得挺实用的，因此分享给大家学习，希望大家阅读完这篇文章后可以有所收获，话不多说，跟着小编一起来看看吧。
创新互联是专业的岚县网站建设公司，岚县接单;提供成都做网站、成都网站制作,网页设计,网站设计,建网站,PHP网站建设等专业做网站服务;采用PHP框架,可快速的进行岚县网站开发网页制作和功能扩展;专业做搜索引擎喜爱的网站,专业的做网站团队,希望更多企业前来合作!
什么是分布式 CAP 原理，什么是分区容错性，zookeeper 和 eureka 的 CAP 区别是什么，还有作为公司的架构师你们是怎么做的，那些分布式系统设计成了 CP、AP，为什么这样设计等等一系列问题。
C（Consistency）：一致性，即数据一致性，特指分布式系统中的数据一致性。
A（Availability）：可用性，即服务的高可用，特指分布式系统中服务的高可用，某个服务瘫痪不影响整个分布式系统的正常运行。
P（Partition Tolerance）：分区容错性（也有的叫分区耐受性），即网络故障，特指分布式系统中服务之间出现了网络故障，整个分布式系统仍然保持可用性和一致性。
一句话概括 CAP：在分布式系统中，网络故障，服务瘫痪，整个系统的数据仍然保持一致性。
上面的表述可能不容易理解，举一个通俗的例子讲讲什么是分布式 CAP 原理。
如上图所示，小张在京东商城准备购买几本微服务实战相关的书籍，订单总金额共 200 元，他刚好有一张满 200 减 100 元的优惠劵。
这时分 3 种情况说明分布式系统的 CAP 如下：
数据一致性体现：
使用 100 元优惠劵扣减，实付 100 元，优惠劵用完。
使用 100 元优惠劵失败，实付 200 元，优惠劵还在。
系统可用性体现：
小张下订单时，订单服务或是 PLUS 会员服务挂了，此时不应该影响小张下单。
系统分区容错性体现：
小张下订单时，订单服务和 PLUS 会员服务之间网络不通也不能影响小张下单。
CAP 定理中最难理解的概念是 P，分区容错性，画个图大家就理解了。
在断网的情况下，2 台服务器变成了独立网络，彼此无法通信，这个情况就是分区。在分区的情况下，分布式系统如果要保证数据一致性和可用性的话，那就满足分区容错性了。
目前大部分互联网企业都是微服务架构，即分布式系统。
现在某电商微服务架构，假设出现网络故障（P），服务挂掉（A），整个系统的数据仍然保持一致。这是无法做到的。
相对可以实现的方案：
业界的做法是 CAP 三选其二，即
CP
AP
CA（请思考？后面叙述）
当服务之间出现网络故障的情况下：
问题：
如何保证订单服务和 PLUS 会员服务高可用？
下订单同时扣除 100 元优惠劵如何实现？
分布式系统的解决方案：
CAP 牺牲一致性（AP）：保证高可用，即保证订单服务可以正常访问，保证 PLUS 会员服务可以正常访问，牺牲了数据的一致性。
小张去京东商城下订单（但是没有扣除 100 元优惠劵），这种情况下，小张订单提交成功后，再去查看 100 元优惠劵还在，居然没有扣除成功，但是实付金额是 100 元，很纳闷（心里窃喜）。
怎么办呢？如何解决这种问题？
一般的做法是，当网络恢复正常的情况下，订单服务重试请求 PLUS 会员服务，再扣除 100 元优惠劵。
CAP 牺牲可用性（CP）：保证数据一致性。
当小张去京东商城下单时，提示：“网络异常，请稍后再试”。
怎么办呢？如何解决这种问题？
只能等网络恢复正常后，小张才可以成功下单。
CAP 牺牲分区容错性（CA）：不要P分区，即不允许出现网络故障，这是不可能实现的。
所以在分布式系统中，是不存在 CA 的。即使传统单体系统也做不到CA，因为单体系统也会出现单一故障。
通过小张在京东商城下订单的案例，小伙伴应该都弄明白了吧。
1）图解 zookeeper 的 CAP 原理
注：此处不介绍 zookeeper 底层原理和实现
zookeeper 作为微服务注册中心是 CP 原理，即保证了数据的一致性，牺牲了可用性。如下图所示：
zookeeper 的数据同步原理：
Client1 客户端向 zk Server1 注册，zk Server1 同步信息给 zk Server2，zk Server2 是注册中心的 leader 节点，该节点负责把消息广播同步给其他 follower 的 zk 节点，为了保证数据的一致性，只有等整个注册中心信息同步完成，Client1客户端才能收到注册成功的消息。
如上图所示，当注册中心 leader 重启或是出现网络故障的情况下，整个 zk 集群重新选举 leader 节点，在选举期间，Client 客户端无法注册，即此时 zookeeper 服务不可用，所以牺牲了系统的可用性。
如上图所示，只有等到整个系统选举出 leader 节点，系统才能恢复注册，故 zookeeper 为了保证数据一致性，牺牲了系统的可用性。
CP 有一个致命的缺点，就是在大型分布式系统中，网络非常复杂，leader 节点出现故障的频率特别高，而且很容易引起雪崩。所以这是很多大型分布式系统都不选择 zookeeper 作为注册中心的原因。
2）图解 Eureka 的 CAP 原理
如下图所示：
eureka 是 AP 原理，即保证了系统的可用性，却牺牲了系统的一致性。
eureka 的数据同步原理：
第一步，Client1 客户端注册到 eureka Server1 服务中；
第二步，eureka Server1 直接告诉 Client1 注册成功。
第三步，eureka Server1 把 Client1 的注册信息同步给 Server2，为了保证服务的可用性，eureka Server 之间是异步同步的。
通过以上的案例描述和图形解读，相信大家对于微服务（分布式系统）架构中 CAP 原理有了一定的了解。比如知道了什么是 CAP 原理，什么是分区容错性，zookeeper 和 eureka 作为注册中心的 CAP 区别是什么。同时希望对今后你们公司的系统架构设计有所帮助，系统设计是遵循 CP 还是 AP。
以上就是微服务架构中的CAP原理是什么，小编相信有部分知识点可能是我们日常工作会见到或用到的。希望你能通过这篇文章学到更多知识。更多详情敬请关注创新互联行业资讯频道。