深入云存储系统Swift存储节点：存储实现分析

淩亂°似流年 2021-11-22 05:50 359阅读 0赞

# [深入云存储系统Swift存储节点：存储实现分析][Swift] #

>    原文链接：[http://www.cnblogs.com/yuxc/archive/2012/07/04/2575536.html][Swift] 
> 
>    作者：余兴超 @SAE.Sina Web Service Team
> 
>    请尊重作者辛勤劳动，转载请标注链接和作者

在[深入云存储系统Swift核心组件：Ring实现原理剖析][Swift_Ring]和[深入云存储系统Swift核心组件：Ring数据结构及构建、重平衡操作][Swift_Ring 1]两篇博文中，我们详细地分析了Swift中数据的映射机制和具体操作。那么在集群中的每一台存储节点上，Swift是如何实现Account、Container、Object的具体存储呢？本篇旨在分析Storage node与partition，partition与data间的映射关系在实际存储目录中的以何种格式存储，即怎么存，存什么。

在Storage node上运行着Linux系统并使用了XFS文件系统，逻辑上使用一致性哈希算法将固定总数的partition映射到每个Storage node上，每个Data也使用同样的哈希算法映射到Partition上，其层次结构如下图所示：

![2012070409420145.jpg][]

Figure1:Stoage node hierachy

以我们的一台storage node sws51为例，该device的文件路径挂载到/srv/node/sdc，目录结构如下所示：

> root@sws51:/srv/node/sdc\# ls
> 
> accounts  async\_pending  containers  objects  quarantined  tmp

其中accounts、containers、objects分别是账号、容器、对象的存储目录，async\_pending是异步待更新目录，quarantined是隔离目录，tmp是临时目录。

### 1.objects目录 ###

在objects目录下存放的是各个partition目录，其中每个partition目录是由若干个suffix\_path名的目录和一个hashes.pkl文件组成，suffix\_path目录下是由object的hash\_path名构成的目录，在hash\_path目录下存放了关于object的数据和元数据，object存储目录的层次结构如图2所示。

![wps\_clip\_image-16011][wps_clip_image-16011]

Figure2: Object directory hierachy

hashes.pkl是存放在每个partition中的一个2进制pickle化文件。例如：

root@sws50:/srv/node/sdc/objects/100000\# ls

8bd  hashes.pkl

In \[1\]: with open('hashes.pkl', 'rb') as fp:

...:     import pickle

...:     hashes = pickle.load(fp)

...:

In \[2\]: hashes

Out\[2\]: \{'8bd': '9e99c8eedaa3197a63f685dd92a5b4b8'\}

‘8bd’是suffix\_dir，而9e99c8eedaa3197a63f685dd92a5b4b8则是该partition下数据的md5哈希值。

Object path生成过程

object的存储路径由object server进程内部称为DiskFile类初始化时产生，过程如下：

> 1.由文件所属的account、container和object名称产生'/account/container/object'格式的字符串，和HASH\_PATH\_SUFFIX组成新的字符串，调用hash\_path函数，生成md5 hash值name\_hash。其中HASH\_PATH\_SUFFIX作为salt来增加安全性，HASH\_PATH\_SUFFIX值存放在/etc/swift/swift.conf中。
> 
> 2. 调用storage\_directory函数，传入DATADIR, partition, hash\_path参数生成DATADIR/partition/name\_path\[-3:\]/name\_path格式字符串
> 
> 3. 连结path/devcie/storage\_directory(DATADIR, partition,name\_ hash)生成数据存储路径datadir
> 
> 4. 调用normalize\_timestamp函数生成“16位.5位”的时间戳\+扩展名的格式生成对象名称

例如，某object的存储路径为：/srv/node/sdc/objects/19892/ab1/136d0ab88371e25e16663fbd2ef42ab1/1320050752.09979.data

其中每个目录分别表示：

![wps\_clip\_image-23876][wps_clip_image-23876]

Figure3: Object directory represention

### Object数据 ###

Object的数据存放在后缀为.data的文件中，它的metadata存放在以后缀为.meta的文件中，将被删除的Object以一个0字节后缀为.ts的文件存放。

### 2.accounts目录 ###

在accounts目录下存放的是各个partition，而每个partition目录是由若干个suffix\_path目录组成，suffix\_path目录下是由account的hsh名构成的目录，在hsh目录下存放了关于account的sqlite db，account存储目录的层次结构如图4所示。

![wps\_clip\_image-24231][wps_clip_image-24231]

Figure4: Account directory hierachy

### Account path生成过程 ###

account使用AccountController类来生成path，其过程与object类似，唯一的不同之处在于，account的db命名调用hash\_path(account)来生成，而不是使用时间戳的形式。例如，某account的db存储路径为：/srv/node/sdc/accounts/20443/ac8/c7a5e0f94b23b79345b6036209f9cac8/ c7a5e0f94b23b79345b6036209f9cac8.db

[![wps\_clip\_image-9097][wps_clip_image-9097]][wps_clip_image-9097_wps_clip_image-9097]

Figure5: Object directory represention

Account db数据

在account的db文件中，包含了account\_stat、container、incoming\_sync 、outgoing\_sync 4张表。

表account\_stat是记录关于account的信息，如名称、创建时间、container数统计等等，其schema如下：

CREATE TABLE account\_stat (  
                account TEXT,  
                created\_at TEXT,  
                put\_timestamp TEXT DEFAULT '0',  
                delete\_timestamp TEXT DEFAULT '0',  
                container\_count INTEGER,  
                object\_count INTEGER DEFAULT 0,  
                bytes\_used INTEGER DEFAULT 0,  
                hash TEXT default '00000000000000000000000000000000',  
                id TEXT,  
                status TEXT DEFAULT '',  
                status\_changed\_at TEXT DEFAULT '0',  
                metadata TEXT DEFAULT ''  
            );

account表示account名称，created\_at表示创建时间，put\_timestamp表示put request的时间戳，delete\_timestamp表示delete request的时间戳，container\_count为countainer的计数，object\_count为object的计数，bytes\_used表示已使用的字节数，hash表示db文件的hash值，id表示统一标识符，status表示account是否被标记为删除，status\_changed\_at表示状态修改时间，metadata表示account的元数据。

以test账号为例，该db的表account\_stat中存放了以下数据项：

![wps\_clip\_image-5299][wps_clip_image-5299]

表container记录关于container的信息，其schema如下：

CREATE TABLE container (  
                ROWID INTEGER PRIMARY KEY AUTOINCREMENT,  
                name TEXT,  
                put\_timestamp TEXT,  
                delete\_timestamp TEXT,  
                object\_count INTEGER,  
                bytes\_used INTEGER,  
                deleted INTEGER DEFAULT 0  
            );  
CREATE INDEX ix\_container\_deleted\_name ON  
                container (deleted, name);  
CREATE TRIGGER container\_delete AFTER DELETE ON container  
            BEGIN  
                UPDATE account\_stat  
                SET container\_count = container\_count - (1 - old.deleted),  
                    object\_count = object\_count - old.object\_count,  
                    bytes\_used = bytes\_used - old.bytes\_used,  
                    hash = chexor(hash, old.name,  
                                  old.put\_timestamp || '-' ||  
                                    old.delete\_timestamp || '-' ||  
                                    old.object\_count || '-' || old.bytes\_used);  
            END;  
CREATE TRIGGER container\_insert AFTER INSERT ON container  
            BEGIN  
                UPDATE account\_stat  
                SET container\_count = container\_count + (1 - new.deleted),  
                    object\_count = object\_count + new.object\_count,  
                    bytes\_used = bytes\_used + new.bytes\_used,  
                    hash = chexor(hash, new.name,  
                                  new.put\_timestamp || '-' ||  
                                    new.delete\_timestamp || '-' ||  
                                    new.object\_count || '-' || new.bytes\_used);  
            END;  
CREATE TRIGGER container\_update BEFORE UPDATE ON container  
            BEGIN  
                SELECT RAISE(FAIL, 'UPDATE not allowed; DELETE and INSERT');  
            END;

其中ROWID字段表示自增的主键，name字段表示container的名称，put\_timestamp和delete\_timestamp分别表示container的put和delete的时间戳，object\_count表示container内的object数， bytes\_used  表示已使用的空间，deleted表示container是否标记为删除。

账号test的account表中的数据项如下所示：

[![wps\_clip\_image-28912][wps_clip_image-28912]][wps_clip_image-28912_wps_clip_image-28912]

表incoming\_sync记录到来的同步数据项，其schema如下：

CREATE TABLE incoming\_sync (  
                remote\_id TEXT UNIQUE,  
                sync\_point INTEGER,  
                updated\_at TEXT DEFAULT 0  
            );  
CREATE TRIGGER incoming\_sync\_insert AFTER INSERT ON incoming\_sync  
            BEGIN  
                UPDATE incoming\_sync  
                SET updated\_at = STRFTIME('%s', 'NOW')  
                WHERE ROWID = new.ROWID;  
            END;  
CREATE TRIGGER incoming\_sync\_update AFTER UPDATE ON incoming\_sync  
            BEGIN  
                UPDATE incoming\_sync  
                SET updated\_at = STRFTIME('%s', 'NOW')  
                WHERE ROWID = new.ROWID;  
            END;

remote\_id字段表示远程节点的id，sync\_point字段表示上一次更新所在的行位置，updated\_at字段表示更新时间。

账号test的表incoming\_sync中的数据项如下所示：

[![wps\_clip\_image-16251][wps_clip_image-16251]][wps_clip_image-16251_wps_clip_image-16251]

表outgoing\_sync表示推送出的同步数据项，其schema如下：

CREATE TABLE outgoing\_sync (  
                remote\_id TEXT UNIQUE,  
                sync\_point INTEGER,  
                updated\_at TEXT DEFAULT 0  
            );  
CREATE TRIGGER outgoing\_sync\_insert AFTER INSERT ON outgoing\_sync  
            BEGIN  
                UPDATE outgoing\_sync  
                SET updated\_at = STRFTIME('%s', 'NOW')  
                WHERE ROWID = new.ROWID;  
            END;  
CREATE TRIGGER outgoing\_sync\_update AFTER UPDATE ON outgoing\_sync  
            BEGIN  
                UPDATE outgoing\_sync  
                SET updated\_at = STRFTIME('%s', 'NOW')  
                WHERE ROWID = new.ROWID;  
            END;

remote\_id字段表示远程节点的id，sync\_point字段表示上一次更新所在的行位置，updated\_at字段表示更新时间。

账号test的表remote\_id中的数据项如下所示：

[![wps\_clip\_image-4803][wps_clip_image-4803]][wps_clip_image-4803_wps_clip_image-4803]

3.Container目录

Container目录结构和生成过程与Account类似，Containerdb中共有5张表，其中incoming\_sync和outgoing\_sync的schema与Account中的相同。其他3张表分别为container\_stat、object、sqlite\_sequence。

表container\_stat与表account\_stat相似，其区别是container\_stat存放的是关于container信息：

CREATE TABLE container\_stat (  
                account TEXT,  
                container TEXT,  
                created\_at TEXT,  
                put\_timestamp TEXT DEFAULT '0',  
                delete\_timestamp TEXT DEFAULT '0',  
                object\_count INTEGER,  
                bytes\_used INTEGER,  
                reported\_put\_timestamp TEXT DEFAULT '0',  
                reported\_delete\_timestamp TEXT DEFAULT '0',  
                reported\_object\_count INTEGER DEFAULT 0,  
                reported\_bytes\_used INTEGER DEFAULT 0,  
                hash TEXT default '00000000000000000000000000000000',  
                id TEXT,  
                status TEXT DEFAULT '',  
                status\_changed\_at TEXT DEFAULT '0',  
                metadata TEXT DEFAULT '',  
                x\_container\_sync\_point1 INTEGER DEFAULT -1,  
                x\_container\_sync\_point2 INTEGER DEFAULT -1  
            );

其中account字段表示container所示的account，container字段表示container名称，created\_at表示创建时间，put\_timestamp表示put request的时间戳，delete\_timestamp表示delete request的时间戳，object\_count表示object计数，bytes\_used表示使用空间，hash表示db文件的哈希值, reported\_put\_timestamp, reported\_delete\_timestamp, reported\_object\_count, reported\_bytes\_used表示reported的状态信息，id表示统一标识符，status表示container状态，status\_changed\_at表示更改时间，metadata表示container的元数据，x\_container\_sync\_point1表示同步点1，x\_container\_sync\_point2表示同步点2.

以名称为test的container db为例，其中的表container\_stat数据项如下:

[![wps\_clip\_image-25120][wps_clip_image-25120]][wps_clip_image-25120_wps_clip_image-25120]

表object的schema如下：

CREATE TABLE object (  
                ROWID INTEGER PRIMARY KEY AUTOINCREMENT,  
                name TEXT,  
                created\_at TEXT,  
                size INTEGER,  
                content\_type TEXT,  
                etag TEXT,  
                deleted INTEGER DEFAULT 0  
            );  
CREATE INDEX ix\_object\_deleted\_name ON object (deleted, name);  
CREATE TRIGGER object\_delete AFTER DELETE ON object  
            BEGIN  
                UPDATE container\_stat  
                SET object\_count = object\_count - (1 - old.deleted),  
                    bytes\_used = bytes\_used - old.size,  
                    hash = chexor(hash, old.name, old.created\_at);  
            END;  
CREATE TRIGGER object\_insert AFTER INSERT ON object  
            BEGIN  
                UPDATE container\_stat  
                SET object\_count = object\_count + (1 - new.deleted),  
                    bytes\_used = bytes\_used + new.size,  
                    hash = chexor(hash, new.name, new.created\_at);  
            END;  
CREATE TRIGGER object\_update BEFORE UPDATE ON object  
            BEGIN  
                SELECT RAISE(FAIL, 'UPDATE not allowed; DELETE and INSERT');  
            END;

test container db的表object数据项如下所示：

[![wps\_clip\_image-18073][wps_clip_image-18073]][wps_clip_image-18073_wps_clip_image-18073]

4. tmp目录

tmp目录作为account/container/object server向partition目录内写入数据前的临时目录。

例如，在client向服务端上传某一文件，object server调用DiskFile类的mkstemp方法在创建路径为path/device/tmp的目录。在数据上传完成之后，调用put()方法，将数据移动到相应路径。

5. async\_pending目录

本地server在与remote server建立http连接或者发送数据时超时导致更新失败时，将把文件放入async\_pending目录。这种情况经常发生在系统故障或者是高负荷的情况下。如果更新失败，本次更新被加入队列，然后由Updater继续处理这些失败的更新工作。例如，假设一个container server处于负荷下，此时一个新的对象被加入到系统。当Proxy成功地响应Client的请求时，这个对象将变为直接可访问的。但是container服务器并没有更新对象列表，本次更新将进入队列等待延后的更新。所以，container列表不可能马上就包含这个新对象。随后Updater使用object\_sweep扫描device上的async pendings目录，遍历每一个prefix目录并执行升级。一旦完成升级，则移除pending目录下的文件(实际上，是通过调用renamer函数将文件移动到object相应的目录下)。

为了验证以上过程，通过执行一个并发上传1000个文件的脚本，观察sws50的async\_pending目录下的所发生的变化。async\_pending的路径为/srv/node/sdc/async\_pending/，在执行脚本前，该目录下为空。脚本执行完毕后，async\_pending目录下产生了一些prefix目录，cd到一个prefix为cb9的目录中，观察其中的数据：

root@sws50:/srv/node/sdc/async\_pending/cb9\# ll

total 24

\-rw------- 1 swift swift 324 2011-11-08 10:15 69a5ee25ea7a4a4b08ea47102930fcb9-1320718532.01864

\-rw------- 1 swift swift 324 2011-11-08 10:15 69a5ee25ea7a4a4b08ea47102930fcb9-1320718537.04863

\-rw------- 1 swift swift 324 2011-11-08 10:15 69a5ee25ea7a4a4b08ea47102930fcb9-1320718543.08122

\-rw------- 1 swift swift 324 2011-11-08 10:15 69a5ee25ea7a4a4b08ea47102930fcb9-1320718550.13288

\-rw------- 1 swift swift 324 2011-11-08 10:15 69a5ee25ea7a4a4b08ea47102930fcb9-1320718558.18801

\-rw------- 1 swift swift 324 2011-11-08 10:16 69a5ee25ea7a4a4b08ea47102930fcb9-1320718567.25494

文件路径的组成如下图所示，其中数据名称是由hash\_path后面紧跟’\-‘，后面是以发送container request的header中包含的时间戳所产生：

[![wps\_clip\_image-22259][wps_clip_image-22259]][wps_clip_image-22259_wps_clip_image-22259]

Figure6:  async\_pendingdirectory represention

2分钟之后，查看该目录下的文件，仅剩下一个文件：

> root@sws50:/srv/node/sdc/async\_pending/cb9\# ll
> 
> total 4
> 
> \-rw------- 1 swift swift 356 2011-11-08 10:18 69a5ee25ea7a4a4b08ea47102930fcb9-1320718567.25494

最后，async\_pending目录变为空。

account和container的db pending文件并不会独立地存在于async\_pending目录下，它们的pending文件会与其db文件在一个目录下存放。例如：

某container的db文件为b8e7f40f8c2012d17aca4e0483d391d0.db，其pending文件为b8e7f40f8c2012d17aca4e0483d391d0.db.pending，一起存放在suffix目录1d0下。

再次执行测试脚本观察1d0目录下的变化，执行前pending文件的大小为0kb，执行过程中，pending的大小慢慢增加到12kb左右，接着又缓慢下降直到0kb。读取此过程某一时刻的pending文件。

其中内容如下所示：

> ':gAIoVQM3MzVxAVUQMTMyMTE4NjczMy4yNTQ0N3ECSgBwAQBVGGFwcGxpY2F0aW9uL29jdGV0LXN0
> 
> \\ncmVhbXEDVSBkYmQzZjhmYjQ1ZmQyZjBkZGZmNTA1ODZkNWU0ZGY3ZnEESwB0Lg==\\n:gAIoVQM3Mzh
> 
> xAVUQMTMyMTE4NjczMy41MjM4MXECTQDcVRhhcHBsaWNhdGlvbi9vY3RldC1zdHJl\\nYW1xA1UgOGI3YzR
> 
> iZGVlYzNkZGU4ZDI5OWU1Yzk1ZmE1N2ExZWVxBEsAdC4=\\n:gAIoVQM3MzlxAVUQMTMyMTE4NjczMy42M
> 
> zg0NnECTQCgVRhhcHBsaWNhdGlvbi9vY3RldC1zdHJl\\nYW1xA1UgMmQ1ZDlhYjk0MzlkMTNiMmZhODhiZmF
> 
> mNTk3NTRkMjZxBEsAdC4=\\n:g..........................................AIoVQM3NDdxAVUQMTM
> 
> yMTE4NjczNC40MzIxNnECSgBoAQBVGGFwcGxpY2F0aW9uL29jdGV0LXN0\\ncmVhbXEDVSBjYTgzNmZhY2Fh
> 
> MzY0MGQwNDc4YTU5OGQzZmUzYmRiNHEESwB0Lg==\\n:gAIoVQM3NDlxAVUQMTMyMTE4NjczNC42MzA
> 
> 1NXECTQCUVRhhcHBsaWNhdGlvbi9vY3RldC1zdHJl\\nYW1xA1UgY2Y5NWU3MDIxNWEzOTFlNzcwZDBkODB
> 
> jZjlhN2Q5OTlxBEsAdC4=\\n:gAIoVQM3NTBxAVUQMTMyMTE4NjczNC43NTA2MXECSgAoAQBVGGFwcGxpY2
> 
> F0aW9uL29jdGV0LXN0\\ncmVhbXEDVSAyYzU4Zjc3ZGIwMGUxMTgxNjZmNjg2Zjc0YzlmZmNjZHEESwB0Lg==\\n'

使用’:’对以上字符串进行分割成list，我们得到第一个非空元素

> y\[1\]：'gAIoVQM3MzVxAVUQMTMyMTE4NjczMy4yNTQ0N3ECSgBwAQBVGG
> 
> FwcGxpY2F0aW9uL29jdGV0LXN0\\ncmVhbXEDVSBkYmQzZjhmYjQ1ZmQyZjBk
> 
> ZGZmNTA1ODZkNWU0ZGY3ZnEESwB0Lg==\\n'

使用pickle模块对其进行解码pickle.loads(y\[1\].decode('base64'))，获得一个dict类型的数据：

name, timestamp, size, content\_type, etag,deleted=

('735',

'1321186733.25447',

94208,

'application/octet-stream',

'dbd3f8fb45fd2f0ddff50586d5e4df7f',

表示一个名称为’735’，大小为94208B，md5哈希值为dbd3f8fb45fd2f0ddff50586d5e4df7f，可访问的字节流文件。此过程由ContainerBroker类的\_commit\_puts方法完成，随后使用put\_object方法把这些数据项放入container db的object表中，.pending文件中的数据类型与object表中的字段定义一致。

从account与container的db和object两者的pending文件处理方式中发现其不同之处在于，db的pending文件在更新完其中的一项数据之后，删除pending文件中的相应的数据项，而object的数据在更新完成之后，移动pending文件到目标目录。

6. quarantined目录

Auditor进程会在本地服务器上每隔一段时间就扫面一次磁盘来检测account、container、object的完整性。一旦发现不完整的数据，该文件就会被隔离，该目录就称为quarantined目录。为了限制Auditor消耗过多的系统资源，其默

认扫描间隔是30秒，每秒最大的扫描文件数为20，最高速率为10Mb/s。

obj auditor使用AuditorWorker类的object\_audit方法来检查文件的完整性，该方法封装了obj server的DiskFile类，该类有一个\_handle\_close\_quarantine方法，用来检测文件是否需要被隔离，如果发现损坏，则直接将文件移动到隔离目录下。随后replicator从其他replica那拷贝新的文件来替换，最后Server计算文件的hash值是否正确。整个处理流程如下所示：

[![image][]][image 1]

Figure7: quarantined object处理流程

为了验证auditor的有效性，做一个简单的测试，在路径为srv/4/node/sdb4/objects/210/82c/003499609ba80372d62aa39a9f9a482c/1321186693.02822.data的文件中随意写入了一串字符。约过了10秒之后，发现sdb4/目录下建立了一个quarantined目录，其中包含object目录，里面损坏了的文件，其路径为/srv/4/node/sdb4/quarantined/objects/003499609ba80372d62aa39a9f9a482c/1321186693.02822.data。此时，打开原目录下的文件，已恢复为修改前的状态。

account使用AccountAuditor类的account\_audit方法，container使用ContainerAuditor类的container\_audit方法对目录下的db文件进行检查。然而，我在测试时，对container目录下的某db文件进行了修改，大约经过了数分钟后，该db文件才被隔离。在阅读源代码时，发现account和container的auditor的扫面间隔与object差异较大。在类初始化时设置了一个interval的变量，默认为1800s，然后在run\_forever中传入该参数到random函数来设置休眠时间，每次执行的间隔在180~1800s之间，也就是3到30分钟。设置较长间隔的原因，我认为主要是由于每次检查db文件前，需要锁住db文件，如果检查的频率过于频繁会影响存储节点的db正常的读写性能。

总结

存储结点上的各路径由不同的进程产生和维护，Accounts目录存放了关于account的信息，主要记录account下的container信息，Containes目录存放了关于 container的信息，主要记录了该container下的object信息，Objects目录则是存放了文件的数据和元数据，tmp目录用于数据写入以上目录前的临时目录， async\_pending存放未能及时更新而被加入更新队列的数据，quaraninued路径用于隔离发生损坏的数据。

[Swift]: http://www.cnblogs.com/yuxc/archive/2012/07/04/2575536.html
[Swift_Ring]: http://www.cnblogs.com/yuxc/archive/2012/06/22/2558312.html
[Swift_Ring 1]: http://www.cnblogs.com/yuxc/archive/2012/06/28/2568584.html
[2012070409420145.jpg]: /images/20211122/6c8b508cfcfa4aa88e90c69ada2fdb9c.png
[wps_clip_image-16011]: /images/20211122/74e398745db040d7918cff509a8c9bce.png
[wps_clip_image-23876]: /images/20211122/75174864fb7040348ff99533213cbd1d.png
[wps_clip_image-24231]: /images/20211122/9e365837bf1f4a178bf366a45edd4578.png
[wps_clip_image-9097]: http://images.cnblogs.com/cnblogs_com/yuxc/201207/201207040058394562.png
[wps_clip_image-9097_wps_clip_image-9097]: /images/20211122/ef64d588365848c1a6dd59e1dabb9a75.png
[wps_clip_image-5299]: /images/20211122/1163b289f80740dca56585161aa32dd1.png
[wps_clip_image-28912]: http://images.cnblogs.com/cnblogs_com/yuxc/201207/201207040058412727.png
[wps_clip_image-28912_wps_clip_image-28912]: /images/20211122/a0604785c8b94a0fa5c9430a6bd7a539.png
[wps_clip_image-16251]: http://images.cnblogs.com/cnblogs_com/yuxc/201207/201207040058422379.png
[wps_clip_image-16251_wps_clip_image-16251]: /images/20211122/a626e1902eb4488c8928bdc9e2e13c0d.png
[wps_clip_image-4803]: http://images.cnblogs.com/cnblogs_com/yuxc/201207/201207040058424854.png
[wps_clip_image-4803_wps_clip_image-4803]: /images/20211122/8807f7a84e3b46718e783d1784329d86.png
[wps_clip_image-25120]: http://images.cnblogs.com/cnblogs_com/yuxc/201207/201207040058432214.png
[wps_clip_image-25120_wps_clip_image-25120]: /images/20211122/d470a1895be642dba692ca6c364d5c3c.png
[wps_clip_image-18073]: http://images.cnblogs.com/cnblogs_com/yuxc/201207/201207040058435004.png
[wps_clip_image-18073_wps_clip_image-18073]: /images/20211122/cf935f11d73e4f708f302e8639ec2521.png
[wps_clip_image-22259]: http://images.cnblogs.com/cnblogs_com/yuxc/201207/201207040058441068.png
[wps_clip_image-22259_wps_clip_image-22259]: /images/20211122/5ebb898c44374e9fb0666ed98c94ad4e.png
[image]: /images/20211122/520a4d17f94b46d28a531dc4c031794a.png
[image 1]: http://images.cnblogs.com/cnblogs_com/yuxc/201207/201207040058444099.png