5分鐘搞懂 Golang 資料庫連線管理

俞凡發表於2024-11-13
本文介紹瞭如何在 Golang 中最佳化資料庫連線,透過有效管理連線來提高應用程式吞吐量。原文: Optimizing Database Connections in Go: Improving Throughput by Managing Open Connections Efficiently

Go 的 database/sql 軟體包提供了自動化資料庫連線池,能夠幫助開發人員有效管理連線。通常情況下,開發人員會請求某個開啟的連線,執行查詢,然後關閉連線以確保連線返回到池中。

開發人員常犯的一個錯誤是長時間持有資料庫連線,從而導致效能瓶頸。新請求不得不等待可用連線,造成連線池的效率受到影響。

本文將探討如何避免這一問題,並透過確定常見問題域和學習解決方法,最佳化 Go 應用以提高吞吐量。

基本示例

我們以一個返回僱員記錄的基本 HTTP 處理程式為例:

func GetEmployeesHandler(w http.ResponseWriter, r *http.Request) {
    rows, err := db.Query(`SELECT id, name, email FROM employee`)
    if err != nil {
        http.Error(w, fmt.Sprintf("error querying database: %v", err), http.StatusInternalServerError)
        return
    }
    defer rows.Close()

    var employees []Employee
    for rows.Next() {
        var e Employee
        if err := rows.Scan(&e.ID, &e.Name, &e.Email); err != nil {
            http.Error(w, fmt.Sprintf("Error scanning row: %v", err), http.StatusInternalServerError)
            return
        }
        decorateEmployee(&e)
        employees = append(employees, e)
    }

    if err = rows.Err(); err != nil {
        http.Error(w, fmt.Sprintf("error during row iteration: %v", err), http.StatusInternalServerError)
        return
    }

    w.Header().Set("Content-Type", "application/json")
    if err := json.NewEncoder(w).Encode(employees); err != nil {
        http.Error(w, "Error encoding response", http.StatusInternalServerError)
        return
    }
}

在這個處理程式中:

  • 查詢資料庫中的僱員記錄。
  • 透過 defer rows.Close() 確保在處理完結果集後關閉連線。
  • 掃描每一行,並用從外部獲取的資料對其進行裝飾。
  • 將最終結果追加到陣列中。
  • 檢查迭代過程中的任何錯誤,並以 JSON 格式返回結果。

乍一看,似乎沒有什麼特別的地方。不過,你會期待在壓力測試的時候獲得更好的效能。

初步效能結果

使用 Vegeta 等壓力測試工具,可以模擬該端點的負載情況。在每秒 10 個請求(RPS,requests per second)的初始速率下,應用在 30 秒的測試執行中表現相對較好:

$ echo "GET http://localhost:8080/employees" | vegeta attack -duration=30s -rate=10 | tee results.bin | vegeta report
Requests      [total, rate, throughput]         300, 10.03, 5.45
Duration      [total, attack, wait]             52.095s, 29.9s, 22.196s
Latencies     [min, mean, 50, 90, 95, 99, max]  2.318s, 11.971s, 8.512s, 26.222s, 30.001s, 30.001s, 30.001s
Bytes In      [total, mean]                     2290991, 7636.64
Bytes Out     [total, mean]                     0, 0.00
Success       [ratio]                           94.67%
Status Codes  [code:count]                      0:16  200:284

然而,當我們將負載增加到 50 RPS 時,就會發現吞吐量大幅下降,請求失敗率急劇上升:

$ echo "GET http://localhost:8080/employees" | vegeta attack -duration=30s -rate=50 | tee results.bin | vegeta report
Requests      [total, rate, throughput]         1500, 50.03, 4.20
Duration      [total, attack, wait]             59.981s, 29.981s, 30s
Latencies     [min, mean, 50, 90, 95, 99, max]  2.208s, 27.175s, 30.001s, 30.001s, 30.001s, 30.002s, 30.002s
Bytes In      [total, mean]                     2032879, 1355.25
Bytes Out     [total, mean]                     0, 0.00
Success       [ratio]                           16.80%
Status Codes  [code:count]                      0:1248  200:252

(上述狀態程式碼為 0 表示測試執行過程中出現客戶端超時)

定位瓶頸

當 RPS 為 50 時,成功率急劇下降,吞吐量降至每秒僅 4.2 個請求。為什麼會這樣?其中一個可能的原因是,考慮到當前資源,50 RPS 是一個不合理的目標。為了確認程式碼是否可以透過修改獲得更好的效能,我們可以研究收集一些指標。其中一個指標來源是裝飾過程,但在本文中,我們將重點關注資料庫連線池統計資料。

Go 的 database/sql 軟體包可透過 DBStats 函式檢視應用的資料庫池效能,會返回我們感興趣的統計資訊:

  • InUse: 當前正在使用的連線數。
  • Idle:空閒連線數。
  • WaitCount:等待的連線總數。

可以透過新增另一個端點處理程式來輸出這些值:

func GetInfoHandler(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Content-Type", "application/json")
    if err := json.NewEncoder(w).Encode(db.Stats()); err != nil {
        http.Error(w, "Error encoding response", http.StatusInternalServerError)
        return
    }
}

重新執行上述壓力測試,並對 /info 端點進行監控:

$ while true; do curl -s http://localhost:8080/info; sleep 2; done
...
{"MaxOpenConnections":15,"OpenConnections":15,"InUse":15,"Idle":0,"WaitCount":1434,"WaitDuration":1389188829869,"MaxIdleClosed":0,"MaxIdleTimeClosed":0,"MaxLifetimeClosed":0}
{"MaxOpenConnections":15,"OpenConnections":15,"InUse":15,"Idle":0,"WaitCount":1485,"WaitDuration":1582086078604,"MaxIdleClosed":0,"MaxIdleTimeClosed":0,"MaxLifetimeClosed":0}
{"MaxOpenConnections":15,"OpenConnections":15,"InUse":15,"Idle":0,"WaitCount":1485,"WaitDuration":1772844971842,"MaxIdleClosed":0,"MaxIdleTimeClosed":0,"MaxLifetimeClosed":0}
...

上述結果表明連線池已達到最大值(InUse: 15, Idle: 0),每個新請求都被迫等待(WaitCount 不斷增加)。換句話說,連線池基本上處於停滯狀態,從而導致了之前觀察到的延遲和超時問題!

最佳化連線使用

檢視原始程式碼,我們發現問題要麼出在查詢本身效能不佳,要麼出在遍歷結果集時每次呼叫裝飾函式都需要很長時間才能返回。可以嘗試在 rows.Next() 迴圈之外裝飾記錄,並將其移至資料庫連線使用之下,從而找出問題所在。

以下是更新後的程式碼:

func GetEmployeesHandler(w http.ResponseWriter, r *http.Request) {
    rows, err := db.Query(`SELECT id, name, email FROM employee`)
    if err != nil {
        http.Error(w, fmt.Sprintf("error querying database: %v", err), http.StatusInternalServerError)
        return
    }

    var employees []Employee
    for rows.Next() {
        var e Employee
        if err := rows.Scan(&e.ID, &e.Name, &e.Email); err != nil {
            http.Error(w, fmt.Sprintf("Error scanning row: %v", err), http.StatusInternalServerError)
            return
        }
        employees = append(employees, e)
    }

    if err = rows.Err(); err != nil {
        http.Error(w, fmt.Sprintf("error during row iteration: %v", err), http.StatusInternalServerError)
        return
    }
    rows.Close()

    for i := range employees {
        decorateEmployee(&employees[i])
    }

    w.Header().Set("Content-Type", "application/json")
    if err := json.NewEncoder(w).Encode(employees); err != nil {
        http.Error(w, "Error encoding response", http.StatusInternalServerError)
        return
    }
}

在這個重構的處理程式中,我們:

  • 將所有行掃描到記憶體中。
  • 掃描後立即關閉連線,將其釋放回池。
  • 在記憶體中裝飾僱員記錄,而無需保持連線開啟。
最佳化後的效能

最佳化後以 50 RPS 執行相同的 Vegeta 測試,結果如下:

$ echo "GET http://localhost:8080/employees" | vegeta attack -duration=30s -rate=50 | tee results.bin | vegeta report
Requests      [total, rate, throughput]         1500, 50.03, 45.78
Duration      [total, attack, wait]             32.768s, 29.98s, 2.788s
Latencies     [min, mean, 50, 90, 95, 99, max]  2.045s, 2.502s, 2.499s, 2.692s, 2.741s, 2.856s, 2.995s
Bytes In      [total, mean]                     11817000, 7878.00
Bytes Out     [total, mean]                     0, 0.00
Success       [ratio]                           100.00%
Status Codes  [code:count]                      200:1500
...
{"MaxOpenConnections":15,"OpenConnections":1,"InUse":0,"Idle":1,"WaitCount":0,"WaitDuration":0,"MaxIdleClosed":0,"MaxIdleTimeClosed":0,"MaxLifetimeClosed":0}
{"MaxOpenConnections":15,"OpenConnections":1,"InUse":0,"Idle":1,"WaitCount":0,"WaitDuration":0,"MaxIdleClosed":0,"MaxIdleTimeClosed":0,"MaxLifetimeClosed":0}
{"MaxOpenConnections":15,"OpenConnections":1,"InUse":0,"Idle":1,"WaitCount":0,"WaitDuration":0,"MaxIdleClosed":0,"MaxIdleTimeClosed":0,"MaxLifetimeClosed":0}
...

可以看到,不僅吞吐量和延遲得到了 100% 的大幅改善,而且 OpenConnections 的總數也沒有超過 1,甚至還有閒置連線處於待機狀態,從而使 WaitCount 始終為零!

總結

透過最佳化連線的處理方式,先將所有行獲取到記憶體中,然後立即關閉連線,而不是在執行其他 I/O 繫結操作(如裝飾記錄)時保持連線開啟。這樣,資料庫連線就能儘快返回到池中,為其他傳入請求釋放資源,從而提高吞吐量和併發性。


你好,我是俞凡,在Motorola做過研發,現在在Mavenir做技術工作,對通訊、網路、後端架構、雲原生、DevOps、CICD、區塊鏈、AI等技術始終保持著濃厚的興趣,平時喜歡閱讀、思考,相信持續學習、終身成長,歡迎一起交流學習。為了方便大家以後能第一時間看到文章,請朋友們關注公眾號"DeepNoMind",並設個星標吧,如果能一鍵三連(轉發、點贊、在看),則能給我帶來更多的支援和動力,激勵我持續寫下去,和大家共同成長進步!

本文由mdnice多平臺釋出

相關文章