分布式系统架构——CAP理论

1 什么是CAP

在分布式系统中，任何存储系统（有状态服务）都会涉及到CAP定理：

• Consistency：一致性，简称C。在同一时刻所有节点是具有同样的数据副本，每个节点的数据要保证实时同步。
• Availability：可用性，简称A。对于一个集群整体而言，能够不间断的对外提供读写请求，集群内部一部分节点出现故障不会影响整个集群。
• Partition tolerance：分区容错性，简称P。在分布式系统中，难以避免网络故障（如网络延迟、丢包等）等问题。在出现网络故障时，集群仍能正常对外提供读写请求服务，但是数据可能是一致性的或者非一致性的，也就是能对外提供一致性或可用性的服务。

2 C和A二则不可兼得

在分布式系统中，P是一定要实现的，必须要保证每个节点上的服务都能够正常对外提供读写请求，只有这样在出现网络故障时才有选择性，要阻塞还是不阻塞，可以根据要实现什么样的系统来进行抉择。
C和A二则不可兼得，下面来进行说明
假设有Node01和Node02两台机器，每台机器上部署了一个DB。

在网络正常的情况下，在Node01节点写入了一个“A”，然后同步给了Node02，在Node02上也能正常访问到“A”。

再次向Node01发起一个请求，将“A”更新为“B”，此时Node01和Node02之间发生了网络故障，“B”无法同步给Node02。由于网络容错性，Node02任然能够对外提供服务，如果获取数据的请求分发到了Node02上，这个时候就只有两个选择：一是舍弃可用性，保证一致性，阻塞请求直到网络恢复，“B”成功同步到Node02上；

二是舍弃一致性，保证可能性，此时无法获取到最新的数据“B”。

3 Zookeeper不适合直接做注册中心

Zookeeper遵从的是CP原则，保证数据的一致性。
假设Zookeeper有两个节点（ZK的节点数实际为奇数）ZK01和ZK02，三个App往ZK上注册服务，ZK01是leader节点，ZK02往ZK01同步数据，ZK01和App1、App2在同一个IDC，ZK02和App3在同一个IDC。如果此时发生了故障，App3就会被阻塞，无法向ZK02注册服务，其他服务也不能通过ZK02发现服务，任何访问ZK02的请求都会被阻塞，直到网络恢复，这显然无法保证服务的高可用。

注册中心不需要数据的强一致性，每个App可以向不同的注册中心节点注册服务，只要保证最终一致性即可，所以能作为注册中心的组件应该遵从AP原则。