白话大数据之分布式系统CAP理论

Posted 2021-05-01 就爱极客

---

分布式系统

传统的系统架构形式是纵向扩展，所谓纵向扩展就是所说的“堆硬件”，1G内存不够，就再加上1G内存，依此类推。但是，这样做有一个坏处，就是提升的空间有限，不够灵活。随着硬件资源的越发便宜，再加上若干个节点组成一个集群已经可以从理论层面走向实践。通过集群的方式来构成我们私人的“超级计算机”理论上是没有问题的。

集群之间需要进行通信，通信的方式就采用TCP通信形式，虽然TCP通信能够保证可靠，但是，当网络连接发生中断的时候(学名叫做网络分区，后称之为网络分区)，很多数据就难以保证被及时获取。如果此时服务器集群正在对外部进行服务，那么这个任务就很难继续进行，此时服务器集群是对外返回一个“近似”的结果还是等待网络恢复或者直接返回错误信息呢？

这种服务器集群几个要素的权衡关系，就引出了今天所述的CAP理论。

CAP理论

CAP理论是服务器集群在设计时候所有考虑到的首要因素之一。所谓CAP是指:

C:强一致性

A:可用性

P:分区容错性

可用性

可用性就是指集群可以使用，能够在合理的时间内对外部提供服务；也就是在任何时间点对服务器集群的读写操作都能在规定的时间内得到应答。

一致性

一致性是指集群中每台节点中的数据都是一样的，例如读取服务器集群中任何一台节点中所获得的数据都是相同的，此时就可以称之为服务器集群中的节点是一致的。因为对于用户来说，服务器集群中的任何节点从宏观上来看都是相同的，他们的状态都是同步的。

例如服务器集群中节点A的状态发生改变，节点B，C等立刻跟随着A的状态发生改变，这个过程称之为同步。同步过程是需要时间的，这一点我们并不难理解，在这个时间区间内各个节点的状态是不能保证完全相同的，那么这个时间区间我们称之为不一致窗口。

当这个不一致窗口时间段过去之后，整个集群就完成了状态同步，整个集群也就是一致的了。

那么，所谓强一致性就是指这个不一致窗口时间很短，甚至没有。例如单节点的服务器一定是强一致的，因为集群中只有它自己，根本不需要同步。而弱一致性就是需要一个不一致窗口进行调节。分布式系统都是存在不一致窗口的，如果在这个不一致窗口内强行对外进行服务那么本身就是牺牲了一致性这个要素，而如果在这个不一致窗口内拒绝服务，直到同步完成，那么在宏观上来看，集群就是具有强一致性的了，这类似于线程模型中的锁的概念。

弱一致性分为好几个种类，例如单调读一致性，因果一致性，最终一致性等等。

分区容错性

我们在上面介绍过什么叫做网络分区，简言之就是集群中的通信发生了故障。在实际情况中，集群中的节点可能会很多，成百上千都很常见。那么，这么大规模的集群中出现网络通信延迟，丢包，连接失败都是很常见的。那么，这个集群就要容忍这种情况的发生，即当这种情况发生时，系统仍然能够工作，不至于挂掉。

鱼与熊掌

鱼，我所欲也，熊掌亦我所欲也；二者不可得兼，舍鱼而取熊掌者也。

在分布式系统中也一样，很多事情难以兼得。CAP理论证明了在C／A／P三要素中，任何一个集群只能选择其二，不可兼得。

举个简单的例子：

现在很流行的NoSQL数据库是支持横向扩展的，那么网络分区情况是在所难免的，因此P这个要素是必须保证的。然后，就是在C和A这两个要素中进行选择。

例如MongoDB选择了CP两个因素，那么，MongoDB集群要想保证强一致性，就要在节点同步时间段，也就是不一致窗口时间段内拒绝外部访问，直到全部节点同步完毕之后，才应答外部响应。那么，在这个层面来讲，MongoDB在一定程度上牺牲了高可用性。而Cassandra数据库则强调了AP两个因素，即要求集群无论在什么时候都要对外作出应答，哪怕这个结果是很老旧的结果，也要在规定时间内返回结果。

关于CAP三要素的一个示意图，下面有一个最经典的例子：