[openstack swift]3 其他相关

最新推荐文章于 2024-09-27 16:49:43 发布

zzcase

最新推荐文章于 2024-09-27 16:49:43 发布

阅读量4.3k

点赞数

分类专栏： opendoc openstack swift 文章标签：分布式存储 object nosql network sqlite upload

本文链接：https://blog.youkuaiyun.com/zzcase/article/details/6651837

版权

openstack swift 同时被 2 个专栏收录

12 篇文章

订阅专栏

opendoc

8 篇文章

订阅专栏

本文探讨了OpenStack Swift与CAP原则的关系，解释了Swift在一致性、可用性和分区容忍性方面的特点。Swift采用弱一致性模型，通过updater和auditor确保最终一致性。它是一个AP系统，注重可用性和分区容忍性，适用于微博图片、视频分享等业务场景。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

********转载请注明出处！

最后更新 ：2011年8月1日20:22:35

3.1CAP原则和swift的联系

这个idiot的小节源自淘宝网某某问我的一个问题：

“swift为什么不用RAID？swift如何保证冗余？”

当时我对CAP的理解一瓶不满半瓶晃，误以为swift是文件系统，误以为冗余就是CAP中的P，误以为swift不用RAID就没有容错机制。

这个小节只作为我对过去“无知无畏”的一种纪念，大牛们请直接跳到下一条目。

CAP原则源自Berkerly 大学Brewer教授的一次应邀讲话。有证可查的是收录在2000年7月Principles of Distributed Systems中的一篇文章Towards robust distributedsystems。（这里我并没有对原文做详实考证。）

以下摘录自文献[1]2.3节，对Brewer原文含义做的总结：

一致性(Consistency)：任何一个读操作总是能读取到之前完成的写操作结果；

可用性(Availability)：每一个操作总是能够在确定的时间内返回；

分区可容忍性(Tolerance of network Partition)：在出现网络分区的情况下，仍然能够满足一致性和可用性；

鉴于工程实践角度，文献[1]中对CAP做了修正：

一致性(Consistency)：读操作总是能读取到之前完成的写操作结果，满足这个条件的系统称为强一致系统，这里的“之前”一般对同一个客户端而言，但可能是一个客户端的多个Session；

可用性(Availability)：读写操作在单台机器发生故障的情况下仍然能够正常执行，而不需要等到机器重启或者机器上的服务分配给其它机器才能执行；

分区可容忍性(Tolerance of network Partition)：机房停电或者机房间网络故障的时候仍然能够满足一致性和可用性；

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

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

强一致性：支付业务上多采用
弱一致性和最终一致性：需要等待一个“一致性窗口”的时间之后才能读取到最新值
session一致性：用户发表的微博，评论数据，用户可以马上看到，但是其他用户要等一段时间。

一致性模型多和业务逻辑有很大关联，不同的业务对CAP的取舍也不尽相同，这里不赘述。详细请参考文献[1][2][3]。

3.1.1swift擅长的业务领域

相比来说，swift更适合应用在以下几个方面：

微博中加载的图片、视频、音频；
上传附件的存储；
facebook的图片分享;
在线视频分享，youku,YouTube之类;
*未来可能会有效应用在手机图片分享平台上，类似推图的后端etc

我比较认同于把swift归类为Blob存储系统(参见文[4])。

swift毕竟不是文件系统，她借鉴了面向对象存储，相似于Dynamo和Ceph的很多东西，比如DHT的思想，基于故障原因所做的容灾分区等，但远远没有有两者复杂的机理以形成独立的“生态系统”。swift没有POSIX接口，底层使用memcache缓存和XFS文件系统(或者其他有xattrs属性的本地fs)，管理account/container/object使用sqlite。因此swift也是一套集成的存储方案，每个部分可以从源码的角度根据自身业务进行定制。

下图源自[3]，对部分sql和nosql系统按照CAP做了一个归类。可以和swift做一个参照。

3.1.2swift中CAP的支持程度

这里谈谈我对swift中CAP的理解。

swift为AP系统

Consistency：

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

Availability：

基于python对hash的原生支持，swift中广泛使用了hash算法。比如均衡ring中partition的分布，object update备份策略。异步的replication操作。
sqlite控制account/container/object的相关信息，简化了维护成本
memcache缓存的机制。

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