通过NAS对分布式系统CAP理论的理解
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都属于此类。
没有那种原则是最好的，只有最适合的。
