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

最后更新：2011年8月3日20:51:36

4 悬而未决的问题和几点考虑

4.1如何避免SDC？

SDC全称Silent Data Corruption。正如AMD给出的解释：“SDC occurs when incorrect data is delivered by a computing system to the user without any error being logged”，SDC发生往往不会被记录，也没有任何异常产生。

现代的文件系统在设计之初都考虑到了数据完整性检查，例如GFS、ZFS，btrfs，ext4等等。

比如普遍都会采用计算checksum(校验和)，异地存储，传输后检验的方法。

但是swift官方推荐的XFS[1][2]并没有类似的解决方法(注：待考证)，swift中也没有对数据完整性进行检查。(注：swift中的auditor只是做副本的一致性检查，而副本是否拷贝完整无从校验。)

当然，数据完整性和业务模型有一定关联，若干bit的错误数据对一些业务来说也许是可以接受的。

4.2memcache的考虑？

OpenStack Object Storage Administrator Manual中提到，默认下只有查询authtoken，container/account时会用到memcache。Manual建议其它server上也使用缓存服务。

缓存是内嵌在swift中的，这无可非议。但大并发下，swift的缓存机制可能并不能提升多少命中率。虽然hash算法均衡了负载，但也会存在一定几率的“雪崩”情况。即：缓存大面积失效，压力转向后端存储设备，最终导致后端连锁性无法响应。

实际应用中，cache层独立出来做一层缓冲，可以有效降低后端压力。类似Haystack的Haystack Cache[3]也许可以提供一些借鉴。

swift的策略规避了对缓存一致性的要求，因此这里不做考虑。

4.3replication粒度或者策略？

swift并不存在数据append(附加)的情况，因此没有[4]中“转移中提供服务”的通用问题。swift读到过期数据似乎影响不大。

但当故障发生时(网络拥塞，存储结点宕机)，需要考虑replication的粒度。即副本拷贝时，副本所在storage node有很大压力(特别是副本较大、数量多、网络不通畅时，会有很长的传输时间)。

swift中是以partition作为replication的基本单位，并限制在一定时间内(默认为一个小时)只允许移动一个partition的副本。这样的设计有基于数据安全方面的考虑，但效率可能会不高(副本大、网络拥塞时会增加数据风险，提升读出旧数据的可能性)。

可以借鉴[5]5.4节做一个折中，即在一定时长内使用单副本replication，超出时长如果仍未完成副本拷贝的，其他副本所在的partition和空闲storage node参与进来进行分流。这可能会造成一些额外的性能开销。

提高副本数也是一个不错的选择，如facebook做4*3的备份([3]4.1.2，即一份数据存12份)。

因此replication的粒度可能需要在效率、性能、成本上做平衡。

4.4 后端db的考量

gholt是swift的主要开发者之一。他提到swift源自MogileFS——一个perl实现的存储引擎。最初的设计中规避了文件的查询——但需要一种管理机制。Cassandra几乎就要作为swift object的管理策略了，但最终还是因为自身的原因而不得不放弃[6]。

sqlite现在作为swift底层备份管理的db。[7]中提到，sqlite在高并发下会有写丢失的情况，并最终转向mysql。swift现在或将来提供很多机制优化后端性能，比如sqlite的WAL([8]， write-ahead-logging journal mode)。但目前缺少有力的测试数据和实践经验。

swift中是否也会因为高并发而影响sqlite的写丢失？目前我没有能力或条件去做证实，期待巨牛之人可以解答之。

4.5部署中需要注意的事情

OpenStack Object Storage AdministratorManual4.6中已穷尽考虑，这里只提出几个相对重要的方面。

系统时间

应该统一时间，系统中要有专用的NTP服务器。时间对一些服务来说是很重要的，比如object存储的名字是object名字hash之后连接一个操作的时间戳。机群内部的时间不应该差异太大，否则，很有可能会出现一些诡异的事情。：）

多核的利用

计算机多核时代已经来临，因此需要充分利用有限的cpu资源。manual中建议proxy node设置的worker数是cpu总核数的2倍。比如双4核cpu，worker设置为16。而storage node上的服务较多，需要根据实际情况酌情考虑。

文件系统

manual中推荐使用XFS，但不推荐使用RAID。也许是swift出于简单设计的原因吧。

[3]中的三层结构有一定的借鉴意义。笔者更倾向于把文件系统单独拿出来做一层结构。自己设计一层通用fs或者使用更可靠的类GFS系统。

日志的配置

swift的日志部分从1.2之后更改较多，或者说变的更加清晰、强大。比如说可以定制输出，一些异常也不会莫名其妙的被系统吞掉。需要做线上数据分析或者数据挖掘的可以参考相关文档。

写在结尾：《swift实战基础》已写完计划部分。整理后的pdf版本在不久后会共享出来。欢迎交流指正。

这之后开始从代码层面做介绍，文章结构请参考
swift实战_纲要。

[1] Scalability in the XFS File System 96年xfs的设计论文

[2 ]http://xfs.org/index.php/Main_Pagexfs源码中也没有对数据完整性有任何考虑

[3] Finding a needle in Haystack:Facebook’s photo storage

[4] http://code.taobao.org/trac/tair/wiki/intro淘宝tail引擎的存储策略

[5] Ceph: A Scale，High-Performance Distributed FileSystem

[6] http://tlohg.com/the-story-of-swift gholt的博客，讲述swift的设计变迁

    此文章链接过期，原文发布日期为2011-4-1，现链接失效。

[7] 篱笆社区的架构变迁，《程序员》3月刊p106

[8] https://blueprints.launchpad.net/swift/+spec/cactus-sqlite-walswift设计蓝本，这里是swift未来特性的雏形