目前，我開發(fā) HTTP 服務(wù)， 用的是 beego框架， 方便了很多。

但是， 有時(shí)候，還是會(huì)遇到一些 特殊的場(chǎng)景。

比如： 過濾日志。

這應(yīng)該是一種典型的stream，同時(shí)數(shù)據(jù)量也適中， 不會(huì)有人，為了這個(gè)， 就用一些很重的框架。

可以這樣直觀的描述這個(gè) 邏輯

其他組件 產(chǎn)生 log
||
\ /
我的組件，業(yè)務(wù)處理
||
\ /
用戶， http client

這種情景下， 有幾個(gè)特殊點(diǎn)：

1. 難以用 string，或者 byte 數(shù)組 收集數(shù)據(jù)

2. 數(shù)據(jù)Source 端，不斷的有數(shù)據(jù)產(chǎn)生

3. 數(shù)據(jù)緩沖，如果占有的 內(nèi)存太多， 可能導(dǎo)致 服務(wù)崩潰

通常情況下，我們準(zhǔn)備好數(shù)據(jù)， 然后調(diào)用Beego框架的方法，將數(shù)據(jù)發(fā)送到客戶端，就不管了。

而如果，我們需要根據(jù)處理的情況，多次寫數(shù)據(jù)到客戶端，該怎么辦呢？

首先，對(duì)于 這種簡(jiǎn)單的 流數(shù)據(jù)， golang 提供了一個(gè) 結(jié)構(gòu)。

pipeReader, pipeWriter := io.Pipe()

這個(gè)方法的原型是這樣的

func Pipe() (*PipeReader, *PipeWriter)

它返回緊密相連的一對(duì) Reader 和 Writer。 他們的“生命周期”相同。

任何 寫到 Writer中的數(shù)據(jù)， 直接流到了Reader中。這個(gè) 和 Linux 命令行中 “管道 |” 很像。

我們先開個(gè)goroutine 接收 日志數(shù)據(jù)

 go func () {
 for {
 var log []byte
 //log = 
 pipeWriter.Write(log)
 
 //break;
 }
 pipeWriter.CloseWithError(io.EOF)
 }

主邏輯中， 處理日志

 defer pipeReader.Close()
 rr := bufio.NewReader(io.Reader(pipeReader))
 for {

 line, err := rr.ReadBytes('\n')
 if io.EOF == err {
 break
 }
........
 }

最后， 輸出到客戶端

var out []byte
ctl.Ctx.ResponseWriter.Write(out)
ctl.Ctx.ResponseWriter.Flush()

總結(jié)：

iopipe 直接 對(duì)接了 日志輸出， 緩沖很小，

處理后的結(jié)果， 直接輸出到 http 客戶端。

尤其是第二點(diǎn)，很重要，我在處理這個(gè)邏輯的時(shí)候， 發(fā)現(xiàn)服務(wù)器，有幾次意外崩潰，后來，才意識(shí)到，beego的controller 如果緩沖 處理后的數(shù)據(jù)，有可能仍然占有大量?jī)?nèi)存。

以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。如有錯(cuò)誤或未考慮完全的地方，望不吝賜教。

最新評(píng)論