CAP理论/AP架构/CP架构

浅浅的花香味﹌ 2022-05-15 15:19 161阅读 0赞

最近有时间研究分布式架构，因为公司使用的Zookeeper，并没有使用Spring Cloud Eureka，所以想探究一下他们之间的区别，于是看到简书里的文章：[Spring Cloud Eureka简介及与Zookeeper对比][Spring Cloud Eureka_Zookeeper]，明显的区别可能就是Zookeeper为CP设计，而Eureka为AP设计，但是对CAP/AP/CP很不理解，于是查阅资料，做一个简单的了解。

> Eureka服务治理机制与Dubbo服务治理机制的比较
> 
> <table> 
>  <thead> 
>   <tr> 
>    <th>Feature</th> 
>    <th>Eureka</th> 
>    <th>Zookeeper</th> 
>   </tr> 
>  </thead> 
>  <tbody> 
>   <tr> 
>    <td>服务健康检查</td> 
>    <td>可配支持</td> 
>    <td>(弱)长连接，keepalive</td> 
>   </tr> 
>   <tr> 
>    <td>CAP</td> 
>    <td>AP</td> 
>    <td>CP</td> 
>   </tr> 
>   <tr> 
>    <td>watch支持（客户端观察到服务提供者变化）</td> 
>    <td>支持 long polling/大部分增量</td> 
>    <td>支持</td> 
>   </tr> 
>   <tr> 
>    <td>自我保护</td> 
>    <td>支持</td> 
>    <td>-</td> 
>   </tr> 
>   <tr> 
>    <td>客户端缓存</td> 
>    <td>支持</td> 
>    <td>-</td> 
>   </tr> 
>   <tr> 
>    <td>自身集群的监控</td> 
>    <td>metrics</td> 
>    <td>-</td> 
>   </tr> 
>  </tbody> 
> </table>
> 
> Eureka支持健康检查，自我保护等
> 
> Zookeeper为CP设计，Eureka为AP设计。作为服务发现产品，可用性优先级较高，一致性的特点并不重要，宁可返回错误的数据，也比不反回结果要好得多。
> 
> 服务列表变更Zookeeper服务端会有通知，Eureka则通过长轮询来实现，Eureka未来会实现watch机制

CAP理论提出就是针对分布式数据库环境的，所以，P这个属性是必须具备的。  
P就是在分布式环境中，由于网络的问题可能导致某个节点和其它节点失去联系，这时候就形成了P(partition)，也就是由于网络问题，将系统的成员隔离成了2个区域，互相无法知道对方的状态，这在分布式环境下是非常常见的。  
因为P是必须的，那么我们需要选择的就是A和C。  
大家知道，在分布式环境下，为了保证系统可用性，通常都采取了复制的方式，避免一个节点损坏，导致系统不可用。那么就出现了每个节点上的数据出现了很多个副本的情况，而数据从一个节点复制到另外的节点时需要时间和要求网络畅通的，所以，当P发生时，也就是无法向某个节点复制数据时，这时候你有两个选择：  
选择可用性 A(Availability)，此时，那个失去联系的节点依然可以向系统提供服务，不过它的数据就不能保证是同步的了（失去了C属性）。  
选择一致性C(Consistency)，为了保证数据库的一致性，我们必须等待失去联系的节点恢复过来，在这个过程中，那个节点是不允许对外提供服务的，这时候系统处于不可用状态(失去了A属性)。

最常见的例子是读写分离，某个节点负责写入数据，然后将数据同步到其它节点，其它节点提供读取的服务，当两个节点出现通信问题时，你就面临着选择A（继续提供服务，但是数据不保证准确），C（用户处于等待状态，一直等到数据同步完成）。

[Spring Cloud Eureka_Zookeeper]: https://www.jianshu.com/p/e47c027a9aeb