目前,我開發(fā) HTTP 服務(wù), 用的是 beego框架, 方便了很多。
但是, 有時(shí)候,還是會遇到一些 特殊的場景。
比如: 過濾日志。
這應(yīng)該是一種典型的stream,同時(shí)數(shù)據(jù)量也適中, 不會有人,為了這個(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ù)到客戶端,該怎么辦呢?
首先,對于 這種簡單的 流數(shù)據(jù), golang 提供了一個(gè) 結(jié)構(gòu)。
pipeReader, pipeWriter := io.Pipe()
這個(gè)方法的原型是這樣的
func Pipe() (*PipeReader, *PipeWriter)
它返回緊密相連的一對 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 直接 對接了 日志輸出, 緩沖很小,
處理后的結(jié)果, 直接輸出到 http 客戶端。
尤其是第二點(diǎn),很重要,我在處理這個(gè)邏輯的時(shí)候, 發(fā)現(xiàn)服務(wù)器,有幾次意外崩潰,后來,才意識到,beego的controller 如果緩沖 處理后的數(shù)據(jù),有可能仍然占有大量內(nèi)存。
以上為個(gè)人經(jīng)驗(yàn),希望能給大家一個(gè)參考,也希望大家多多支持腳本之家。如有錯誤或未考慮完全的地方,望不吝賜教。
標(biāo)簽:保定 松原 河池 黔西 宜春 鷹潭 泰安 武漢
巨人網(wǎng)絡(luò)通訊聲明:本文標(biāo)題《golang HTTP 服務(wù)器 處理 日志/Stream流的操作》,本文關(guān)鍵詞 golang,HTTP,服務(wù)器,處理,日志,;如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問題,煩請?zhí)峁┫嚓P(guān)信息告之我們,我們將及時(shí)溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò),涉及言論、版權(quán)與本站無關(guān)。