1. Swift 最初是由 Rackspace 公司开发的高可用分布式对象存储服务（Object Storage Service），并于 2010 年贡献给 OpenStack 开源社区作为其最初的核心子项目之一，为其 Nova 子项目提供虚机镜像存储服务。Swift 构筑在比较便宜的标准硬件存储基础设施之上，无需采用 RAID（磁盘冗余阵列），通过在软件层面引入一致性散列技术和数据冗余性，牺牲一定程度的数据一致性来达到高可用性和可伸缩性，支持多租户模式、容器和对象读写操作，适合解决互联网的应用场景下非结构化数据存储问题。
2. Swift 包括2个组成部分，一个是代理服务（proxy）,一个是存储服务（storage）。
1. 代理服务是Swift内部存储的拓扑逻辑，即一个具体文件位于哪个存储节点的哪个区上。它同时是一个web服务器，通过http或https对外提供REST API服务。
2. 存储服务是负责文件存储的服务，由3个组件组成：account-server、container-server、object-server。其中object-server负责具体的文件存储，container-server包含到每个object的索引，account-server包含到每个container 的索引。
二、原理
1. 一致性散列（Consistent Hashing)：Swift 是基于一致性散列技术，通过计算可将对象均匀分布到虚拟空间的虚拟节点上，在增加或删除节点时可大大减少需移动的数据量；虚拟空间大小通常采用 2 的 n 次幂，便于进行高效的移位操作；然后通过独特的数据结构 Ring（环）再将虚拟节点映射到实际的物理存储设备上，完成寻址过程。
1. 平衡性：平衡性是指哈希的结果能够尽可能的分布到所有的缓冲中去，这样可以使得所有缓冲空间能够都得到利用。为了更好的满足平衡性，引入了虚拟节点概念，虚拟节点是实际节点在hash空间的复制品，一个实际节点对应若干个虚拟节点，这个对应的个数也称为复制个数，虚拟节点在hash空间以hash值排列。
2. 单调性：单调性是指如果已经有些内容通过Hash分派到相应的缓冲中，又有新的缓冲加入到系统中，哈希的结果应能够保证原有已分配的内容可以被映射到原有或者新的缓冲中区，而不会被映射到旧的或者其他缓冲区。
3. 分散性：在分布式环境中，客户端可能看不到所有的缓冲，而只能看到其中一部分。当终端希望通过哈希过程将内容映射到缓冲上时，由于不同的客户端所看到的缓冲范围可能不同，从而导致得到的Hash结果不一致，导致结果相同的内容被映射到不用的缓冲区中。这种情况应该被避免，因为这将会导致相同的内容将会被映射到不同缓冲区中，降低了系统的存储效率。
4. 负载：负载时对分散性要求的另一个维度。既然相同的内容可能被映射到不同的缓冲中去，那么对于同一个缓冲而言，就有可能被不同的用户映射不同的内容。与分散性一样，这种情况应该被避免。
5. 如图所示，以逆时针方向递增的散列空间有 4 个字节长共 32 位，整数范围是[0~232-1]；将散列结果右移 m 位，可产生 232-m个虚拟节点，例如 m=29 时可产生 8 个虚拟节点。在实际部署的时候需要经过仔细计算得到合适的虚拟节点数，以达到存储空间和工作负载之间的平衡。
2. 数据一致性模型（Consistency Model）
1. 按照 Eric Brewer 的 CAP（Consistency，Availability，Partition Tolerance）理论，无法同时满足 3 个方面，Swift 放弃严格一致性（满足 ACID 事务级别），而采用最终一致性模型（Eventual Consistency），来达到高可用性和无限水平扩展能力。为了实现这一目标，Swift 采用 Quorum 仲裁协议(Quorum 有法定投票人数的含义)：
1. 定义：N：数据的副本总数；W：写操作被确认接受的副本数量；R：读操作的副本数量
2. 强一致性：R+W>N，以保证对副本的读写操作会产生交集，从而保证可以读取到最新版本；如果 W=N，R=1，则需要全部更新，适合大量读少量写操作场景下的强一致性；如果 R=N，W=1，则只更新一个副本，通过读取全部副本来得到最新版本，适合大量写少量读场景下的强一致性。