Swift源码分析

一 Swift源码结构

[root@localhost swift]# tree -L 1
bin
etc
swift
├── account
├── cli
├── common
├── container
├── __init__.py
├── __init__.pyc
├── __init__.pyo
├── obj
└── proxy
setup.cfg
setup.py
test

• bin：一些启动脚本，以及工具脚本。比如swift-proxy-server负责启动proxy server，swift-ring-builder用来创建Ring。
• swift：swift的核心代码。account、container、obj、proxy几个子目录分别是Account、Container、Object、Proxy几个服务的具体实现。common子目录包含的是一些可以被多个组件共用的公共代码，比如Account、Container以及Object服务都有Ring的操作，那么这些共用的代码就存放在common目录下。
• etc：配置文件模板，包括Paste配置文件等。

二 setup.cfg

依照惯例，理解具体的实现之前，我们需要仔细浏览setup.cfg文件。

scripts =
    bin/swift-account-audit
    bin/swift-account-auditor
    bin/swift-account-info
    bin/swift-account-reaper
    bin/swift-account-replicator
    bin/swift-account-server
    bin/swift-config
    bin/swift-container-auditor
    bin/swift-container-info
    bin/swift-container-replicator
    bin/swift-container-server
    bin/swift-container-sync
    bin/swift-container-updater
    bin/swift-container-reconciler
    bin/swift-reconciler-enqueue
    bin/swift-dispersion-populate
    bin/swift-dispersion-report
    bin/swift-drive-audit
    bin/swift-form-signature
    bin/swift-get-nodes
    bin/swift-init
    bin/swift-object-auditor
    bin/swift-object-expirer
    bin/swift-object-info
    bin/swift-object-replicator
    bin/swift-object-server
    bin/swift-object-updater
    bin/swift-oldies
    bin/swift-orphans
    bin/swift-proxy-server
    bin/swift-recon
    bin/swift-recon-cron
    bin/swift-ring-builder
    bin/swift-temp-url

对于Swift来说，setup.cfg文件中值得关注的是script关键字所对应的内容，其中每一项都代表一个被安装在系统里的可执行的脚本，它们同时也是Swift各项工作的入口，完全可以作为我们理解Swift具体实现的起点。

• swift-proxy-server:代理服务（Proxy Server）进程，通常运行这个进程的服务器又被称为代理服务器。
• *-auditor：swift-account-auditor、swift-container-auditor、swift-object-auditor分别对应了Account、Container和Object的Auditor（审计）进程。
• *-updater：swift-container-updater与swift-object-updater分别对应了Container和Object的Updater进程，并不存在Account的Updater。
• *-replicator：基于Account、Container和Object存储方式不同，它们的Replicator进程又分两类：一是针对Account与Container这两种以数据库形式存在的数据，swift-account-replicator和swift-container-replicator完成的是数据库的复制；二是swift-object-replicator针对Object完成数据对象数据的复制。
• swift-account-server、swift-container-server、swift-object-server，分别对应了Account、Container、Object三种服务的进程。
• swift-account-audit：与*-auditor不同，swift-account-audit并不是一个后台服务进程，它只是一个命令行工具。可以手动地对指定的Account、Container或Object的数据进行完整性检查。指定了Container时，将递归检测该Container中的每个Object，同理，指定Account时，将递归检测该Account下的每个Container，并进一步检查每个Container下的各个Object。
• *-info：打印Account、Container和Object的内容或元数据信息。
• swift-account-reaper：Account收割器，负责清除被删除Account中所包含的数据。
• swift-container-sync：实现Container同步功能。一个Container的所有内容可以通过后台同步镜像到另外一个Container（两个Container可以在同一个集群也可以在完全不同的集群）。比如可以使用这个功能实现Account的迁移，将旧的Account中的所有Container都同步到新的Account中去，利用这个功能，数据可以在不同的云服务提供商之间迁移，而不会被锁定在一个特定的供应商，比如数据可以在不同的云服务提供商之间迁移，而不会被锁定在一个特定的供应商，比如数据可以从私有的Swift集群迁移到一个公共Swift。
• swift-container-reconciler：伴随Storage Policies（存储策略）而出现的一个后台进程，简单地说，一种Storage Policy就是一种存储的方式，比如创建2个副本或创建3个副本，swift-container-reconciler主要负责将错误Storage Policy中的对象迁移到正确的Storage Policy中去。
• swift-dispersion-report：通过检测Container和Object是不是在集群中合适位置来估计整个集群的健康状态。比如说，每个对象有3个副本，如果3个副本中只有两个在适当位置，那么这个对象的健康值就是66.66%，最佳是100%。如果我们在占集群一定百分比的Partition中（比如1%）创建足够的对象，就可以获得一个对整个集群健康度相当有效的估计。为了估计健康状态，我们所要做的第一件事情就是创建一个专门用于该工作的Account，然后，我们需要向不同的Partition中放置容器和对象。swift-dispersion-populate工具能完成这个工作，它创建随机的Container和Object直到它们落在不同的Partition里。最后，我们运行swift-dispersion-tool来进行检测。
• swift-drive-audit：经验表明，当一个设备快要出故障时，错误信息会涌入/var/log/kern.log。此时我们可以通过cron运行swift-drive-audit脚本来寻找坏掉的硬盘，并将其卸载，从而Swift能够绕开它工作。
• swift-get-nodes：如果我们希望知道对象在哪个存储节点上，可以使用这个工具。
• swift-init：启动swfit基本服务。
• swift-object-expirer：在指定时间内删除对象。当对象过期达到删除的时间时，Swift会停止向用户提供针对该对象的服务，并在短时间内把该对象删除。
• swift-oldies：可以列出运行时间很长的Swift服务进程，比如“swift-oldies –a 48”打印出已经运行超过48个小时的那些进程。
• swift-orphans：可以清除那些孤儿进程（父进程已经退出）
• swift-recon：可以用于收集一些Swift统计数据，比如Account、Container和Object的数量等。
• swift-ring-builder：用于构建Ring。