三个注册中心对比

CAP定义

C：Consistency(强一致性)

A：Availability(可用性)

P：Partition tolerance(分区容错性)

CAP指标

最多只能同时较好的满足两个。

CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性、可用性和分区容错性这三个需求。

因此，根据CAP原理将NoSQL数据库分成了满足CA原则、满足CP原则和满足AP原则三大类：

• CA - 单点集群，满足一致性、可用性的系统，通常在可扩展性上不太强大。例如：RDBMS
• CP - 满足一致性、分区容错性的系统，通常性能不是特别高。例如：MongoDB、HBase、Redis
• AP - 满足可用性、分区容错性的系统，通常可能对一致性要求低一些。例如：CouchDB、Cassandra、DynamoDB、Riak

AP架构

当网络分区出现问题后，为了保证可用性，系统B可以返回旧值，保证系统的可用性。当数据出现不一致时，虽然系统A和系统B上的注册信息不完全相同，但是每个节点依然能够对外提供服务，这会出现查询服务信息是如果请求系统A失败，但是系统B能请求，如此保证了可用性但牺牲了一致性。

结论：违背了一致性（C）的要求，只满足可用性和分区容错性，即AP

案例：

1、当没有网络分区问题时，系统A和系统B数据是一直的，X=1

2、系统A数据发生变更，X=2

3、此时，网络分区问题，数据同步失败，两个系统的数据不一致，即系统A的X=2，系统B的X=1

4、当客户端请求系统B时，为了保证系统的可用性，此时系统B会返回旧值，即X=1

CP架构

当网络分区出现问题后，为了保持一致性，就必须拒接请求，否则无法保证一致性，例如Consul遵循CAP中的CP原则，保证了强一致性和分区容错性，且使用的是Raft算法，比Zookeeper使用的Paxos算法更加简单。虽然保证了强一致性，但是可用性就相应下降了，例如服务注册的时间会稍长一些，因为Consul的Raft协议要求必须过半的节点都写入成功才认为注册成功，在leader挂掉之后，重新选举出leader之前会导致Consul服务不可用。

结论：违背了可用性（A）的要求，只满足一致性和分区容错性，即CP

案例：

1、当没有网络分区问题时，系统A和系统B数据是一直的，X=1

2、系统A数据发生变更，X=2

3、此时，网络分区问题，数据同步失败，两个系统的数据不一致，即系统A的X=2，系统B的X=1

4、当客户端请求系统B时，为了保证一致性，此时系统B会拒绝服务请求，返回错误码和错误信息。