标签 Google 下的文章

Golang技术幻灯片的查看方法

随着go 1.5的发布,golang在世界各地日益受到欢迎,golang技术鼓吹者在世界各地举办各种级别的技术会议(从GopherCon大会到小小的meetup),并在会议上分享自己的技术心得和技术想法。

Golang相关的技术幻灯片有多种格式,以.ppt, .pdf和.slide为主。ppt、pdf自然不必多说,需要直接下载查看。

.slide是随着golang诞生而出现的一种present格式,Go核心开发成员似乎十分喜欢以这种格式分享Go语言。在Golang官方,几乎所有技术会议的talk幻灯片均是以.slide形式提供的。

.slide文件通过web服务查看,目前似乎尚无本地工具可以render slide文件。

目前已知的render .slide文件的服务包括:
- talks.golang.org
- go-talks.appspot.com

talks.golang.org是golang官方的服务,用于查看Go core team发表的各次技术演讲的幻灯片资料,按年份归档。

其他Go开发者用.slide形式编写的文件可以放在自己的github.com repo中,并使用go-talks.appspot.com这个第三方服务render。

比如:Dave Cheney将自己的performance-without-the-event-loop.slide存放在 github.com/davecheney/presentations下,那我们就可以通过如下url查看该slide render后的形式:

http://go-talks.appspot.com/github.com/davecheney/presentations/performance-without-the-event-loop.slide

不过由于appspot.com是Go appengine托管服务,国内无法访问,因此前期搭建了一个go-talks的镜像go-talks.tonybai.com,国内程序员可以无需fanqiang就可以访问(由于go-talks.tonybai.com托管主机内存不大,常常出现超时甚至crash现象,望谅解)。

因此要想看到上述slide,可以访问:

http://go-talks.tonybai.com/github.com/davecheney/presentations/performance-without-the-event-loop.slide

对于talks.golang.org上的slide,比如:

http://talks.golang.org/2015/gogo.slide

如果无法fanqiang又如何访问呢?这样行么?

http://go-talks.tonybai.com/talks.golang.org/2015/gogo.slide

结果告诉我们这样是不行的。那如何访问呢?

好在talks.golang.org上的slide都放在了github.com上,repo为https://github.com/golang/talks,上述那个gogo.slide,我们可以通过:

http://go-talks.tonybai.com/github.com/github.com/golang/talks/2015/gogo.slide访问。

补充

“相濡以沫”网友在评论中给出了一种在本地查看.slide的方法:

1、go get -u golang.org/x/tools/cmd/present //需翻墙
2、go install golang.org/x/tools/cmd/present,将present可执行程序放入$GOBIN或$GOPATH/bin中
3、下载你要查看的.slide,比如go get github.com/golang/talks,cd到talks所在目录,执行./present,你会看到如下结果:

$present
2015/08/23 19:34:51 Open your web browser and visit http://127.0.0.1:3999

打开浏览器,如果要查看当前目录下的2015/tricks.slide,则在浏览器里输入:http://127.0.0.1:3999/2015/tricks.slide即可查看该.slide文件。

weed-fs使用简介

weed-fs,全名Seaweed-fs,是一种用golang实现的简单且高可用的分布式文件系统。该系统的目标有二:

- 存储billions of files
- serve the files fast

weed-fs起初是为了搞一个基于Fackbook的Haystack论文的实现,Haystack旨在优化Fackbook内部图片存储和获取。后在这个基 础上,weed-fs作者又增加了若干feature,形成了目前的weed-fs。

这里并不打算深入分析weed-fs源码,仅仅是从黑盒角度介绍weed-fs的使用,发掘weed-fs的功能、长处和不足。

一、weed-fs集群简介

weed-fs集群的拓扑(Topology)由DataCenter、Rack(机架)、Machine(或叫Node)组成。最初版本的weed-fs应该可以通 过配置文件来描述整个集群的拓扑结构,配置文件采用xml格式,官方给出的样例如下:

<Configuration>
  <Topology>
    <DataCenter name="dc1">
      <Rack name="rack1">
        <Ip>192.168.1.1</Ip>
      </Rack>
    </DataCenter>
    <DataCenter name="dc2">
      <Rack name="rack1">
        <Ip>192.168.1.2</Ip>
      </Rack>
      <Rack name="rack2">
        <Ip>192.168.1.3</Ip>
        <Ip>192.168.1.4</Ip>
      </Rack>
    </DataCenter>
  </Topology>
</Configuration>

但目前的版本中,该配置文件在help说明中被置为“Deprecating!”了:

$weed master -help

-conf="/etc/weedfs/weedfs.conf": Deprecating! xml configuration file

0.70版本的weed-fs在Master中维护集群拓扑,master会根据master与master、volume与master的连接 情况实时合成拓扑结构了。

weed-fs自身可以在两种模式下运行,一种是Master,另外一种则是Volume。集群的维护以及强一致性的保证由master们保 证,master间通过raft协议实现强一致性。Volume是实际管理和存储数据的运行实例。数据的可靠性则可以通过weed-fs提供的 replication机制保证。

weed-fs提供了若干种replication策略(rack – 机架,一个逻辑上的概念):

000 no replication, just one copy
001 replicate once on the same rack
010 replicate once on a different rack in the same data center
100 replicate once on a different data center
200 replicate twice on two other different data center
110 replicate once on a different rack, and once on a different data center

选择数据更可靠的策略,则会带来一些性能上的代价,这始终是一个权衡的问题。

更多的细节以及Scaling、数据迁移等方面,下面将逐一说明。

二、weed-fs集群的启动

为了实验方便,我们定义了一个weed-fs集群拓扑:

三个master:
    master1 – localhost:9333
    master2 – localhost:9334
    master3 – localhost:9335

    replication策略:100(即在另外一个不同的datacenter中复制一份)

三个volume:
         volume1 – localhost:8081  dc1
    volume2 – localhost:8082  dc1
    volume3 – localhost:8083  dc2

集群启动首先启动master们,启动顺序: master1、master2、master3:

master1:

$ weed -v=3 master -port=9333 -mdir=./m1 -peers=localhost:9333,localhost:9334,localhost:9335 -defaultReplication=100
I0820 14:37:17 07606 file_util.go:20] Folder ./m1 Permission: -rwxrwxr-x
I0820 14:37:17 07606 topology.go:86] Using default configurations.
I0820 14:37:17 07606 master_server.go:59] Volume Size Limit is 30000 MB
I0820 14:37:17 07606 master.go:69] Start Seaweed Master 0.70 beta at 0.0.0.0:9333
I0820 14:37:17 07606 raft_server.go:50] Starting RaftServer with IP:localhost:9333:
I0820 14:37:17 07606 raft_server.go:74] Joining cluster: localhost:9333,localhost:9334,localhost:9335
I0820 14:37:17 07606 raft_server.go:134] Attempting to connect to: http://localhost:9334/cluster/join
I0820 14:37:17 07606 raft_server.go:139] Post returned error:  Post http://localhost:9334/cluster/join: dial tcp 127.0.0.1:9334: connection refused
I0820 14:37:17 07606 raft_server.go:134] Attempting to connect to: http://localhost:9335/cluster/join
I0820 14:37:17 07606 raft_server.go:139] Post returned error:  Post http://localhost:9335/cluster/join: dial tcp 127.0.0.1:9335: connection refused
I0820 14:37:17 07606 raft_server.go:78] No existing server found. Starting as leader in the new cluster.
I0820 14:37:17 07606 master_server.go:93] [ localhost:9333 ] I am the leader!

I0820 14:37:52 07606 raft_server_handlers.go:16] Processing incoming join. Current Leader localhost:9333 Self localhost:9333 Peers map[]
I0820 14:37:52 07606 raft_server_handlers.go:20] Command:{"name":"localhost:9334","connectionString":"http://localhost:9334"}
I0820 14:37:52 07606 raft_server_handlers.go:27] join command from Name localhost:9334 Connection http://localhost:9334

I0820 14:38:02 07606 raft_server_handlers.go:16] Processing incoming join. Current Leader localhost:9333 Self localhost:9333 Peers map[localhost:9334:0xc20800f730]
I0820 14:38:02 07606 raft_server_handlers.go:20] Command:{"name":"localhost:9335","connectionString":"http://localhost:9335"}
I0820 14:38:02 07606 raft_server_handlers.go:27] join command from Name localhost:9335 Connection http://localhost:9335

master2:

$ weed -v=3 master -port=9334 -mdir=./m2 -peers=localhost:9333,localhost:9334,localhost:9335 -defaultReplication=100
I0820 14:37:52 07616 file_util.go:20] Folder ./m2 Permission: -rwxrwxr-x
I0820 14:37:52 07616 topology.go:86] Using default configurations.
I0820 14:37:52 07616 master_server.go:59] Volume Size Limit is 30000 MB
I0820 14:37:52 07616 master.go:69] Start Seaweed Master 0.70 beta at 0.0.0.0:9334
I0820 14:37:52 07616 raft_server.go:50] Starting RaftServer with IP:localhost:9334:
I0820 14:37:52 07616 raft_server.go:74] Joining cluster: localhost:9333,localhost:9334,localhost:9335
I0820 14:37:52 07616 raft_server.go:134] Attempting to connect to: http://localhost:9333/cluster/join
I0820 14:37:52 07616 raft_server.go:179] Post returned status:  200

master3:

$ weed -v=3 master -port=9335 -mdir=./m3 -peers=localhost:9333,localhost:9334,localhost:9335 -defaultReplication=100
I0820 14:38:02 07626 file_util.go:20] Folder ./m3 Permission: -rwxrwxr-x
I0820 14:38:02 07626 topology.go:86] Using default configurations.
I0820 14:38:02 07626 master_server.go:59] Volume Size Limit is 30000 MB
I0820 14:38:02 07626 master.go:69] Start Seaweed Master 0.70 beta at 0.0.0.0:9335
I0820 14:38:02 07626 raft_server.go:50] Starting RaftServer with IP:localhost:9335:
I0820 14:38:02 07626 raft_server.go:74] Joining cluster: localhost:9333,localhost:9334,localhost:9335
I0820 14:38:02 07626 raft_server.go:134] Attempting to connect to: http://localhost:9333/cluster/join
I0820 14:38:03 07626 raft_server.go:179] Post returned status:  200

master1启动后,发现其他两个peer master尚未启动,于是将自己选为leader。master2、master3启动后,加入到以master1为leader的 master集群。

接下来我们来启动volume servers:

volume1:

$ weed -v=3 volume -port=8081 -dir=./v1 -mserver=localhost:9333 -dataCenter=dc1
I0820 14:44:29 07642 file_util.go:20] Folder ./v1 Permission: -rwxrwxr-x
I0820 14:44:29 07642 store.go:225] Store started on dir: ./v1 with 0 volumes max 7
I0820 14:44:29 07642 volume.go:136] Start Seaweed volume server 0.70 beta at 0.0.0.0:8081
I0820 14:44:29 07642 volume_server.go:70] Volume server bootstraps with master localhost:9333
I0820 14:44:29 07642 list_masters.go:18] list masters result :{"IsLeader":true,"Leader":"localhost:9333","Peers":["localhost:9334","localhost:9335"]}
I0820 14:44:29 07642 store.go:65] current master nodes is nodes:[localhost:9334 localhost:9335 localhost:9333 localhost:9333], lastNode:3

volume server的启动大致相同,volume2和volume3的输出日志这里就不详细列出了。

volume2:

$weed -v=3 volume -port=8082 -dir=./v2 -mserver=localhost:9334 -dataCenter=dc1

volume3:

$weed -v=3 volume -port=8083 -dir=./v3 -mserver=localhost:9335 -dataCenter=dc2

三个volume server启动后,我们在leader master(9333)上能看到如下日志:

I0820 14:44:29 07606 node.go:208] topo adds child dc1
I0820 14:44:29 07606 node.go:208] topo:dc1 adds child DefaultRack
I0820 14:44:29 07606 node.go:208] topo:dc1:DefaultRack adds child 127.0.0.1:8081
I0820 14:47:09 07606 node.go:208] topo:dc1:DefaultRack adds child 127.0.0.1:8082
I0820 14:47:21 07606 node.go:208] topo adds child dc2
I0820 14:47:21 07606 node.go:208] topo:dc2 adds child DefaultRack
I0820 14:47:21 07606 node.go:208] topo:dc2:DefaultRack adds child 127.0.0.1:8083

至此,整个weed-fs集群已经启动了。初始启动后的master会在-mdir下建立一些目录和文件:

$ ls m1
conf  log  snapshot

但volume在-dir下没有做任何操作,volume server会在第一次写入数据时建立相应的.idx文件和.dat文件。

三、基本操作:存储、获取和删除文件

创建一个hello.txt文件,内容为"hello weed-fs!",用于我们测试weed-fs的基本操作。weed-fs提供了HTTP REST API接口,我们可以很方便的使用其基本功能(这里客户端使用curl)。

1、存储

我们来将hello.txt文件存储在weed-fs文件系统中,我们通过master提供的submit API接口来完成这一操作:

$ curl -F file=@hello.txt http://localhost:9333/submit
{"fid":"6,01fc4a422c","fileName":"hello.txt","fileUrl":"127.0.0.1:8082/6,01fc4a422c","size":39}

我们看到master给我们返回了一行json数据,其中:

fid是一个逗号分隔的字符串,按照repository中文档的说明,这个字符串应该由volume id, key uint64和cookie code构成。其中逗号前面的6就是volume id, 01fc4a422c则是key和cookie组成的串。fid是文件hello.txt在集群中的唯一ID。后续查看、获取以及删除该文件数据都需要使 用这个fid。

fileUrl是该文件在weed-fs中的一个访问地址(非唯一哦),这里是127.0.0.1:8082/6,01fc4a422c,可以看出weed-fs在volume server2上存储了一份hello.txt的数据。

这一存储操作引发了物理volume的创建,我们可以看到volume server的-dir下发生了变化,多了很多.idx和.dat文 件:

$ ls v1 v2 v3
v1:
3.dat  3.idx  4.dat  4.idx  5.dat  5.idx

v2:
1.dat  1.idx  2.dat  2.idx  6.dat  6.idx

v3:
1.dat  1.idx  2.dat  2.idx  3.dat  3.idx  4.dat  4.idx  5.dat  5.idx  6.dat  6.idx

并且这个创建过程是在master leader的控制之下的:

I0820 15:06:02 07606 volume_growth.go:204] Created Volume 3 on topo:dc1:DefaultRack:127.0.0.1:8081
I0820 15:06:02 07606 volume_growth.go:204] Created Volume 3 on topo:dc2:DefaultRack:127.0.0.1:8083

我们从文件的size可以看出,hello.txt文件被存储在了v2和v3下的id为6的卷(6.dat和6.idx)中:

v2:
-rw-r–r– 1 tonybai tonybai  104  8月20 15:06 6.dat
-rw-r–r– 1 tonybai tonybai   16  8月20 15:06 6.idx

v3:
-rw-r–r– 1 tonybai tonybai  104  8月20 15:06 6.dat
-rw-r–r– 1 tonybai tonybai   16  8月20 15:06 6.idx

v2和v3中的6.dat是一模一样的,6.idx也是一样的(后续在做数据迁移时,这点极其重要)。

2、获取

前面提到master给我们返回了一个fid:6,01fc4a422c以及fileUrl":"127.0.0.1:8082/6,01fc4a422c"。

通过这个fileUrl,我们可以获取到hello.txt的数据:

$ curl http://127.0.0.1:8082/6,01fc4a422c
hello weed-fs!

根据我们的replication策略,hello.txt应该还存储在v3下,我们换成8083这个volume,应该也可以得到 hello.txt数据:

$ curl http://127.0.0.1:8083/6,01fc4a422c
hello weed-fs!

如果我们通过volume1 (8081)查,应该得不到数据:

$ curl http://127.0.0.1:8081/6,01fc4a422c
<a href="http://127.0.0.1:8082/6,01fc4a422c">Moved Permanently</a>.

这里似乎是重定向了。我们给curl加上重定向处理选项再试一次:

$ curl -L  http://127.0.0.1:8081/6,01fc4a422c
hello weed-fs!

居然也能得到相应数据,从volume1的日志来看,volume1也能获取到hello.txt的正确地址,并将返回重定向请求,这样curl 就能从正确的machine上获取数据了。

如果我们通过master来获取hello.txt数据,会是什么结果呢?

$ curl -L  http://127.0.0.1:9335/6,01fc4a422c
hello weed-fs!

同样master返回重定向地址,curl从volume节点获取到正确数据。我们看看master是如何返回重定向地址的?

$ curl   http://127.0.0.1:9335/6,01fc4a422c
<a href="http://127.0.0.1:8082/6,01fc4a422c">Moved Permanently</a>.
$ curl   http://127.0.0.1:9335/6,01fc4a422c
<a href="http://127.0.0.1:8083/6,01fc4a422c">Moved Permanently</a>.

可以看到master会自动均衡负载,轮询式的返回8082和8083。0.70版本以前,通过非leader master是无法得到正确结果的,只能通过leader master得到,0.70版本fix了这个问题。

3、删除

通过fileUrl地址直接删除hello.txt:

$ curl -X DELETE http://127.0.0.1:8082/6,01fc4a422c
{"size":39}

操作成功后,我们再来get一下hello.txt:

$ curl -i  http://127.0.0.1:8082/6,01fc4a422c
HTTP/1.1 404 Not Found
Date: Thu, 20 Aug 2015 08:13:28 GMT
Content-Length: 0
Content-Type: text/plain; charset=utf-8

$ curl -i -L  http://127.0.0.1:9335/6,01fc4a422c
HTTP/1.1 301 Moved Permanently
Content-Length: 69
Content-Type: text/html; charset=utf-8
Date: Thu, 20 Aug 2015 08:13:56 GMT
Location: http://127.0.0.1:8082/6,01fc4a422c

HTTP/1.1 404 Not Found
Date: Thu, 20 Aug 2015 08:13:56 GMT
Content-Length: 0
Content-Type: text/plain; charset=utf-8

可以看出,无论是直接通过volume还是间接通过master都无法获取到hello.txt了,hello.txt被成功删除了。

不过删除hello.txt后,volume server下的数据文件的size却并没有随之减小,别担心,这就是weed-fs的处理方法,这些数据删除后遗留下来的空洞需要手工清除(对数据文件 进行手工紧缩):

$ curl "http://localhost:9335/vol/vacuum"
{"Topology":{"DataCenters":[{"Free":8,"Id":"dc1","Max":14,"Racks":[{"DataNodes":[{"Free":4,"Max":7,"PublicUrl":"127.0.0.1:8081","Url":"127.0.0.1:8081","Volumes":3},{"Free":4,"Max":7,"PublicUrl":"127.0.0.1:8082","Url":"127.0.0.1:8082","Volumes":3}],”Free”:8,”Id”:”DefaultRack”,”Max”:14}]},{“Free”:1,”Id”:”dc2″,”Max”:7,”Racks”:[{"DataNodes":[{"Free":1,"Max":7,"PublicUrl":"127.0.0.1:8083","Url":"127.0.0.1:8083","Volumes":6}],”Free”:1,”Id”:”DefaultRack”,”Max”:7}]}],”Free”:9,”Max”:21,”layouts”:[{"collection":"","replication":"100","ttl":"","writables":[1,2,3,4,5,6]}]},"Version":"0.70 beta"}

紧缩后,你再查看v1, v2, v3下的文件size,真的变小了。

四、一致性(consistency)

在分布式系统中,“一致性”是永恒的难题。weed-fs支持replication,其多副本的数据一致性需要保证。

weed-fs理论上采用了是一种“强一致性”的策略,即:

存储文件时,当多个副本都存储成功后,才会返回成功;任何一个副本存储失败,此次存储操作则返回失败。
删除文件时,当所有副本都删除成功后,才返回成功;任何一个副本删除失败,则此次删除操作返回失败。

我们来验证一下weed-fs是否做到了以上两点:

1、存储的一致性保证

我们先将volume3停掉(即dc2),这样在replication 策略为100时,向weed-fs存储hello.txt时会发生如下结果:

$ curl -F file=@hello.txt http://localhost:9333/submit
{"error":"Cannot grow volume group! Not enough data node found!"}

master根据100策略,需要在dc2选择一个volume存储hello.txt的副本,但dc2所有machine都down掉了,因此 没有存储空间,于是master认为此次操作无法继续进行,返回失败。这点符合存储一致性的要求。

2、删除的一致性保证

恢复dc2,将hello.txt存入:

$ curl -F file=@hello.txt http://localhost:9333/submit
{"fid":"6,04dce94a72","fileName":"hello.txt","fileUrl":"127.0.0.1:8082/6,04dce94a72","size":39}

再次停掉dc2,之后尝试删除hello.txt(通过master删除):

$ curl -L  -X DELETE http://127.0.0.1:9333/6,04dce94a72
{"error":"Deletion Failed."}

虽然返回的是delete failed,但从8082上的日志来看,似乎8082已经将hello.txt删除了:

I0820 17:32:20 07653 volume_server_handlers_write.go:53] deleting Cookie:3706276466, Id:4, Size:0, DataSize:0, Name: , Mime:

我们再从8082获取一下hello.txt:

$ curl  http://127.0.0.1:8082/6,04dce94a72

结果是什么也没有返回。

从8082日志来看:

I0820 17:33:24 07653 volume_server_handlers_read.go:53] read error: File Entry Not Found. Needle 70 Memory 0 /6,04dce94a72

hello.txt的确被删除了!

这时将dc2(8083)重新启动!我们尝试从8083获取hello.txt:

$ curl  http://127.0.0.1:8083/6,04dce94a72
hello weed-fs!

8083上的hello.txt依旧存在,可以被读取。

再试试通过master来获取hello.txt:

$ curl  -L http://127.0.0.1:9333/6,04dce94a72
$ curl  -L http://127.0.0.1:9333/6,04dce94a72
hello weed-fs!

结果是有时能返回hello.txt内容,有时不行。显然这是与master的自动负载均衡有关,返回8082这个重定向地址,则curl无法得 到结果;但若返回8083这个重定向地址,我们就可以得到hello.txt的内容。

这样来看,目前weed-fs的删除操作还无法保证强一致性。weed-fs github.com上已有若干issues(#172,#179,#182)是关于这个问题的。在大数据量(TB、PB级别)的情况下,这种不一致性最 大的问题是导致storage leak,即空间被占用而无法回收,volume将被逐个逐渐占满,期待后续的解决方案吧。

五、目录支持

weed-fs还支持像传统文件系统那样,将文件放在目录下管理,并通过文件路径对文件进行存储、获取和删除操作。weed-fs对目录的支持是 通过另外一个server实现的:filer server。也就是说如果想拥有对目录的支持,则必须启动一个(或若干个) filer server,并且所有的操作都要通过filer server进行。

$ weed filer -port=8888 -dir=./f1 -master=localhost:9333 -defaultReplicaPlacement=100
I0820 22:09:40 08238 file_util.go:20] Folder ./f1 Permission: -rwxrwxr-x
I0820 22:09:40 08238 filer.go:88] Start Seaweed Filer 0.70 beta at port 8888

1、存储

$curl -F "filename=@hello.txt" "http://localhost:8888/foo/"
{"name":"hello.txt","size":39}

2、获取

$ curl http://localhost:8888/foo/hello.txt
hello weed-fs!

3、查询目录文件列表

$ curl "http://localhost:8888/foo/?pretty=y"
{
  "Directory": "/foo/",
  "Files": [
    {
      "name": "hello.txt",
      "fid": "6,067281a126"
    }
  ],
  "Subdirectories": null
}

4、删除

$ curl -X DELETE http://localhost:8888/foo/hello.txt
{"error":""}

再尝试获取hello.txt:

$curl http://localhost:8888/foo/hello.txt
返回空。hello.txt已被删除。

5、filer server

weed filer server是单点,我们再来启动一个filer server。

$ weed filer -port=8889 -dir=./f2 -master=localhost:9333 -defaultReplicaPlacement=100
I0821 13:47:52 08973 file_util.go:20] Folder ./f2 Permission: -rwxrwxr-x
I0821 13:47:52 08973 filer.go:88] Start Seaweed Filer 0.70 beta at port 8889

两个filer节点间是否有协调呢?我们来测试一下:我们从8888存储一个文件,然后从8889获取这个文件:

$ curl -F "filename=@hello.txt" "http://localhost:8888/foo/"
{"name":"hello.txt","size":39}
$ curl http://localhost:8888/foo/hello.txt
hello weed-fs!
$ curl http://localhost:8889/foo/hello.txt

从测试结果来看,二者各自独立工作,并没有任何联系,也就是说没有共享“文件full path”到"fid"的索引关系。默认情况下 filer server都是工作在standalone模式下的。

weed-fs官方给出了filer的集群方案,即使用redis或Cassandra作为后端,在多个filer节点间共享“文件full path”到"fid"的索引关系。

我们启动一个redis-server(2.8.21),监听在默认的6379端口。用下面命令重启两个filer server节点:

$ weed filer -port=8888 -dir=./f1 -master=localhost:9333 -defaultReplicaPlacement=100 -redis.server=localhost:6379
$ weed filer -port=8889 -dir=./f2 -master=localhost:9333 -defaultReplicaPlacement=100 -redis.server=localhost:6379

重复一下上面的测试步骤:
$ curl -F "filename=@hello.txt" "http://localhost:8888/foo/"
{"name":"hello.txt","size":39}

$ curl http://localhost:8889/foo/hello.txt
hello weed-fs!

可以看到从8888存储的文件,可以被从8889获取到。

我们删除这个文件:
$ curl -X DELETE http://localhost:8889/foo/hello.txt
{"error":"Invalid fileId "}

提示error,但实际上文件已经被删除了!这块可能是个小bug(#183)。

虽然filer是集群了,但其后端的redis依旧是单点,如果考虑高可靠性,redis显然也要做好集群。

六、Collection

Collection,顾名思义是“集合”,在weed-fs中,它指的是物理volume的集合。前面我们在存储文件时并没有指定 collection,因此weed-fs采用默认collection(空)。如果我们指定集合,结果会是什么样子呢?

$ curl -F file=@hello.txt "http://localhost:9333/submit?collection=picture"
{"fid":"7,0c4f5dc90f","fileName":"hello.txt","fileUrl":"127.0.0.1:8083/7,0c4f5dc90f","size":39}

$ ls v1 v2 v3
v1:
3.dat  3.idx  4.dat  4.idx  5.dat  5.idx  picture_7.dat  picture_7.idx
v2:
1.dat  1.idx  2.dat  2.idx  6.dat  6.idx
v3:
1.dat  1.idx  2.dat  2.idx  3.dat  3.idx  4.dat  4.idx  5.dat  5.idx  6.dat  6.idx  picture_7.dat  picture_7.idx

可以看出volume server在自己的-dir下面建立了一个collection名字为prefix的idx和dat文件,上述例子中hello.txt被分配到 8081和8083两个volume server上,因此这两个volume server各自建立了picture_7.dat和picture_7.idx。以picture为前缀的idx和dat文件只是用来存放存储在 collection=picture的文件数据,其他数据要么存储在默认collection中,要么存储在其他名字的collection 中。

collection就好比为Windows下位驱动器存储卷起名。比如C:叫"系统盘",D叫“程序盘”,E叫“数据盘”。这里各个 volume server下的picture_7.dat和picture_7.idx被起名为picture卷。如果还有video collection,那么它可能由各个volume server下的video_8.dat和video_8.idx。

不过由于默认情况下,weed volume的默认-max="7",因此在实验环境下每个volume server最多在-dir下建立7个物理卷(七对.idx和.dat)。如果此时我还想建立video卷会怎么样呢?

$ curl -F file=@hello.txt "http://localhost:9333/submit?collection=video"
{"error":"Cannot grow volume group! Not enough data node found!"}

volume server们返回失败结果,提示无法再扩展volume了。这时你需要重启各个volume server,将-max值改大,比如100。

比如:$weed -v=3 volume -port=8083 -dir=./v3 -mserver=localhost:9335 -dataCenter=dc2 -max=100

重启后,我们再来建立video collection:

$ curl -F file=@hello.txt "http://localhost:9333/submit?collection=video"
{"fid":"11,0ee98ca54d","fileName":"hello.txt","fileUrl":"127.0.0.1:8083/11,0ee98ca54d","size":39}

$ ls v1 v2 v3
v1:
3.dat  4.dat  5.dat  picture_7.dat  video_10.dat  video_11.dat  video_12.dat  video_13.dat  video_9.dat
3.idx  4.idx  5.idx  picture_7.idx  video_10.idx  video_11.idx  video_12.idx  video_13.idx  video_9.idx

v2:
1.dat  1.idx  2.dat  2.idx  6.dat  6.idx  video_8.dat  video_8.idx

v3:
1.dat  2.dat  3.dat  4.dat  5.dat  6.dat  picture_7.dat  video_10.dat  video_11.dat  video_12.dat  video_13.dat  video_8.dat  video_9.dat
1.idx  2.idx  3.idx  4.idx  5.idx  6.idx  picture_7.idx  video_10.idx  video_11.idx  video_12.idx  video_13.idx  video_8.idx  video_9.idx

可以看到每个datacenter的volume server一次分配了6个volume作为video collection的存储卷。

七、伸缩(Scaling)

对于分布式系统来说,Scaling是不得不考虑的问题,也是极为常见的操作。

1、伸(scale up)

weed-fs对“伸"的支持是很好的,我们分角色说。

【master】
    master间采用的是raft协议,增加一个master,对于集群来说是最最基本的操作:

$weed -v=3 master -port=9336 -mdir=./m4 -peers=localhost:9333,localhost:9334,localhost:9335,localhost:9336 -defaultReplication=100
I0821 15:45:47 12398 file_util.go:20] Folder ./m4 Permission: -rwxrwxr-x
I0821 15:45:47 12398 topology.go:86] Using default configurations.
I0821 15:45:47 12398 master_server.go:59] Volume Size Limit is 30000 MB
I0821 15:45:47 12398 master.go:69] Start Seaweed Master 0.70 beta at 0.0.0.0:9336
I0821 15:45:47 12398 raft_server.go:50] Starting RaftServer with IP:localhost:9336:
I0821 15:45:47 12398 raft_server.go:74] Joining cluster: localhost:9333,localhost:9334,localhost:9335,localhost:9336
I0821 15:45:48 12398 raft_server.go:134] Attempting to connect to: http://localhost:9333/cluster/join
I0821 15:45:49 12398 raft_server.go:179] Post returned status:  200

新master节点启动后,会通过raft协议自动加入到以9333为leader的master集群中。

【volume】

和master一样,volume本身就是靠master管理的,volume server之间没有什么联系,增加一个volume server要做的就是启动一个新的volume server就好了:

$ weed -v=3 volume -port=8084 -dir=./v4 -mserver=localhost:9335 -dataCenter=dc2
I0821 15:48:21 12412 file_util.go:20] Folder ./v4 Permission: -rwxrwxr-x
I0821 15:48:21 12412 store.go:225] Store started on dir: ./v4 with 0 volumes max 7
I0821 15:48:21 12412 volume.go:136] Start Seaweed volume server 0.70 beta at 0.0.0.0:8084
I0821 15:48:21 12412 volume_server.go:70] Volume server bootstraps with master localhost:9335
I0821 15:48:22 12412 list_masters.go:18] list masters result :
I0821 15:48:22 12412 list_masters.go:18] list masters result :{"IsLeader":true,"Leader":"localhost:9333","Peers":["localhost:9334","localhost:9335","localhost:9336"]}
I0821 15:48:22 12412 store.go:65] current master nodes is nodes:[localhost:9334 localhost:9335 localhost:9336 localhost:9333 localhost:9333], lastNode:4
I0821 15:48:22 12412 volume_server.go:82] Volume Server Connected with master at localhost:9333

新volume server节点启动后,同样会自动加入集群,后续master就会自动在其上存储数据了。

【filer】

前面已经谈到了,无论是standalone模式,还是distributed模式,filter都可以随意增减,这里就不再重复赘述了。

2、缩(scale down)

master的缩是极其简单的,只需将相应节点shutdown即可;如果master是leader,则其他master会检测到leader shutdown,并自动重新选出新leader。不过在leader选举的过程中,整个集群的服务将短暂停止,直到leader选出。

filer在standalone模式下,谈伸缩是毫无意义的;对于distributed模式下,filter节点和master节点缩的方法 一致,shutdown即可。

唯一的麻烦就是volume节点,因为数据存储在volume节点下,我们不能简单的停掉volume,我们需要考虑在不同 replication策略下是否可以做数据迁移,如何做数据迁移。这就是下一节我们要详细描述的。

八、数据迁移

下面我们就来探讨一下weed-fs的volume数据迁移问题。

1、000复制策略下的数据迁移

为方便测试,我简化一下实验环境(一个master+3个volume):

master:

$ weed -v=3 master -port=9333 -mdir=./m1 -defaultReplication=000

volume:

$ weed -v=3 volume -port=8081 -dir=./v1 -mserver=localhost:9333 -dataCenter=dc1
$ weed -v=3 volume -port=8082 -dir=./v2 -mserver=localhost:9333 -dataCenter=dc1
$ weed -v=3 volume -port=8083 -dir=./v3 -mserver=localhost:9333 -dataCenter=dc1

和之前一样,启动后,v1,v2,v3目录下面是空的,卷的创建要等到第一份数据存入时。000策略就是没有副本的策略,你存储的文件在 weed-fs中只有一份数据。

我们上传一份文件:

$ curl -F filename=@hello1.txt "http://localhost:9333/submit"
{"fid":"1,01655ab58e","fileName":"hello1.txt","fileUrl":"127.0.0.1:8081/1,01655ab58e","size":40}

$ ll v1 v2 v3

v1:
-rw-r–r– 1 tonybai tonybai  104  8 21 21:31 1.dat
-rw-r–r– 1 tonybai tonybai   16  8 21 21:31 1.idx
-rw-r–r– 1 tonybai tonybai    8  8 21 21:31 4.dat
-rw-r–r– 1 tonybai tonybai    0  8 21 21:31 4.idx
-rw-r–r– 1 tonybai tonybai    8  8 21 21:31 7.dat
-rw-r–r– 1 tonybai tonybai    0  8 21 21:31 7.idx

v2:
-rw-r–r– 1 tonybai tonybai    8  8 21 21:31 2.dat
-rw-r–r– 1 tonybai tonybai    0  8 21 21:31 2.idx
-rw-r–r– 1 tonybai tonybai    8  8 21 21:31 3.dat
-rw-r–r– 1 tonybai tonybai    0  8 21 21:31 3.idx
-rw-r–r– 1 tonybai tonybai    8  8 21 21:31 6.dat
-rw-r–r– 1 tonybai tonybai    0  8 21 21:31 6.idx

v3:
-rw-r–r– 1 tonybai tonybai    8  8 21 21:31 5.dat
-rw-r–r– 1 tonybai tonybai    0  8 21 21:31 5.idx

可以看到hello1.txt被存储在v1下,同时可以看出不同的物理卷分别存放在不同节点下(由于不需要do replication)。

在这种情况(000)下,如果要将v1数据迁移到v2或v3中,只需将v1停掉,将v1下的文件mv到v2或v3中,重启volume server2或volume server3即可。

2、001复制策略下的数据迁移

001复制策略是weed-fs默认的复制策略,weed-fs会为每个文件在同Rack下复制一个副本。我们还利用上面的环境,不过需要停掉 weed-fs,清空目录下的文件,重启后使用,别忘了-defaultReplication=001。

我们连续存储三个文件:

$ curl -F filename=@hello1.txt "http://localhost:9333/submit"
{"fid":"2,01ea84980d","fileName":"hello1.txt","fileUrl":"127.0.0.1:8082/2,01ea84980d","size":40}

$ curl -F filename=@hello2.txt "http://localhost:9333/submit"
{"fid":"1,027883baa8","fileName":"hello2.txt","fileUrl":"127.0.0.1:8083/1,027883baa8","size":40}

$ curl -F filename=@hello3.txt "http://localhost:9333/submit"
{"fid":"6,03220f577e","fileName":"hello3.txt","fileUrl":"127.0.0.1:8081/6,03220f577e","size":40}

可以看出三个文件分别被存储在vol2, vol1和vol6中,我们查看一下v1, v2, v3中的文件情况:

$ ll v1 v2 v3
v1:
-rw-r–r– 1 tonybai tonybai  104  8 21 22:00 1.dat
-rw-r–r– 1 tonybai tonybai   16  8 21 22:00 1.idx
-rw-r–r– 1 tonybai tonybai    8  8 21 21:56 3.dat
-rw-r–r– 1 tonybai tonybai    0  8 21 21:56 3.idx
-rw-r–r– 1 tonybai tonybai    8  8 21 21:56 4.dat
-rw-r–r– 1 tonybai tonybai    0  8 21 21:56 4.idx
-rw-r–r– 1 tonybai tonybai  104  8 21 22:02 6.dat
-rw-r–r– 1 tonybai tonybai   16  8 21 22:02 6.idx

v2:
-rw-r–r– 1 tonybai tonybai  104  8 21 21:56 2.dat
-rw-r–r– 1 tonybai tonybai   16  8 21 21:56 2.idx
-rw-r–r– 1 tonybai tonybai    8  8 21 21:56 5.dat
-rw-r–r– 1 tonybai tonybai    0  8 21 21:56 5.idx

v3:
-rw-r–r– 1 tonybai tonybai  104  8 21 22:00 1.dat
-rw-r–r– 1 tonybai tonybai   16  8 21 22:00 1.idx
-rw-r–r– 1 tonybai tonybai  104  8 21 21:56 2.dat
-rw-r–r– 1 tonybai tonybai   16  8 21 21:56 2.idx
-rw-r–r– 1 tonybai tonybai    8  8 21 21:56 3.dat
-rw-r–r– 1 tonybai tonybai    0  8 21 21:56 3.idx
-rw-r–r– 1 tonybai tonybai    8  8 21 21:56 4.dat
-rw-r–r– 1 tonybai tonybai    0  8 21 21:56 4.idx
-rw-r–r– 1 tonybai tonybai    8  8 21 21:56 5.dat
-rw-r–r– 1 tonybai tonybai    0  8 21 21:56 5.idx
-rw-r–r– 1 tonybai tonybai  104  8 21 22:02 6.dat
-rw-r–r– 1 tonybai tonybai   16  8 21 22:02 6.idx

假设我们现在要shutdown v3,将v3数据迁移到其他volume server,我们有3种做法:

1) 不迁移
2) 将v3下的所有文件mv到v2或v1中
3) 将v3下的所有文件先后覆盖到v1和v2中

我们来逐个分析每种做法的后果:

1)  不迁移

001策略下,每份数据有两个copy,v3中的数据其他两个v1+v2总是有的,因此即便不迁移,v1+v2中也会有一份数据copy。你可以 测试一下当shutdown volume3后:

$ curl -L "http://localhost:9333/2,01ea84980d"
hello weed-fs1!
$ curl -L "http://localhost:9333/1,027883baa8"
hello weed-fs2!
$ curl -L "http://localhost:9333/6,03220f577e"
hello weed-fs3!

针对每一份文件,你都可以多get几次,都会得到正确的结果。但此时的不足也很明显,那就是存量数据不再拥有另外一份备份。

2) 将v3下的所有文件mv到v2或v1中

还是根据001策略,将v3数据mv到v2或v1中,结果会是什么呢,这里就以v3 mv到 v1举例:
 
 - 对于v1和v3都有的卷id,比如1,两者的文件1.idx和1.dat是一模一样的。这是001策略决定的。但一旦迁移后,系统中的数据就由2份变 成1份了
 - 对于v1有,而v3没有的,那自然不必说了。
 - 对于v1没有,而v3有的,mv过去就成为了v1的数据。

为此,这种做法依旧不够完美。

3)将v3下的所有文件覆盖到v1和v2中

结合上面的方法,只有此种迁移方式才能保证迁移后,系统中的数据不丢失,且每个都是按照001策略所说的2份,这才是正确的方法。

我们来测试一下:

   – 停掉volume3;
   – 停掉volume1,将v3下的文件copy到v1下,启动volume1
   – 停掉volume2,将v3下的文件copy到v2下,启动volume2

$ curl  "http://localhost:9333/6,03220f577e"
<a href="http://127.0.0.1:8081/6,03220f577e">Moved Permanently</a>.

$ curl  "http://localhost:9333/6,03220f577e"
<a href="http://127.0.0.1:8082/6,03220f577e">Moved Permanently</a>.

可以看到,master返回了重定向地址8081和8082,说明8083迁移到8082上的数据也生效了。

3、100复制策略下的数据迁移

测试环境稍作变化:

master:

$ weed -v=3 master -port=9333 -mdir=./m1 -defaultReplication=100

volume:

$ weed -v=3 volume -port=8081 -dir=./v1 -mserver=localhost:9333 -dataCenter=dc1
$ weed -v=3 volume -port=8082 -dir=./v2 -mserver=localhost:9333 -dataCenter=dc1
$ weed -v=3 volume -port=8083 -dir=./v3 -mserver=localhost:9333 -dataCenter=dc2

和之前一样,我们上传三份文件:

$ curl -F filename=@hello1.txt "http://localhost:9333/submit"
{"fid":"4,01d937dd30","fileName":"hello1.txt","fileUrl":"127.0.0.1:8083/4,01d937dd30","size":40}

$ curl -F filename=@hello2.txt "http://localhost:9333/submit"
{"fid":"2,025efbef14","fileName":"hello2.txt","fileUrl":"127.0.0.1:8082/2,025efbef14","size":40}

$ curl -F filename=@hello3.txt "http://localhost:9333/submit"
{"fid":"2,03be936488","fileName":"hello3.txt","fileUrl":"127.0.0.1:8082/2,03be936488","size":40}

$ ll v1 v2 v3
-rw-r–r– 1 tonybai tonybai    8  8 21 22:58 3.dat
-rw-r–r– 1 tonybai tonybai    0  8 21 22:58 3.idx
-rw-r–r– 1 tonybai tonybai  104  8 21 22:58 4.dat
-rw-r–r– 1 tonybai tonybai   16  8 21 22:58 4.idx

v2:
-rw-r–r– 1 tonybai tonybai    8  8 21 22:58 1.dat
-rw-r–r– 1 tonybai tonybai    0  8 21 22:58 1.idx
-rw-r–r– 1 tonybai tonybai  200  8 21 22:59 2.dat
-rw-r–r– 1 tonybai tonybai   32  8 21 22:59 2.idx
-rw-r–r– 1 tonybai tonybai    8  8 21 22:58 5.dat
-rw-r–r– 1 tonybai tonybai    0  8 21 22:58 5.idx
-rw-r–r– 1 tonybai tonybai    8  8 21 22:58 6.dat
-rw-r–r– 1 tonybai tonybai    0  8 21 22:58 6.idx

v3:
-rw-r–r– 1 tonybai tonybai    8  8 21 22:58 1.dat
-rw-r–r– 1 tonybai tonybai    0  8 21 22:58 1.idx
-rw-r–r– 1 tonybai tonybai  200  8 21 22:59 2.dat
-rw-r–r– 1 tonybai tonybai   32  8 21 22:59 2.idx
-rw-r–r– 1 tonybai tonybai    8  8 21 22:58 3.dat
-rw-r–r– 1 tonybai tonybai    0  8 21 22:58 3.idx
-rw-r–r– 1 tonybai tonybai  104  8 21 22:58 4.dat
-rw-r–r– 1 tonybai tonybai   16  8 21 22:58 4.idx
-rw-r–r– 1 tonybai tonybai    8  8 21 22:58 5.dat
-rw-r–r– 1 tonybai tonybai    0  8 21 22:58 5.idx
-rw-r–r– 1 tonybai tonybai    8  8 21 22:58 6.dat
-rw-r–r– 1 tonybai tonybai    0  8 21 22:58 6.idx

由于100策略是在不同DataCenter中各保持一份copy,因此数据的迁移不应该在数据中心间进行,而同一数据中心内的迁移又回归到了 “000”策略的情形。

其他策略的分析方式也是如此,这里就不长篇大论了。

九、Benchmark

在HP ProLiant DL380 G4, Intel(R) Xeon(TM) CPU 3.60GHz 4核,6G内存的机器(非SSD硬盘)上,执行benchmark test:

$ weed benchmark -server=localhost:9333

This is SeaweedFS version 0.70 beta linux amd64

———— Writing Benchmark ———-
Concurrency Level:      16
Time taken for tests:   831.583 seconds
Complete requests:      1048576
Failed requests:        0
Total transferred:      1106794545 bytes
Requests per second:    1260.94 [#/sec]
Transfer rate:          1299.75 [Kbytes/sec]

Connection Times (ms)
              min      avg        max      std
Total:        2.2      12.5       1118.4      9.3

Percentage of the requests served within a certain time (ms)
   50%     11.4 ms
   66%     13.3 ms
   75%     14.8 ms
   80%     15.9 ms
   90%     19.2 ms
   95%     22.6 ms
   98%     27.4 ms
   99%     31.2 ms
  100%    1118.4 ms

———— Randomly Reading Benchmark ———-
Concurrency Level:      16
Time taken for tests:   151.480 seconds
Complete requests:      1048576
Failed requests:        0
Total transferred:      1106791113 bytes
Requests per second:    6922.22 [#/sec]
Transfer rate:          7135.28 [Kbytes/sec]

Connection Times (ms)
              min      avg        max      std
Total:        0.1      2.2       116.7      3.9

Percentage of the requests served within a certain time (ms)
   50%      1.6 ms
   66%      2.1 ms
   75%      2.5 ms
   80%      2.8 ms
   90%      3.7 ms
   95%      4.8 ms
   98%      7.4 ms
   99%     11.1 ms
  100%    116.7 ms

这个似乎比作者在mac笔记本(SSD)上性能还要差些,当然此次我们用的策略是100,并且这个服务器上还运行着其他程序。但即便如此,感觉weed-fs还是有较大优化的空间的。

作者在官网上将weed-fs与其他分布式文件系统如Ceph,hdfs等做了简要对比,强调了weed-fs相对于其他分布式文件系统的优点。

十、其它

weed-fs使用google glog,因此所有log的级别设置以及log定向的方法均与glog一致。

weed-fs提供了backup命令,用来在同机上备份volume server上的数据。

weed-fs没有提供官方client包,但在wiki上列出多种第三方client包(各种语言),就Go client包来看,似乎还没有特别理想的。

weed-fs目前还没有web console,只能通过命令行进行操作。

使用weed-fs时,别忘了将open files no limit调大,否则可能会导致volume server crash。

十一、小结

weed-fs为想寻找开源分布式文件系统的朋友们提供了一个新选择。尤其是在存储大量小图片时,weed-fs自身就是基于haystack这一优化图 片存储的论文的。另外weed-fs使用起来的确十分简单,分分钟就可以建立起一个分布式系统,部署容易,几乎不需要什么配置。但weed-fs目前最大 的问题似乎是没有重量级的使用案例,自身也还有不少不足,但希望通过这篇文章能让更多人认识weed-fs,并使用weed-fs,帮助改善weed-fs吧。

理解Go 1.5 vendor

Go 1.5中(目前最新版本go1.5beta3)加入了一个experimental feature: vendor/。这个feature不是Go 1.5的正式功能,但却是Go Authors们在解决Go被外界诟病的包依赖管理的道路上的一次重要尝试。目前关于Go vendor机制的资料有限,主要的包括如下几个:

1、Russ Cox在Golang-dev group上的一个名 为"proposal: external packages" topic上的reply。
2、Go 1.5beta版发布后Russ Cox根据上面topic整理的一个doc
3、medium.com上一篇名为“Go 1.5 vendor/ experiment"的文章。

但由于Go 1.5稳定版还未发布(最新消息是2015.8月中旬发布),因此估计真正采用vendor的repo尚没有。但既然是Go官方解决方案,后续从 expreimental变成official的可能性就很大(Russ的初步计划:如果试验顺利,1.6版本默认 GO15VENDOREXPERIMENT="1";1.7中将去掉GO15VENDOREXPERIMENT环境变量)。因此对于Gophers们,搞 清楚vendor还是很必要的。本文就和大家一起来理解下vendor这个新feature。

一、vendor由来

Go第三方包依赖和管理的问题由来已久,民间知名的解决方案就有godepgb等。这次Go team在推出vendor前已经在Golang-dev group上做了长时间的调研,最终Russ Cox在Keith Rarick的proposal的基础上做了改良,形成了Go 1.5中的vendor。

Russ Cox基于前期调研的结果,给出了vendor机制的群众意见基础:
    – 不rewrite gopath
    – go tool来解决
    – go get兼容
    – 可reproduce building process

并给出了vendor机制的"4行"诠释:

If there is a source directory d/vendor, then, when compiling a source file within the subtree rooted at d, import "p" is interpreted as import "d/vendor/p" if that exists.

When there are multiple possible resolutions,the most specific (longest) path wins.

The short form must always be used: no import path can  contain “/vendor/” explicitly.

Import comments are ignored in vendored packages.

这四行诠释在group中引起了强烈的讨论,短小精悍的背后是理解上的不小差异。我们下面逐一举例理解。

二、vendor基本样例

Russ Cox诠释中的第一条是vendor机制的基础。粗犷的理解就是如果有如下这样的目录结构:

d/
   vendor/
          p/
           p.go
   mypkg/
          main.go

如果mypkg/main.go中有"import p",那么这个p就会被go工具解析为"d/vendor/p",而不是$GOPATH/src/p。

现在我们就来复现这个例子,我们在go15-vendor-examples/src/basic下建立如上目录结构(其中go15-vendor-examples为GOPATH路径):

$ls -R
d/

./d:
mypkg/    vendor/

./d/mypkg:
main.go

./d/vendor:
p/

./d/vendor/p:
p.go

其中main.go代码如下:

//main.go
package main

import "p"

func main() {
    p.P()
}

p.go代码如下:

//p.go
package p

import "fmt"

func P() {
    fmt.Println("P in d/vendor/p")
}

在未开启vendor时,我们编译d/mypkg/main.go会得到如下错误结果:

$ go build main.go
main.go:3:8: cannot find package "p" in any of:
    /Users/tony/.bin/go15beta3/src/p (from $GOROOT)
    /Users/tony/OpenSource/github.com/experiments/go15-vendor-examples/src/p (from $GOPATH)

错误原因很显然:go编译器无法找到package p,d/vendor下的p此时无效。

这时开启vendor:export GO15VENDOREXPERIMENT=1,我们再来编译执行一次:
$go run main.go
P in d/vendor/p

开启了vendor机制的go tool在d/vendor下找到了package p。

也就是说拥有了vendor后,你的project依赖的第三方包统统放在vendor/下就好了。这样go get时会将第三方包同时download下来,使得你的project无论被下载到那里都可以无需依赖目标环境而编译通过(reproduce the building process)。

三、嵌套vendor

那么问题来了!如果vendor中的第三方包中也包含了vendor目录,go tool是如何choose第三方包的呢?我们来看看下面目录结构(go15-vendor-examples/src/embeded):

d/
   vendor/
          p/
            p.go
          q/
            q.go
            vendor/
               p/
                 p.go
   mypkg/
          main.go

embeded目录下出现了嵌套vendor结构:main.go依赖的q包本身还有一个vendor目录,该vendor目录下有一个p包,这样我们就有了两个p包。到底go工具会选择哪个p包呢?显然为了验证一些结论,我们源文件也要变化一下:

d/vendor/p/p.go的代码不变。

//d/vendor/q/q.go
package q

import (
    "fmt"
    "p"
)

func Q() {
    fmt.Println("Q in d/vendor/q")
    p.P()
}

//d/vendor/q/vendor/p/p.go
package p

import "fmt"

func P() {
    fmt.Println("P in d/vendor/q/vendor/p")
}

//mypkg/main.go
package main

import (
    "p"
    "q"
)

func main() {
    p.P()
    fmt.Println("")
    q.Q()
}

目录和代码编排完毕,我们就来到了见证奇迹的时刻了!我们执行一下main.go:

$go run main.go
P in d/vendor/p

Q in d/vendor/q
P in d/vendor/q/vendor/p

可以看出main.go中最终引用的是d/vendor/p,而q.Q()中调用的p.P()则是d/vendor/q/vendor/p包的实现。go tool到底是如何在嵌套vendor情况下选择包的呢?我们回到Russ Cox关于vendor诠释内容的第二条:

   When there are multiple possible resolutions,the most specific (longest) path wins.

这句话很简略,但却引来的巨大争论。"longest path wins"让人迷惑不解。如果仅仅从字面含义来看,上面main.go的执行结果更应该是:

P in d/vendor/q/vendor/p

Q in d/vendor/q
P in d/vendor/q/vendor/p

d/vendor/q/vendor/p可比d/vendor/p路径更long,但go tool显然并未这么做。它到底是怎么做的呢?talk is cheap, show you the code。我们粗略翻看一下go tool的实现代码:

在$GOROOT/src/cmd/go/pkg.go中有一个方法vendoredImportPath,这个方法在go tool中广泛被使用

// vendoredImportPath returns the expansion of path when it appears in parent.
// If parent is x/y/z, then path might expand to x/y/z/vendor/path, x/y/vendor/path,
// x/vendor/path, vendor/path, or else stay x/y/z if none of those exist.
// vendoredImportPath returns the expanded path or, if no expansion is found, the original.
// If no expansion is found, vendoredImportPath also returns a list of vendor directories
// it searched along the way, to help prepare a useful error message should path turn
// out not to exist.
func vendoredImportPath(parent *Package, path string) (found string, searched []string)

这个方法的doc讲述的很清楚,这个方法返回所有可能的vendor path,以parentpath为x/y/z为例:

x/y/z作为parentpath输入后,返回的vendorpath包括:
   
x/y/z/vendor/path
x/y/vendor/path
x/vendor/path
vendor/path

这么说还不是很直观,我们结合我们的embeded vendor的例子来说明一下,为什么结果是像上面那样!go tool是如何resolve p包的!我们模仿go tool对main.go代码进行编译(此时vendor已经开启)。

根据go程序的package init顺序,go tool首先编译p包。如何找到p包呢?此时的编译对象是d/mypkg/main.go,于是乎parent = d/mypkg,经过vendordImportPath处理,可能的vendor路径为:

d/mypkg/vendor
d/vendor

但只有d/vendor/下存在p包,于是go tool将p包resolve为d/vendor/p,于是下面的p.P()就会输出:
P in d/vendor/p

接下来初始化q包。与p类似,go tool对main.go代码进行编译,此时的编译对象是d/mypkg/main.go,于是乎parent = d/mypkg,经过vendordImportPath处理,可能的vendor路径为:

d/mypkg/vendor
d/vendor

但只有d/vendor/下存在q包,于是乎go tool将q包resolve为d/vendor/q,由于q包自身还依赖p包,于是go tool继续对q中依赖的p包进行选择,此时go tool的编译对象变为了d/vendor/q/q.go,parent = d/vendor/q,于是经过vendordImportPath处理,可能的vendor路径为:

d/vendor/q/vendor
d/vendor/vendor
d/vendor

存在p包的路径包括:

d/vendor/q/vendor/p
d/vendor/p

此时按照Russ Cox的诠释2:choose longest,于是go tool选择了d/vendor/q/vendor/p,于是q.Q()中的p.P()输出的内容就是:
"
P in d/vendor/q/vendor/p"

如果目录结构足够复杂,这个resolve过程也是蛮繁琐的,但按照这个思路依然是可以分析出正确的包的。

另外vendoredImportPath传入的parent x/y/z并不是一个绝对路径,而是一个相对于$GOPATH/src的路径。

BTW,上述测试样例代码在这里可以下载到。

四、第三和第四条

最难理解的第二条已经pass了,剩下两条就比较好理解了。

The short form must always be used: no import path can  contain “/vendor/” explicitly.

这条就是说,你在源码中不用理会vendor这个路径的存在,该怎么import包就怎么import,不要出现import "d/vendor/p"的情况。vendor是由go tool隐式处理的。

Import comments are ignored in vendored packages.

go 1.4引入了canonical imports机制,如:

package pdf // import "rsc.io/pdf"

如果你引用的pdf不是来自rsc.io/pdf,那么编译器会报错。但由于vendor机制的存在,go tool不会校验vendor中package的import path是否与canonical import路径是否一致了。

五、问题

根据小节三中的分析,对于vendor中包的resolving过程类似是一个recursive(递归)过程。

main.go中的p使用d/vendor/p;而q.go中的p使用的是d/vendor/q/vendor/p,这样就会存在一个问题:一个工程中存 在着两个版本的p包,这也许不会带来问题,也许也会是问题的根源,但目前来看从go tool的视角来看似乎没有更好的办法。Russ Cox期望大家良好设计工程布局,作为lib的包不携带vendor更佳。

这样一个project内的所有vendor都集中在顶层vendor里面。就像下面这样:

d/
    vendor/   
            q/
            p/
            … …
    mypkg1
            main.go
    mypkg2
            main.go
    … …

另外Go vendor不支持第三方包的版本管理,没有类似godep的Godeps.json这样的存储包元信息的文件。不过目前已经有第三方的vendor specs放在了github上,之前Go team的Brad Fizpatrick也在Golang-dev上征集过类似的方案,不知未来vendor是否会支持。

六、vendor vs. internal

在golang-dev有人提到:有了vendor,internal似乎没用了。这显然是混淆了internal和vendor所要解决的问题。

internal故名思议:内部包,不是对所有源文件都可见的。vendor是存储和管理外部依赖包,更类似于external,里面的包都是copy自 外部的,工程内所有源文件均可import vendor中的包。另外internal在1.4版本中已经加入到go核心,是不可能轻易去除的,虽然到目前为止我们还没能亲自体会到internal 包的作用。

在《Go 1.5中值得关注的几个变化》一文中我提到过go 1.5 beta1似乎“不支持”internal,beta3发布后,我又试了试看beta3是否支持internal包。

结果是beta3中,build依旧不报错。但go list -json会提示错误:
"DepsErrors": [
        {
            "ImportStack": [
                "otherpkg",
                "mypkg/internal/foo"
            ],
            "Pos": "",
            "Err": "use of internal package not allowed"
        }
    ]

难道真的要到最终go 1.5版本才会让internal包发挥作用?




这里是Tony Bai的个人Blog,欢迎访问、订阅和留言!订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您喜欢通过微信App浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:



本站Powered by Digital Ocean VPS。

选择Digital Ocean VPS主机,即可获得10美元现金充值,可免费使用两个月哟!

著名主机提供商Linode 10$优惠码:linode10,在这里注册即可免费获得。

阿里云推荐码:1WFZ0V立享9折!

View Tony Bai's profile on LinkedIn


文章

评论

  • 正在加载...

分类

标签

归档











更多