go語言.buffer Go語言圣經(jīng)

可以用go語言成功執(zhí)行shutdown命令嗎？怎么做

import?(

十年專業(yè)網(wǎng)站設(shè)計(jì)公司歷程，堅(jiān)持以創(chuàng)新為先導(dǎo)的網(wǎng)站服務(wù)，服務(wù)超過上千家企業(yè)及個人，涉及網(wǎng)站設(shè)計(jì)、成都app軟件開發(fā)公司、微信開發(fā)、平面設(shè)計(jì)、互聯(lián)網(wǎng)整合營銷等多個領(lǐng)域。在不同行業(yè)和領(lǐng)域給人們的工作和生活帶來美好變化。

"bytes"

"fmt"

"os/exec"

)

func?exec_shell()?(string,?error){

//函數(shù)返回一個*Cmd，用于使用給出的參數(shù)執(zhí)行name指定的程序

cmd?:=?exec.Command("shutdown",?"-h","now")

//讀取io.Writer類型的cmd.Stdout，再通過bytes.Buffer(緩沖byte類型的緩沖器)將byte類型轉(zhuǎn)化為string類型(out.String():這是bytes類型提供的接口)

var?out?bytes.Buffer

cmd.Stdout?=?out

//Run執(zhí)行c包含的命令，并阻塞直到完成。??這里stdout被取出，cmd.Wait()無法正確獲取stdin,stdout,stderr，則阻塞在那了

err?:=?cmd.Run()

return?out.String(),?err

}

func?main(){

if?result,err:=exec_shell();err!=nil{

fmt.Println("error:",err)

}else{

fmt.Println("exec?succ?",?result)

}

}

Go語言基礎(chǔ)語法（一）

本文介紹一些Go語言的基礎(chǔ)語法。

先來看一個簡單的go語言代碼：

go語言的注釋方法：

代碼執(zhí)行結(jié)果：

下面來進(jìn)一步介紹go的基礎(chǔ)語法。

go語言中格式化輸出可以使用 fmt 和 log 這兩個標(biāo)準(zhǔn)庫，

常用方法：

示例代碼：

執(zhí)行結(jié)果：

更多格式化方法可以訪問中的fmt包。

log包實(shí)現(xiàn)了簡單的日志服務(wù)，也提供了一些格式化輸出的方法。

執(zhí)行結(jié)果：

下面來介紹一下go的數(shù)據(jù)類型

下表列出了go語言的數(shù)據(jù)類型：

int、float、bool、string、數(shù)組和struct屬于值類型，這些類型的變量直接指向存在內(nèi)存中的值；slice、map、chan、pointer等是引用類型，存儲的是一個地址，這個地址存儲最終的值。

常量是在程序編譯時(shí)就確定下來的值，程序運(yùn)行時(shí)無法改變。

執(zhí)行結(jié)果：

執(zhí)行結(jié)果：

Go 語言的運(yùn)算符主要包括算術(shù)運(yùn)算符、關(guān)系運(yùn)算符、邏輯運(yùn)算符、位運(yùn)算符、賦值運(yùn)算符以及指針相關(guān)運(yùn)算符。

算術(shù)運(yùn)算符：

關(guān)系運(yùn)算符：

邏輯運(yùn)算符：

位運(yùn)算符：

賦值運(yùn)算符：

指針相關(guān)運(yùn)算符：

下面介紹一下go語言中的if語句和switch語句。另外還有一種控制語句叫select語句，通常與通道聯(lián)用，這里不做介紹。

if語法格式如下：

if ... else ：

else if：

示例代碼：

語法格式：

另外，添加 fallthrough 會強(qiáng)制執(zhí)行后面的 case 語句，不管下一條case語句是否為true。

示例代碼：

執(zhí)行結(jié)果：

下面介紹幾種循環(huán)語句：

執(zhí)行結(jié)果：

執(zhí)行結(jié)果：

也可以通過標(biāo)記退出循環(huán)：

--THE END--

如何用go語言每分鐘處理100萬個請求

在Malwarebytes 我們經(jīng)歷了顯著的增長，自從我一年前加入了硅谷的公司，一個主要的職責(zé)成了設(shè)計(jì)架構(gòu)和開發(fā)一些系統(tǒng)來支持一個快速增長的信息安全公司和所有需要的設(shè)施來支持一個每天百萬用戶使用的產(chǎn)品。我在反病毒和反惡意軟件行業(yè)的不同公司工作了12年，從而我知道由于我們每天處理大量的數(shù)據(jù)，這些系統(tǒng)是多么復(fù)雜。

有趣的是，在過去的大約9年間，我參與的所有的web后端的開發(fā)通常是通過Ruby on Rails技術(shù)實(shí)現(xiàn)的。不要錯怪我。我喜歡Ruby on Rails，并且我相信它是個令人驚訝的環(huán)境。但是一段時(shí)間后，你會開始以ruby的方式開始思考和設(shè)計(jì)系統(tǒng)，你會忘記，如果你可以利用多線程、并行、快速執(zhí)行和小內(nèi)存開銷，軟件架構(gòu)本來應(yīng)該是多么高效和簡單。很多年期間，我是一個c/c++、Delphi和c#開發(fā)者，我剛開始意識到使用正確的工具可以把復(fù)雜的事情變得簡單些。

作為首席架構(gòu)師，我不會很關(guān)心在互聯(lián)網(wǎng)上的語言和框架戰(zhàn)爭。我相信效率、生產(chǎn)力。代碼可維護(hù)性主要依賴于你如何把解決方案設(shè)計(jì)得很簡單。

問題

當(dāng)工作在我們的匿名遙測和分析系統(tǒng)中，我們的目標(biāo)是可以處理來自于百萬級別的終端的大量的POST請求。web處理服務(wù)可以接收包含了很多payload的集合的JSON數(shù)據(jù)，這些數(shù)據(jù)需要寫入Amazon S3中。接下來，map-reduce系統(tǒng)可以操作這些數(shù)據(jù)。

按照習(xí)慣，我們會調(diào)研服務(wù)層級架構(gòu)，涉及的軟件如下：

Sidekiq

Resque

DelayedJob

Elasticbeanstalk Worker Tier

RabbitMQ

and so on…

搭建了2個不同的集群，一個提供web前端，另外一個提供后端處理，這樣我們可以橫向擴(kuò)展后端服務(wù)的數(shù)量。

但是，從剛開始，在 討論階段我們的團(tuán)隊(duì)就知道我們應(yīng)該使用Go，因?yàn)槲覀兛吹竭@會潛在性地成為一個非常龐大（ large traffic）的系統(tǒng)。我已經(jīng)使用了Go語言大約2年時(shí)間，我們開發(fā)了幾個系統(tǒng)，但是很少會達(dá)到這樣的負(fù)載（amount of load）。

我們開始創(chuàng)建一些結(jié)構(gòu)，定義從POST調(diào)用得到的web請求負(fù)載，還有一個上傳到S3 budket的函數(shù)。

type PayloadCollection struct {

WindowsVersion string `json:"version"`

Token string `json:"token"`

Payloads []Payload `json:"data"`

}

type Payload struct {

// [redacted]

}

func (p *Payload) UploadToS3() error {

// the storageFolder method ensures that there are no name collision in

// case we get same timestamp in the key name

storage_path := fmt.Sprintf("%v/%v", p.storageFolder, time.Now().UnixNano())

bucket := S3Bucket

b := new(bytes.Buffer)

encodeErr := json.NewEncoder(b).Encode(payload)

if encodeErr != nil {

return encodeErr

}

// Everything we post to the S3 bucket should be marked 'private'

var acl = s3.Private

var contentType = "application/octet-stream"

return bucket.PutReader(storage_path, b, int64(b.Len()), contentType, acl, s3.Options{})

}

本地Go routines方法

剛開始，我們采用了一個非常本地化的POST處理實(shí)現(xiàn)，僅僅嘗試把發(fā)到簡單go routine的job并行化：

func payloadHandler(w http.ResponseWriter, r *http.Request) {

if r.Method != "POST" {

w.WriteHeader(http.StatusMethodNotAllowed)

return

}

// Read the body into a string for json decoding

var content = PayloadCollection{}

err := json.NewDecoder(io.LimitReader(r.Body, MaxLength)).Decode(content)

if err != nil {

w.Header().Set("Content-Type", "application/json; charset=UTF-8")

w.WriteHeader(http.StatusBadRequest)

return

}

// Go through each payload and queue items individually to be posted to S3

for _, payload := range content.Payloads {

go payload.UploadToS3() // ----- DON'T DO THIS

}

w.WriteHeader(http.StatusOK)

}

對于中小負(fù)載，這會對大多數(shù)的人適用，但是大規(guī)模下，這個方案會很快被證明不是很好用。我們期望的請求數(shù)，不在我們剛開始計(jì)劃的數(shù)量級，當(dāng)我們把第一個版本部署到生產(chǎn)環(huán)境上。我們完全低估了流量。

上面的方案在很多地方很不好。沒有辦法控制我們產(chǎn)生的go routine的數(shù)量。由于我們收到了每分鐘1百萬的POST請求，這段代碼很快就崩潰了。

再次嘗試

我們需要找一個不同的方式。自開始我們就討論過， 我們需要保持請求處理程序的生命周期很短，并且進(jìn)程在后臺產(chǎn)生。當(dāng)然，這是你在Ruby on Rails的世界里必須要做的事情，否則你會阻塞在所有可用的工作 web處理器上，不管你是使用puma、unicore還是passenger（我們不要討論JRuby這個話題）。然后我們需要利用常用的處理方案來做這些，比如Resque、 Sidekiq、 SQS等。這個列表會繼續(xù)保留，因?yàn)橛泻芏嗟姆桨缚梢詫?shí)現(xiàn)這些。

所以，第二次迭代，我們創(chuàng)建了一個緩沖channel，我們可以把job排隊(duì)，然后把它們上傳到S3。因?yàn)槲覀兛梢钥刂莆覀冴?duì)列中的item最大值，我們有大量的內(nèi)存來排列job，我們認(rèn)為只要把job在channel里面緩沖就可以了。

var Queue chan Payload

func init() {

Queue = make(chan Payload, MAX_QUEUE)

}

func payloadHandler(w http.ResponseWriter, r *http.Request) {

...

// Go through each payload and queue items individually to be posted to S3

for _, payload := range content.Payloads {

Queue - payload

}

...

}

接下來，我們再從隊(duì)列中取job，然后處理它們。我們使用類似于下面的代碼：

func StartProcessor() {

for {

select {

case job := -Queue:

job.payload.UploadToS3() // -- STILL NOT GOOD

}

}

}

說實(shí)話，我不知道我們在想什么。這肯定是一個滿是Red-Bulls的夜晚。這個方法不會帶來什么改善，我們用了一個 有缺陷的緩沖隊(duì)列并發(fā)，僅僅是把問題推遲了。我們的同步處理器同時(shí)僅僅會上傳一個數(shù)據(jù)到S3，因?yàn)閬淼降恼埱筮h(yuǎn)遠(yuǎn)大于單核處理器上傳到S3的能力，我們的帶緩沖channel很快達(dá)到了它的極限，然后阻塞了請求處理邏輯的queue更多item的能力。

我們僅僅避免了問題，同時(shí)開始了我們的系統(tǒng)掛掉的倒計(jì)時(shí)。當(dāng)部署了這個有缺陷的版本后，我們的延時(shí)保持在每分鐘以常量增長。

最好的解決方案

我們討論過在使用用Go channel時(shí)利用一種常用的模式，來創(chuàng)建一個二級channel系統(tǒng)，一個來queue job，另外一個來控制使用多少個worker來并發(fā)操作JobQueue。

想法是，以一個恒定速率并行上傳到S3，既不會導(dǎo)致機(jī)器崩潰也不好產(chǎn)生S3的連接錯誤。這樣我們選擇了創(chuàng)建一個Job/Worker模式。對于那些熟悉Java、C#等語言的開發(fā)者，可以把這種模式想象成利用channel以golang的方式來實(shí)現(xiàn)了一個worker線程池，作為一種替代。

var (

MaxWorker = os.Getenv("MAX_WORKERS")

MaxQueue = os.Getenv("MAX_QUEUE")

)

// Job represents the job to be run

type Job struct {

Payload Payload

}

// A buffered channel that we can send work requests on.

var JobQueue chan Job

// Worker represents the worker that executes the job

type Worker struct {

WorkerPool chan chan Job

JobChannel chan Job

quit chan bool

}

func NewWorker(workerPool chan chan Job) Worker {

return Worker{

WorkerPool: workerPool,

JobChannel: make(chan Job),

quit: make(chan bool)}

}

// Start method starts the run loop for the worker, listening for a quit channel in

// case we need to stop it

func (w Worker) Start() {

go func() {

for {

// register the current worker into the worker queue.

w.WorkerPool - w.JobChannel

select {

case job := -w.JobChannel:

// we have received a work request.

if err := job.Payload.UploadToS3(); err != nil {

log.Errorf("Error uploading to S3: %s", err.Error())

}

case -w.quit:

// we have received a signal to stop

return

}

}

}()

}

// Stop signals the worker to stop listening for work requests.

func (w Worker) Stop() {

go func() {

w.quit - true

}()

}

我們已經(jīng)修改了我們的web請求handler，用payload創(chuàng)建一個Job實(shí)例，然后發(fā)到JobQueue channel，以便于worker來獲取。

func payloadHandler(w http.ResponseWriter, r *http.Request) {

if r.Method != "POST" {

w.WriteHeader(http.StatusMethodNotAllowed)

return

}

// Read the body into a string for json decoding

var content = PayloadCollection{}

err := json.NewDecoder(io.LimitReader(r.Body, MaxLength)).Decode(content)

if err != nil {

w.Header().Set("Content-Type", "application/json; charset=UTF-8")

w.WriteHeader(http.StatusBadRequest)

return

}

// Go through each payload and queue items individually to be posted to S3

for _, payload := range content.Payloads {

// let's create a job with the payload

work := Job{Payload: payload}

// Push the work onto the queue.

JobQueue - work

}

w.WriteHeader(http.StatusOK)

}

在web server初始化時(shí)，我們創(chuàng)建一個Dispatcher，然后調(diào)用Run()函數(shù)創(chuàng)建一個worker池子，然后開始監(jiān)聽JobQueue中的job。

dispatcher := NewDispatcher(MaxWorker)

dispatcher.Run()

下面是dispatcher的實(shí)現(xiàn)代碼：

type Dispatcher struct {

// A pool of workers channels that are registered with the dispatcher

WorkerPool chan chan Job

}

func NewDispatcher(maxWorkers int) *Dispatcher {

pool := make(chan chan Job, maxWorkers)

return Dispatcher{WorkerPool: pool}

}

func (d *Dispatcher) Run() {

// starting n number of workers

for i := 0; i d.maxWorkers; i++ {

worker := NewWorker(d.pool)

worker.Start()

}

go d.dispatch()

}

func (d *Dispatcher) dispatch() {

for {

select {

case job := -JobQueue:

// a job request has been received

go func(job Job) {

// try to obtain a worker job channel that is available.

// this will block until a worker is idle

jobChannel := -d.WorkerPool

// dispatch the job to the worker job channel

jobChannel - job

}(job)

}

}

}

注意到，我們提供了初始化并加入到池子的worker的最大數(shù)量。因?yàn)檫@個工程我們利用了Amazon Elasticbeanstalk帶有的docker化的Go環(huán)境，所以我們常常會遵守12-factor方法論來配置我們的生成環(huán)境中的系統(tǒng)，我們從環(huán)境變了讀取這些值。這種方式，我們控制worker的數(shù)量和JobQueue的大小，所以我們可以很快的改變這些值，而不需要重新部署集群。

var (

MaxWorker = os.Getenv("MAX_WORKERS")

MaxQueue = os.Getenv("MAX_QUEUE")

)

直接結(jié)果

我們部署了之后，立馬看到了延時(shí)降到微乎其微的數(shù)值，并未我們處理請求的能力提升很大。

Elastic Load Balancers完全啟動后，我們看到ElasticBeanstalk 應(yīng)用服務(wù)于每分鐘1百萬請求。通常情況下在上午時(shí)間有幾個小時(shí)，流量峰值超過每分鐘一百萬次。

我們一旦部署了新的代碼，服務(wù)器的數(shù)量從100臺大幅 下降到大約20臺。

我們合理配置了我們的集群和自動均衡配置之后，我們可以把服務(wù)器的數(shù)量降至4x EC2 c4.Large實(shí)例，并且Elastic Auto-Scaling設(shè)置為如果CPU達(dá)到5分鐘的90%利用率，我們就會產(chǎn)生新的實(shí)例。

總結(jié)

在我的書中，簡單總是獲勝。我們可以使用多隊(duì)列、后臺worker、復(fù)雜的部署設(shè)計(jì)一個復(fù)雜的系統(tǒng)，但是我們決定利用Elasticbeanstalk 的auto-scaling的能力和Go語言開箱即用的特性簡化并發(fā)。

我們僅僅用了4臺機(jī)器，這并不是什么新鮮事了?？赡芩鼈冞€不如我的MacBook能力強(qiáng)大，但是卻處理了每分鐘1百萬的寫入到S3的請求。

處理問題有正確的工具。當(dāng)你的 Ruby on Rails 系統(tǒng)需要更強(qiáng)大的web handler時(shí)，可以考慮下ruby生態(tài)系統(tǒng)之外的技術(shù)，或許可以得到更簡單但更強(qiáng)大的替代方案。

Go語言中的字節(jié)序

Go中的binary包實(shí)現(xiàn)了簡單的數(shù)字與字節(jié)序列的轉(zhuǎn)換以及變長值的編解碼

package main

import ( "fmt" "bytes" "encoding/binary" ) func main(){ n := 0x12345678 bytesBuffer := bytes.NewBuffer([]byte{}) //BigEndian 大端順序存儲 LittleEndian小端順序存儲 binary.Write(bytesBuffer, binary.BigEndian, int32(n)) data:=bytesBuffer.Bytes() fmt.Printf("[0]: %#x addr:%#x\n",data[0],data[0]) fmt.Printf("[0]: %#x addr:%#x\n",data[1],data[1]) fmt.Printf("[0]: %#x addr:%#x\n",data[2],data[2]) fmt.Printf("[0]: %#x addr:%#x\n",data[3],data[3]) }

輸出

[0]: 0x12 addr:0xc042010248 [1]: 0x34 addr:0xc042010249 [2]: 0x56 addr:0xc04201024a [3]: 0x78 addr:0xc04201024b

也可以使用下面的方式

n := 0x12345678 var data []byte = make([]byte,4) //操作的都是無符號整型 binary.BigEndian.PutUint32(data,uint32(n))

可以使用下面的方式判斷當(dāng)前系統(tǒng)的字節(jié)序類型

const INT_SIZE int = int(unsafe.Sizeof(0))

//判斷我們系統(tǒng)中的字節(jié)序類型 func systemEdian() { var i int = 0x1 bs := (*[INT_SIZE]byte)(unsafe.Pointer(i)) if bs[0] == 0 { fmt.Println("system edian is little endian") } else { fmt.Println("system edian is big endian") } }

go語言string之Buffer與Builder

操作字符串離不開字符串的拼接，但是Go中string是只讀類型，大量字符串的拼接會造成性能問題。

拼接字符串，無外乎四種方式，采用“+”，“fmt.Sprintf()”,"bytes.Buffer","strings.Builder"

上面我們創(chuàng)建10萬字符串拼接的測試，可以發(fā)現(xiàn)"bytes.Buffer","strings.Builder"的性能最好，約是“+”的1000倍級別。

這是由于string是不可修改的，所以在使用“+”進(jìn)行拼接字符串，每次都會產(chǎn)生申請空間，拼接，復(fù)制等操作，數(shù)據(jù)量大的情況下非常消耗資源和性能。而采用Buffer等方式，都是預(yù)先計(jì)算拼接字符串?dāng)?shù)組的總長度（如果可以知道長度），申請空間，底層是slice數(shù)組，可以以append的形式向后進(jìn)行追加。最后在轉(zhuǎn)換為字符串。這申請了不斷申請空間的操作，也減少了空間的使用和拷貝的次數(shù)，自然性能也高不少。

bytes.buffer是一個緩沖byte類型的緩沖器存放著都是byte

是一個變長的 buffer，具有 Read 和Write 方法。 Buffer 的 零值 是一個 空的 buffer，但是可以使用，底層就是一個 []byte， 字節(jié)切片。

向Buffer中寫數(shù)據(jù)，可以看出Buffer中有個Grow函數(shù)用于對切片進(jìn)行擴(kuò)容。

從Buffer中讀取數(shù)據(jù)

strings.Builder的方法和bytes.Buffer的方法的命名幾乎一致。

但實(shí)現(xiàn)并不一致，Builder的Write方法直接將字符拼接slice數(shù)組后。

其沒有提供read方法，但提供了strings.Reader方式

Reader 結(jié)構(gòu):

Buffer:

Builder:

可以看出Buffer和Builder底層都是采用[]byte數(shù)組進(jìn)行裝載數(shù)據(jù)。

先來說說Buffer:

創(chuàng)建好Buffer是一個empty的，off 用于指向讀寫的尾部。

在寫的時(shí)候，先判斷當(dāng)前寫入字符串長度是否大于Buffer的容量，如果大于就調(diào)用grow進(jìn)行擴(kuò)容，擴(kuò)容申請的長度為當(dāng)前寫入字符串的長度。如果當(dāng)前寫入字符串長度小于最小字節(jié)長度64，直接創(chuàng)建64長度的[]byte數(shù)組。如果申請的長度小于二分之一總?cè)萘繙p去當(dāng)前字符總長度，說明存在很大一部分被使用但已讀，可以將未讀的數(shù)據(jù)滑動到數(shù)組頭。如果容量不足，擴(kuò)展2*c + n 。

其String()方法就是將字節(jié)數(shù)組強(qiáng)轉(zhuǎn)為string

Builder是如何實(shí)現(xiàn)的。

Builder采用append的方式向字節(jié)數(shù)組后添加字符串。

從上面可以看出，[]byte的內(nèi)存大小也是以倍數(shù)進(jìn)行申請的，初始大小為 0，第一次為大于當(dāng)前申請的最大 2 的指數(shù)，不夠進(jìn)行翻倍.

可以看出如果舊容量小于1024進(jìn)行翻倍，否則擴(kuò)展四分之一。（2048 byte 后，申請策略的調(diào)整）。

其次String()方法與Buffer的string方法也有明顯區(qū)別。Buffer的string是一種強(qiáng)轉(zhuǎn)，我們知道在強(qiáng)轉(zhuǎn)的時(shí)候是需要進(jìn)行申請空間，并拷貝的。而Builder只是指針的轉(zhuǎn)換。

這里我們解析一下 *(*string)(unsafe.Pointer(b.buf)) 這個語句的意思。

先來了解下unsafe.Pointer 的用法。

也就是說，unsafe.Pointer 可以轉(zhuǎn)換為任意類型，那么意味著，通過unsafe.Pointer媒介，程序繞過類型系統(tǒng)，進(jìn)行地址轉(zhuǎn)換而不是拷貝。

即*A = Pointer = *B

就像上面例子一樣，將字節(jié)數(shù)組轉(zhuǎn)為unsafe.Pointer類型，再轉(zhuǎn)為string類型，s和b中內(nèi)容一樣，修改b,s也變了，說明b和s是同一個地址。但是對s重新賦值后，意味著s的地址指向了“WORLD”,它們所使用的內(nèi)存空間不同了，所以s改變后，b并不會改變。

所以他們的區(qū)別就在于 bytes.Buffer 是重新申請了一塊空間，存放生成的string變量， 而strings.Builder直接將底層的[]byte轉(zhuǎn)換成了string類型返回了回來，去掉了申請空間的操作。

我正在學(xué)習(xí)Go語言網(wǎng)絡(luò)編程部分，太抽象了有點(diǎn)看不懂啊，哪位大神能夠通俗易懂給我解釋下這個代碼的意思啊

本質(zhì)上，是作為文件處理的，發(fā)送是“write，print”，接受是“read”。

連接相當(dāng)于打開文件。

網(wǎng)站欄目：go語言.buffer Go語言圣經(jīng)
標(biāo)題來源：http://m.jiaotiyi.com/article/hjgsei.html