在Go语言中处理任何stream数据时,我已经深陷io.Reader和io.Writer的灵活性中不能自拔。同时我在有一点上又或多或少的受了些折磨,挑战我的reader interface在你看来可能会觉得很简单:那就是怎么样拆分读操作。
我甚至不知道使用“拆分(split)”这个词是否正确,我就是想通过io.Reader多次读取接收到的东西,有时候可能还需要并行操作。但是由于readers不一定会暴露Seek方法重置读取位置,我需要一个方法来复制它。或者可以算是clone或fork么?
现状
假设你有一个web服务允许用户上传一个文件。这个服务将会把文件存储在云端。但是在存储前需要对这个文件进行一些简单的处理。对于接下来的所有请求,你都不得不使用io.Reader去处理。
解决方案
当然,有不止一种方法可以处理这种情况。根据文件的类型,服务的吞吐量,以及文件需要的处理方式的不同有些方式可能比其他的更合适。下面,我给出了5中不同复杂度和灵活性的方法。可以想象还会有更多的方法,但是这几个会是一个不错的起点。
Solution #1:简单的bytes.Reader
如果源reader没有Seek
方法,为什么不自己实现一个呢?你可以把所有的内容都读取到一个bytes.Reader
中,然后你想分多少次读取都可以,只要你开心:
func handleUpload(u io.Reader)(err error) {
//capture all bytes from upload
b, err := ioutil.ReadAll(u)
if err != nil {
return err
}
//wrap the bytes in a ReaderSeeker
r := bytes.NewReader(b)
//process the metadata
err = processMetaData(r)
if err != nil {
return err
}
r.Seek(0, 0)
//upload the data
err = uploadFile(r)
if err != nil {
return err
}
return nil
}
如果数据足够小,这可能是最方便的选择;你可以完全忘掉bytes.Reader
并使用*byte slice的方式代替工作。但是假如是大文件,如视频文件或RAW格式的照片等。这些庞然大物将吞噬你的内存,特别是如果服务还具有高流量特征时。更何况(not to mention)你不能并行执行这些操作。
- 优点:最简单的方案
- 缺点:同步,无法适应你期望的很多、很大的文件。
Solution #2:可靠的文件系统
OK,那么将数据放到磁盘中的文件如何(借助ioutil.TempFile
),并且可以避免将数据存储在内存中带来的隐患。
func handleUpload(u io.Reader)(err error) {
//create a temporary file for the upload
f, err := ioutil.TempFile("", "upload")
if err != nil {
return err
}
//destroy the file once done
defer func() {
n := f.name()
f.Close()
os.Remove(n)
}()
//transfer the bytes to the file
_, err := io.Copy(f, u)
if err != nil {
return err
}
//rewind the file
f.Seek(0.0)
//upload the file
err = uploadFile(f)
if err != nil{
return err
}
return nil
}
如果最终是要将文件存储在service运行的文件系统中,这种方法可能是最好的选择(尽管会产生一个真实的临时文件),但是我们假设它最终将落在云上。继续,如果这个文件同样很大,则将产生显著的,但是不必要的IO。同时,你还将面临机器上单个文件错误或宕机的风险,所以如果你的数据比较敏感,我也不推荐这种方式。
- 优点:避免大量内存占用保存整个文件
- 缺点:同步,潜在的占用大量IO、磁盘空间以及数据单点故障
Solution #3:The Duct-Tape io.MultiReader
有些情况下,你需要的metadata存在于文件最开始的几个字节。例如,识别一个JPEG格式的文件只需要检查文件的前两个字节是否是0xFF 0xD8
。这个可以通过使用io.MultiReader
同步处理。io.MultiReader
将一组readers组织起来使他们看起来像一个一样。如下是我们的JPEG示例:
func handleUpload(u io.Reader)(err error) {
//read in the first 2 bytes
b := make([]byte, 2)
_, err := u.Read(b)
if err != nil {
return err
}
//check that they match the JPEG header
jpg := []byte{0xFF, 0xD8}
if !bytes.Equal(b, jpg) {
return errors.New("not a JPEG")
}
//glue those bytes back onto the reader
r := io.MultiReader(bytes.NewReader(b), u)
//upload the file
err = uploadFile(r)
if err != nil {
return err
}
return nil
}
如果你只打算上传JPEG文件,这是一个很好的技术。只需要两个字节,你就可以停止传输(注:此处的传输不是文件上传的传输,而是将文件拷贝到内存或磁盘进行处理的传输过程),而不必将整个文件拷贝到内存或存放到磁盘上。你应该也会发现,有些场景这个方法也并不适用。比如你需要读取更多的文件内容去收集数据,如通过计算统计单词个数等。这个过程会阻塞文件上传,对任务密集型可能也不是理想的处理方式。最后,大多数第三方包(和大部分标准库)将完整的消耗掉一个reader,以防止你以这种方式使用io.MultiReader
.
另一种方案是使用bufio.Reader.Peek
。本质上它执行相同的操作,但是你可以避开MultiReader
。也就是说,它还可以让你访问Reader上的其他的有用的方法。
- 优点:快速且是对文件头的脏读,可以作为文件上传的门槛。
- 缺点:不适用于不定长读取,处理整个文件,密集任务,或和很多第三方包一同使用。
Solution #4:The Single-Split io.TeeReader
and io.Pipe
回到前面讨论的大视频文件的情况,我们稍微修改一下故事情节。你的用户只会上传单一格式的视频文件,但是你希望这些视频文件能够被你的服务以不同格式播放。比如说,你有一个第三方转码器可以将io.Reader
读取的MP4格式数据转换成WebM格式的数据输出。你的服务将会把原始的MP4和转码的WebM文件都上传到云端。前面的方案必须同步的执行这些操作,现在你想要并行的完成这件事情。
看看io.TeeReader
,它的函数签名是这样的:func TeeReader(r Reader, w Writer) Reader
。文档中是这样描述的:TeeReader将从Reader r读取的数据返回一个写到Writer w的Reader。这个正是你所需要的!现在你怎么确保写到w的数据可读?这个是通过io.Pipe
实现的,它在io.PipeWriter
和io.PipeReader
之间建立了一个连接(即栈,后入先出)。看看代码是怎么实现的:
func HandleUpload(u io.Reader) (err error) {
//create the pipe and tee reader
pr, pw := io.Pipe()
tr := io.TeeReader(u, pw)
//Create channels to synchronize
done := make(chan bool)
errs := make(chan error)
defer close(done)
defer close(errs)
go func() {
//close the PipeWriter after the
//TeeReader completes to trigger EOF
defer pw.Close()
//upload the original MP4 data
err := uploadFile(tr)
if err != nil {
errs <- err
return
}
done <- true
}()
go func() {
//transcode to WebM
webmr, err := transcode(pr)
if err != nil {
errs <- err
return
}
//upload to storage
err = uploadFile(webmr)
if err != nil {
errs <- err
return
}
done <- true
}()
//wait until both are done
//or an error occurs
for c := 0; c < 2; {
select {
case err := <-errs:
return err
case <- done:
c++
}
}
return nil
}
因为uploader将要消费tr
,transcoder在将数据存储前接收并处理相同的数据。所有的操作不需要额外的buffer,并且并行的执行。注意这里使用goroutine来执行这两天路径。io.Pipe
处于阻塞状态直到有程序向它写或从它读取数据。如果尝试在同一个线程中执行相同的io.Pipe
,将会得到一个致命错误:fatal error;all goroutines are asleep - deadlock
。panic。另一个需要注意的点是:使用Pipe时,你需要在一个合适的时间显示的触发一个EOF来关闭io.PipeWriter
。在这个实力中,需要在TeeReader
结束后关闭它。
这个示例同样采用了channel来进行goroutines之间的“doneness”和error的同步。如果你期望在执行过程中有一些更具体的值返回,你可以使用更合适的类型替换chan bool。
- 优点:完全独立的,并行的处理相同的数据流
- 缺点,使用goroutines和channel增加了复杂度
Solution #5:The Multi-Split io.MultiWriter
and io.Copy
io.TeeReader
在只有一个其他的流消费者时,能够非常好的解决问题。由于service可能还需要并行的处理更多的任务(如,转换成更多的格式),使用tee的叠加将使代码变得臃肿。看看io.MultiWriter
的解释:“一个将writes复制并提供给多个writers的writer”。它也像前面的方法一样使用pipes来传播数据,不同的是,不是使用io.TeeReader
,而是使用io.Copy
将数据分发到所有的Pipes。示例代码如下:
func handleUpload(u io.Reader)(err error) {
//create the pipes
mp4R, mp4W := io.Pipe()
webmR, webmW := io.Pipe()
oggR, oggW := io.Pipe()
wavR, wavW := io.Pipe()
//create channels to syschronize
done := make(chan bool)
errs := make(chan error)
defer close(done)
defer close(err)
//spawn all the task goroutines. these looks identical to
//the TeeReader example, but pulled out into separate
//methods for clarity
go uploadMP4(mp4R, done, errs)
go transcodeAndUploadWebM(webmR, done, errs)
go transcodeAndUploadOgg(webmR, done, errs)
go transcodeAndUploadWav(webmR, done, errs)
go func() {
// after completing the copy, we need to close
// the PipeWriters to propagate the EOF to all
// PipeReaders to avoid deadlock
defer mp4W.Close()
defer webmW.Close()
defer oggW.Close()
defer wavW.Close()
//build the multiwriter for all the pipes
mw := io.MultiWriter(mp4W, webmW, oggW, wavW)
//copy the data into the multiwriter
_, err := io.Copy(mw, u)
if err != nil {
errs <- err
}
}()
// wait until all are done
// or an error occurs
for c := 0; c < 4; c++ {
select {
case err := <-errs:
return err
case <-done:
}
}
return nil
}
这个方法和前面的方法有点类似,但是当数据需要被克隆多次时,这种方法明显的更加简洁。因为使用了PIPEs,同样需要使用goroutines和同步channel,以防止死锁。我们在copy完成了关闭了所有的pipes。
- 优点:可以根据需要fork多份原始数据
- 缺点:过多的依赖goroutines和channel进行协调。
关于channels?
Channels是Go提供的独特的,强大的并发工具之一。它是goroutines之间的桥梁,同时兼顾了通信和同步。你可以创建带buffer和不带buffer的channel,来实现数据共享。那么,为什么我不提供一个充分利用Channels的解决方案,而不仅仅是用作同步呢?
查阅了一些标准库的top-level包,发现channels很少出现在函数签名中:
time
: 用于select timeout- reflect: …cause reflection
- fmt: for formatting it as a pointer
- builtin: expose the
close
function
io.Pipe
的实现中放弃了channel,而使用sync.Mutex
来安全的在reader和writer之间移动数据。我怀疑这是因为Channel的性能并不好,所以在这里才被Mutex替代。
当开发一个可重复利用的包的时候,我会像标准库一样在我公开的API中避免使用Channels,但是会在内部使用它们用作同步。如果复杂度足够的低,使用mutex替代channel也许更加理想。这也就是说,在程序开发中,channel是更完美的抽象,比lock更好使用,更加灵活。
抛砖迎玉
我在这里只是抛出了屈指可数的几种方法处理从io.Reader
获取的数据,毫无疑问,肯定还有更多的方法。Go的隐式接口模型(implicit interface model)+ 标准库的大量使用允许创造性的将不同组件组合而不用担心数据。我希望我在这里的一些探讨对你有所帮助,正如它们对我有用一样.
有疑问加站长微信联系(非本文作者)