作者：林冠巨集 / 指尖下的幽靈

關於 server.go 原始碼的解析可以去搜下，已經有很多且還不錯的文章。

正文：

從我們啟動http.ListenAndServe(port,router)開始，server.go 內部最終在一個for 迴圈中的 accept 方法中不停地等待客戶端的連線到來。

每接收到一個accept 就啟動一個 gorutine 去處理當前ip的連線。也就是原始碼裡的go c.serve(ctx)。這一個步驟在 c.serve(ctx) 它並不是簡單的形式：

請求-->處理請求-->返回結果-->斷開這個連線-->結束當前的 gorutine

根據我的除錯結果與原始碼分析顯示，正確的形式是下面這樣的：

1. 為每一個連線的使用者啟動了一個長連線，serve 方法內部有個超時的設定是c.rwc.SetReadDeadline(time.Time{})，這樣子的情況，如果內部不出錯，當前的連線斷開的條件是客戶端自己斷開，或nat超時。

2. 這個連線建立後，以ip為單位，當前的客戶端，此時它的所有http請求，例如get，post，它們都會在這個啟動的gorutine 內進行分發與被處理。

3. 也就是說，同一個ip，多個不同的請求，這裡不會觸發另一個 accept，不會再去啟動一個go c.serve(ctx)

上述我們得出結論：

1. 如果有 100萬

   個 accept，就證明有100萬個連線，100萬個ip與當前server連線。即是我們說的百萬連線

2. 百萬連線 不是百萬請求

3. 每一個連線，它可以進行多個http請求，它的請求都在當前啟動這個連線的gorutine裡面進行。

4. c.serve(...) 原始碼中的for 死迴圈就是負責讀取每個請求再分發

for {
    w, err := c.readRequest(ctx) // 讀取一個 http 請求
    //...
    ServeHTTP(...)
}

1. 我們的100萬 連線裡面，有可能併發更多的請求，例如幾百萬請求，一個客戶端快速呼叫多個請求api

圖解總結

結合 master-worker 併發模式

根據我們上面的分析，每一個新連線到來，go 就會啟動一個 gorutine，在原始碼裡面也沒有看到有一個量級的限制，也就是達到多少連線就不再接收。我們也知道，伺服器是有處理瓶頸的。

所以，在這裡插播一個優化點，就是在server.go 內部做一個連線數目的限制。

master-worker 模式本身是啟動多個worker 執行緒，去併發讀取有界佇列裡面的任務，並執行。

我自身已經實現了一個go版本的master-worker，做過下面的嘗試：

1. 在 go c.serve(ctx) 處做修改，如下。

if srv.masterWorkerModel {
    // lgh --- way to execute
    PoolMaster.AddJob(
        masterworker.Job{
            Tag:" http server ",
            Handler: func() {
                c.serve(ctx)
                fmt.Println("finish job") // 這一句在當前 ip 斷開連線後才會輸出
            },
        })
}else{
    go c.serve(ctx)
}

func (m Master) AddJob(job Job)  {
    fmt.Println("add a job ")
    m.JobQueue <- job // jobQueue 是具備緩衝的
}

// worker
func (w Worker) startWork(master *Master)  {
    go func() {
        for {
            select {
                case job := <-master.JobQueue:
                    job.doJob(master)
            }
        }
    }()
}

// job
func (j Job) doJob(master *Master) {
    go func() {
        fmt.Println(j.Tag+" --- doing job...")
        j.Handler()
    }()
}

不難理解它的模式。

現在我們使用生產者--消費者模式進行假設，連線的產生是生產者，<-master.JobQueue 是消費者，因為每一次消費就是啟動一個處理的gorutine。

因為我們在accept 一個請求到<-master.JobQueue，管道輸出一個的這個過程中，可以說是沒有耗時操作的，這個job，它很快就被輸出了管道。也就是說，消費很快，那麼實際的生產環境中，我們的worker工作協程啟動5~10個就有餘了。

考慮如果出現了消費跟不上的情況，那麼多出來的job將會被緩衝到channel裡面。這種情況可能出現的情景是：

短時間十萬+級別連線的建立，就會導致worker讀取不過來。不過，即使發生了，也是很快就取完的。因為間中的耗時幾乎可以忽略不計！

也就說，短時間大量連線的建立，它的瓶頸在佇列的緩衝數。但是即使瓶頸發生了，它又能很快被分發處理掉。所以說：

• 我的這個第一點的嘗試的意義事實上沒有多大的。只不過是換了一種方式去分發go c.serve(ctx)。

1. 這個是第二種結合方式，把master-worker放置到ServeHTTP的分發階段。例如下面程式碼，是常見的http handler寫法，我們就可以巢狀進去。

func (x XHandler) ServeHTTP(w http.ResponseWriter, r *http.Request)  {
    //...
    if x.MasterWorker {
        poolMaster.AddJob(master_worker.Job{
            Tag:"normal",
            XContext:xc,
            Handler: func(context model.XContext) {
                x.HandleFunc(w,r)
            },
        })
        return
    }
    x.HandleFunc(w,r)
    //...
}

這樣的話，我們就能控制所有連線的併發請求最大數。超出的將會進行排隊，等待被執行，而不會因為短時間 http 請求數目不受控暴增 而導致伺服器掛掉。

此外上述第二種還存在一個：讀，過早關閉問題，這個留給讀者嘗試解決。