通过NAS对分布式系统CAP理论的理解

636 阅读4分钟

CAP原则又称CAP定理,指的是在一个分布式系统中:

Consistency(一致性)、 Availability(可用性)、Partition tolerance(分区容错性),三者不可得兼。

CAP理论在微服务架构中是经常被研究的问题,我在之前看书的时候却总是忘记这套理论,因为它在具体设计系统时CAP原则并不能全部实现,三者之间不同组合让人倍感迷惑,每个原则的舍弃都需要考虑后续可能存在的一系列问题,而我在具体开发中也没有遇到分布式数据同步的问题,只是大概记得这些理论。

最近买了NAS,想着搭起来一套私有云来同步自己的数据,在没有NAS之前我都是用硬盘+坚果云这样的组合来存储数据,坚果云是实时同步,但容量小,硬盘容量大,但要隔几天同步一次。在有了NAS后,我可以将数据实时同步到NAS中,再由它同步到硬盘或两个以上的云存储,我很难信任一种数据存储形式,可能存在的丢失风险太大,这其实就是单体架构,而有了NAS后,我可以选择的存储形式就达到四个以上,这时我突然回忆起了分布式系统的CAP理论。

所谓一致性既是一份文件不论在哪个云存储里,都是一样的,例如word文档,我在NAS里的文件加了标题,而WebDEV里的文件却没有更改,这样很明显是有问题的,数据的不一致会导致版本冲突,影响用户体验。

而可用性则更加直接,就是我能不能访问到存放在云存储里的文件,不可访问即不可用,这样的故障显然是不可以承受的,例如硬盘损坏也会导致数据不可用性,这时候百度云或坚果云的可用性就会比较高,基本不会出现宕机的可能性。

分区容错性,借用百科的解释:以实际效果而言,分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性,就意味着发生了分区的情况,必须就当前操作在C和A之间做出选择。我所搭建的私有云既存在这个问题,又解决了这个问题,存在是因为私有云受电源和网络的影响比较直接,很可能会宕机或连接缓慢,解决问题是NAS提供的套件可以将一份数据同步到多个云平台,这样,只要我的NAS是可用的,即所有数据便能在一定时限能达到一致。

这里我把NAS当作是节点,如果它一旦失效,分区容错便发生了,这时候我就要在CA中选择,本地和云端必然是不一致的,就需要决定哪个版本是可用的有效的。

CAP原则的精髓就是要么AP,要么CP,要么AC,但是不存在CAP。如果在某个分布式系统中数据无副本, 那么系统必然满足强一致性条件, 因为只有独一数据,不会出现数据不一致的情况,此时C和P两要素具备,但是如果系统发生了网络分区状况或者宕机,必然导致某些数据不可以访问,此时可用性条件就不能被满足,即在此情况下获得了CP系统,但是CAP不可同时满足。

当我因为数据存储而思考到这里时,便开始理解这些原则的抉择,在我这样的场景下,我会选择CP(数据一致性和分区容忍性)),而最重要的还是A可用性,保证数据此时可以使用,而一致性只是增加一些不必要的麻烦而已,即使多个云平台的数据出现不同,大不了花些时间去核对整理,最起码数据没有丢失,保证各端可用就行,以数据为核心,而分区可以等恢复之后再进行处理。

而目前都有对应的场景使用三种原则的不同组合,CA:如银行和金融业,对于涉及到钱财这样不能有一丝让步的场景,C必须保证,网络发生故障宁可停止服务,这是保证CA舍弃P。CP :如果不要求A(可用),相当于每个请求都需要在Server之间强一致,而P(分区)会导致同步时间无限延长,如此CP也是可以保证的。很多传统的数据库分布式事务都属于这种模式。AP :要高可用并允许分区,则需放弃一致性。一旦分区发生,节点之间可能会失去联系,为了高可用,每个节点只能用本地数据提供服务,而这样会导致全局数据的不一致性。现在众多的NoSQL都属于此类。

没有那种原则是最好的,只有最适合的。