电子商务网站规划 分析 设计,阜阳网页,开发软件需要什么,照明灯具类企业网站分布式系统 CAP 定理 P 代表什么含义 作者之前在看 CAP 定理时抱有很大的疑惑#xff0c;CAP 定理的定义是指在分布式系统中三者只能满足其二#xff0c;也就是存在分布式 CA 系统的。作者在网络上查阅了很多关于 CAP 文章#xff0c;虽然这些文章对于 P 的解释五花八门CAP 定理的定义是指在分布式系统中三者只能满足其二也就是存在分布式 CA 系统的。作者在网络上查阅了很多关于 CAP 文章虽然这些文章对于 P 的解释五花八门但总结下来这些观点大多都是指 P 是不可缺少的也就是说在分布式系统只能是 AP 或者 CP这种理论与我之前所认识的理论存在分布式 CA 系统是冲突的所以才有了疑惑。 这个定理起源于加州大学柏克莱分校University of California, Berkeley的计算机科学家埃里克·布鲁尔在 2000 年的分布式计算原理研讨会PODC上提出的一个猜想。 在 2002 年麻省理工学院MIT的赛斯·吉尔伯特和南希·林奇发表了布鲁尔猜想的证明使之成为一个定理。 什么是 CAP 定理CAP theorem 在理论计算机科学中CAP 定理CAP theorem又被称作布鲁尔定理Brewers theorem它指出对于一个分布式计算系统来说不可能同时满足以下三点 一致性Consistency 等同于所有节点访问同一份最新的数据副本 可用性Availability每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据 分区容错性Partition tolerance以实际效果而言分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性就意味着发生了分区的情况必须就当前操作在 C 和 A 之间做出选择。 分区容错性Partition tolerance 理解 CAP 理论的最简单方式是想象两个节点分处分区两侧。允许至少一个节点更新状态会导致数据不一致即丧失了 C 性质。如果为了保证数据一致性将分区一侧的节点设置为不可用那么又丧失了 A 性质。除非两个节点可以互相通信才能既保证 C 又保证 A这又会导致丧失 P 性质。 P 指的是分区容错性分区现象产生后需要容错容错是指在 A 与 C 之间选择。如果分布式系统没有分区现象没有出现不一致不可用情况 本身就没有分区 既然没有分区则就更没有分区容错性 P。 无论我设计的系统是 AP 还是 CP 系统如果没有出现不一致不可用。 则该系统就处于 CA 状态 P 的体现前提是得有分区情况存在 文章来源维基百科 CAP 定理 几个常用的 CAP 框架对比 框架所属EurekaAPZookeeperCPConsulCP Eureka Eureka 保证了可用性实现最终一致性。 Eureka 所有节点都是平等的所有数据都是相同的且 Eureka 可以相互交叉注册。 Eureka client 使用内置轮询负载均衡器去注册有一个检测间隔时间如果在一定时间内没有收到心跳才会移除该节点注册信息如果客户端发现当前 Eureka 不可用会切换到其他的节点如果所有的 Eureka 都跪了Eureka client 会使用最后一次数据作为本地缓存所以以上的每种设计都是他不具备一致性的特性。 注意因为 EurekaAP 的特性和请求间隔同步机制在服务更新时候一般会手动通过 Eureka 的 api 把当前服务状态设置为offline并等待 2 个同步间隔后重新启动这样就能保证服务更新节点对整体系统的影响 Zookeeper 强一致性 Zookeeper 在选举 leader 时会停止服务只有成功选举 leader 成功后才能提供服务选举时间较长内部使用 paxos 选举投票机制只有获取半数以上的投票才能成为 leader否则重新投票所以部署的时候最好集群节点不小于 3 的奇数个但是谁能保证跪掉后节点也是奇数个呢Zookeeper 健康检查一般是使用 tcp 长链接在内部网络抖动时或者对应节点阻塞时候都会变成不可用这里还是比较危险的 Consul 和 Zookeeper 一样数据 CP Consul 注册时候只有过半的节点都写入成功才认为注册成功leader 挂掉时重新选举期间整个 Consul 不可用,保证了强一致性但牺牲了可用性 有很多 blog 说 Consul 属于 ap官方已经确认他为 CP 机制 原文地址https://www.consul.io/docs/intro/vs/serf 获取更多干货内容记得关注我哦。 本文由 mdnice 多平台发布
