标签：Erueka CAP SpringCloud Consul 可用性 一致性 CP 分区
ErueKa,Zookeeper,Consul区别
| 组件名 | 开发语言 | CAP | 服务健康检查 | 对外暴露接口 | SpringCloud集成 | 原生Web界面 |
|---|---|---|---|---|---|---|
| Eureka | Java | AP | 可配支持 | HTTP | 已集成 | 有 |
| Zookeeper | Java | CP | 支持 | 客户端 | 已集成 | 无 |
| Consul | Go | CP | 支持 | HTTP/DNS | 已集成 | 有 |
CAP理论
- C : Consistency (强一致性)
- A : Availability (可用性)
- P : Partition tolearnce (分区容错性)
CAP原则的精髓就是要么AP，要么CP，要么AC，但是不存在CAP。如果在某个分布式系统中数据无副本， 那么系统必然满足强一致性条件， 因为只有独一数据，不会出现数据不一致的情况，此时C和P两要素具备，但是如果系统发生了网络分区状况或者宕机，必然导致某些数据不可以访问，此时可用性条件就不能被满足，即在此情况下获得了CP系统，但是CAP不可同时满足。
AP架构（Eureka）
当网络分区出现后，为了保证可用性，系统B可以返回旧值，保证系统的可用性。结论：违背了一致性C的要求，只满足可用性和分区容错，即AP。
CP架构（ZooKeeper/Consul）
当网络分区出现后，为了保证一致性，就必须拒接请求，否则无法保证一致性。结论：违背了可用性A的要求，只满足一致性和分区容错，即CP。
标签：Erueka,CAP,SpringCloud,Consul,可用性,一致性,CP,分区 来源： https://blog.csdn.net/qq_42091436/article/details/121794069
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。