在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

return

}

done

}()

go func() {

//transcode to WebM

webmr, err := transcode(pr)

if err != nil {

errs

return

}

//upload to storage

err = uploadFile(webmr)

if err != nil {

errs

return

}

done

}()

//wait until both are done

//or an error occurs

for c := 0; c < 2; {

select {

case err :=

return err

case

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

}

}()

// wait until all are done

// or an error occurs

for c := 0; c < 4; c++ {

select {

case err :=

return err

case

}

}

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)+ 标准库的大量使用允许创造性的将不同组件组合而不用担心数据。我希望我在这里的一些探讨对你有所帮助，正如它们对我有用一样.