CAP原理应用与分布式矩阵

CAP原理是描述一致性，可用性，和分区兼容性的理论，但这个原理用在实际情况下时往往让人很困惑。什么样的情况适用于这样的原理？有哪些先决条件？如何创建一个同时满足一致性和可用性，分区兼容性的分布式系统？等等的问题。现在我就尝试使用一种简单易懂的方式来把分布式的各种问题抽茧剥丝的放在大家面前。

首先我们把红色的球定义为数据，蓝色的框定义为容器。那么分布式的问题就可以简化为数据如何放入容器内和如何访问的问题？容器也就是CAP原理所描述的分区。当你想把1个数据放入到n分区时我们可以有3种放入的方式。

第一种CP的方式，假设当前有两个容器，我们把数据切分为两个部分，分别放入AB两个容器中。这个分布式模型中能够保证数据的一致的，即数据被平分为左右两个部分，不会出现数据的歧义，那么这个模型下也是有分区兼容性的因为被平分之后放入两个分区中。

这里一致性指的是当修改分区内的数据A时。两个容器内的数据也是相同的，不会出现数据歧义。但当AB其中任何一个分区无法使用时。就会获取不到全部的数据，导致数据出现不可用的状态。

第二种AP的方式，我们把数据复制两份分别放入AB两个分区。当AB任意分区不能使用的情况下，也可以使用数据，保持数据的可用性。

但当两个容器分别修改数据就会导致不能获得一致的数据，这就是AP方式保持可用性和分区兼容性，牺牲数据一致性。

第三种CA的方式，就是保持数据的一致性和可用性牺牲数据分区兼容性。直白的说就是把数据完整的放到一个分区内，那么他也不是一个分布式系统。

好的以上就是关于CAP基本原理的介绍。那么设计一个分布式系统最基本要考虑的，就是如何把数据放入到各个分区中。因为CA就不是一个分布式系统，那么它首先可以被排除掉了。在剩下的CP和AP中对数据的一致性就成了必然的选择，因为不可用的数据或者互相矛盾的数据显然是不可以接受的。那么我们唯一的选择就剩下了CP的分布式系统。但CP的问题也很明显就是任何一个分区或叫节点崩溃之后数据就是不完整的了，会导致数据的错误和不可使用。作为一个互联网工程师首先想到的是我们为每一个分区加上备份服务器好不好呢？而CAP原理的作者认为你加入的不是备份服务，对于CAP原理来说只是是将CP的方式变为了AP的方式。

备份服务器A1与B1与原来的服务器组合成了一个怪异的CP与AP的混合体。虽然增加了可用性，备份服务器与原服务器如果因为任何意外的原因产生数据不一致那么整个系统就失去了一致性，这个组合就是变成了AP系统。所以我们要把备份服务器A1放到A的后面让用户不能直接修改A1服务器。A1服务器只能由A服务器来修改。

那么分布式系统就变成了一个由CP面和AP面组成的矩阵。

在一般情况下其中CP面负责统一的对外通信，提供统一的可分区的数据服务。AP面对用户为不可见状态，当CP面任意节点崩溃或不可用时，在AP方向选择一个可用的服务器转为CP服务器继续为用户提供服务。只要系统有足够多的AP服务器可以转换为CP服务器使其抵消不可用服务器的概率，那么就能保证整个分布式矩阵式CP&AP完备。

在这个分布式矩阵里也可以不单单使用某个面为外部提供数据服务。在系统的设计上可以使用AP节点为用户提供只读服务。这也不局限在CP节点或者某个面，任意的节点其实都可以对外提供只读服务。那么对于可靠性要求不高的只读服务，所有节点就相当于是一个平面二维的系统。可见分布式矩阵相当的灵活，可以依据用户视图做不同的切割。

那么在现实中有没有CP&AP的系统呢？答案是有的，传统的主从服务器就是一个C&AP的系统。注意这里是C&AP不是CP&AP，因为单机的主从系统并不是分布式的。但是提供分布式服务的主从系统例如大型的网站加上阿里的云的数据库，就可以看作是CA&AP完备的系统。因为阿里云的数据库隐含的，提供了主从备份和磁盘备份，相当于对用户和开发者不可见的AP系统。

同理现在的区块链技术也是一个C&AP的系统。由一个POW或DPOS选择的C提供一致性服务，与全网或若干服务器提供的AP服务，组成的单C的分布式矩阵。

接下来深度讨论一个关于一致性定义的问题。因为这涉及到一个C容器能否划分为CP容器的问题？也就是什么样的数据需要一致性的问题？

我们看上图，一个全部为红色的球分为两半分别放入AB两个容器。当A容器内的球变为绿色的时候。把容器内的两个球拿出来拼成绿红的球是否是一个有效的球，如果有效的球，那么我们称这个球是可以分区的，也就是分区兼容的数据。如果这个球必须是全部变成绿才是有效的，那么这个数据本身就是分区不兼容的数据。

那么将C&AP转为CP&AP的过程，就要找到C中可以分区兼容的数据进行分区的过程。

 

参考资料：

http://blog.csdn.net/godfrey90/article/details/6754884