問題場景:高頻系統中,agent 會向ATS 服務器發出刷新和預緩存的請求,這裏的請求head 裏面有GET ,PURGE等,由於通常的預緩存都是小文件,可是某天,忽然服務器oom。。。罪魁禍首發現是併發GET 大文件將服務器打死了。第一個版本是python 的,第二個版本是golang 實現的, 這裏記錄下兩種語言的 下載大文件的實現方式。python
該文章後續仍在不斷的更新修改中, 請移步到原文地址http://dmwan.ccgolang
第一種是python,使用的是request 庫, 使用流式讀取的方式,寫到空設備中去。緩存
res = self.session.request(method, url, data=body, headers=header, timeout=timeout, proxies=proxies, stream=True) with open("/dev/null", 'wb') as f: for chunk in res.iter_content(chunk_size=1024): if chunk: # filter out keep-alive new chunks f.write(chunk) f.flush()
第二種方式,對於golang ,使用io.Copy(), 將response copy 到空設備中。服務器
func downLoadFile(url string)(len int, err error){ //err write /dev/null: bad file descriptor# out, err := os.OpenFile("/dev/null", os.O_RDWR|os.O_CREATE|os.O_APPEND, 0666) defer out.Close() resp, err := http.Get(url) defer resp.Body.Close() n, err := io.Copy(out, resp.Body) return n, err }
使用這種方式爲何不會出現oom 的狀況?由於兩個緣由,第一個, resp.Body 只是個reader 並無發生真實的讀取操做,第二個是io.copy 這個函數設置了緩衝區大小限制爲3m,不會一次所有讀取到內存中,下面是標準庫的源碼:session
func Copy(dst Writer, src Reader) (written int64, err error) { return copyBuffer(dst, src, nil) } // copyBuffer is the actual implementation of Copy and CopyBuffer. // if buf is nil, one is allocated. func copyBuffer(dst Writer, src Reader, buf []byte) (written int64, err error) { // If the reader has a WriteTo method, use it to do the copy. // Avoids an allocation and a copy. if wt, ok := src.(WriterTo); ok { return wt.WriteTo(dst) } // Similarly, if the writer has a ReadFrom method, use it to do the copy. if rt, ok := dst.(ReaderFrom); ok { return rt.ReadFrom(src) } if buf == nil { buf = make([]byte, 32*1024) //這一步能夠控制每次緩衝區迭代的大小,默認大小是3m } for { nr, er := src.Read(buf) if nr > 0 { nw, ew := dst.Write(buf[0:nr]) if nw > 0 { written += int64(nw) } if ew != nil { err = ew break } if nr != nw { err = ErrShortWrite break } } if er != nil { if er != EOF { err = er } break } } return written, err }