Swift 是这两年崛起的分布式文件存储系统，分布式系统的设计都涉及一个CAP的问题，下面来了解一下:

CAP理论是由美国著名科学家，Berkerly大学Brewer教授提出的。后来麻省理工学院的两位科学家证明了CAP理论的正确性。虽然在后来近十年的时间很多人对CAP理论提出了很多异议，但是在NoSQL的世界中，它还是非常有参考价值的。CAP理论：

分布式系统中，有三种重要的属性，分别是：

l 一致性(Consistency)：任何一个读操作总是能读取到之前完成的写操作结果，也就是在分布式环境中，多点的数据是一致的。

l 可用性(Availability)：每一个操作总是能够在确定的时间内返回，也就是系统随时都是可用的。

l 分区可容忍性(Tolerance of network Partition)：在出现网络分区（比如断网）的情况下，分离的系统也能正常运行。

CAP理论的意思是，一个分布式系统不能同时满足一致性，可用性和分区容错性这三个需求，最多只能同时满足两个。

工程实践对网络分区考虑较少，一般可以认为：一致性和写操作的可用性不能同时满足，即如果要保证强一致性，那么出现机器故障的时候，写操作需要等机器重启或者机器上的服务迁移到别的机器才可以继续。

分布式系统的一致性和采用的一致性模型有关。一致性简单的可以分为强一致性、弱一致性、最终一致性；而一致性的变体大体有Causal consistency, Read-your-writes consistency, Session consistency, Monotonic read consistency, Monotonic write consistency等。这里不做赘述，只对部分做简单举例。

l 强一致性：支付业务上多采用；

l 弱一致性和最终一致性：需要等待一个“一致性窗口”的时间之后才能读取到最新值；

l session一致性：用户发表的微博，评论数据，用户可以马上看到，但是其他用户要等一段时间。

一致性模型多和业务逻辑有很大关联，不同的业务对CAP的取舍也不尽相同，这里不赘述。

Swift对CAP的支持

下图对部分SQL和NoSQL系统按照CAP做了一个归类。可以和Swift做一个参照。 

通过比较，可以认为，Swift为AP系统。

Consistency：

l Swift的一致性归为弱一致性模型。Swift由updater保证最终一致性，auditor保证存储对象的完整性。

l Swift只能保证数据的最终一致性，即，如果upload(update也是一种upload)一个object,从其他客户端GET这个object，不一定是最新的。当然，大部分情况(指网络不拥塞，没有单点故障时)，这种情况不会发生。因此，工程实践中，如果业务需要，我们可能需要加入自己的一致性策略，比如在object的metadata中记录版本信息，系统统一管理object的版本变更——但这会损失一些性能。

Availability：

l 基于python对hash的 原生支持，swift中广泛使用了hash算法。比如均衡ring中partition的分布，object  update备份策略。异步的replication操作。

l sqlite控制account/container/object的相关信息，简化了维护成本

l memcache缓存的机制。

Tolerance of network Partition：并没有网络分区。

l 牵强的说，Swift提供zone的概念，建议根据不同的故障原因分zone，以规避故障引起的风险。

l 每个storage node各自维护自己的account/container/object信息，而不是单点统一管理。

l 一致性hash使ring中的partition均匀分布，其实partition是分区域的，当然，这是从代码的角度看。

l 副本的冗余存储。