Bài 11: Connection Pooling & Tuning - Tối ưu kết nối và Xử lý Timeout

Mục tiêu bài học:

• Hiểu cơ chế hoạt động của Connection Pool và tại sao cấu hình mặc định không luôn tốt cho mọi hệ thống.

• Biết cách tinh chỉnh PoolSize, MinIdleConns để chịu tải lớn (High Load) và chống nghẽn cổ chai.

• Thiết lập các ngưỡng Timeout sống còn để bảo vệ ứng dụng Go khỏi tình trạng treo cứng (Goroutine Leaks) khi mạng chập chờn.

1. Tại sao cần Connection Pooling?

Mỗi khi ứng dụng Go muốn nói chuyện với Redis, nó phải mở một kết nối TCP (3-way handshake). Quá trình này tốn nhiều thời gian (vài chục mili-giây). Nếu hệ thống có 10,000 request/giây và mỗi request đều mở/đóng kết nối mới, ứng dụng sẽ sập ngay lập tức vì cạn kiệt cổng (port exhaustion) và CPU overhead.

Connection Pool (Hồ chứa kết nối) giải quyết bằng cách:

1. Mở sẵn một số lượng kết nối nhất định.

2. Khi có request, "mượn" một kết nối từ Pool.

3. Chạy lệnh Redis xong, "trả" kết nối về Pool để request khác dùng lại.

Thư viện go-redis tự động quản lý Pool dưới nền. Tuy nhiên, khi đưa lên Production, bạn phải tinh chỉnh các thông số này cho phù hợp với đặc thù dự án.

2. Cấu hình Connection Pool & Timeout (Code mẫu)

Go

package main

import (
	"context"
	"fmt"
	"time"

	"github.com/redis/go-redis/v9"
)

func initTunedClient() *redis.Client {
	return redis.NewClient(&redis.Options{
		Addr: "localhost:6379",

		// --- 1. CẤU HÌNH POOLING ---
		
		// Tổng số kết nối tối đa. Mặc định là 10 * runtime.GOMAXPROCS (thường là số core CPU).
		PoolSize: 100, 
		
		// Số kết nối nhàn rỗi (idle) tối thiểu luôn được giữ mở để chờ request.
		// Giúp hệ thống phản ứng ngay lập tức khi có lượng traffic tăng đột biến (Spike).
		MinIdleConns: 20,
		
		// Thời gian sống tối đa của một kết nối. 
		// Giúp làm mới kết nối, tránh các lỗi do Firewall tự động ngắt các kết nối quá lâu.
		ConnMaxLifetime: 1 * time.Hour,
		
		// Thời gian tối đa một kết nối được phép nằm nhàn rỗi trước khi bị đóng.
		ConnMaxIdleTime: 30 * time.Minute,

		// --- 2. CẤU HÌNH TIMEOUT ---
		
		// Thời gian chờ để thiết lập một kết nối TCP mới.
		DialTimeout: 5 * time.Second,
		
		// Thời gian tối đa chờ phản hồi (đọc) hoặc gửi dữ liệu (ghi) cho 1 lệnh Redis.
		// Mặc định của go-redis là 3 giây.
		ReadTimeout:  3 * time.Second,
		WriteTimeout: 3 * time.Second,
		
		// Thời gian tối đa ứng dụng phải chờ để "mượn" được 1 kết nối từ Pool.
		// Nếu hết thời gian này mà Pool vẫn đang đầy, go-redis sẽ báo lỗi "redis: connection pool timeout"
		PoolTimeout: 4 * time.Second, // Thường đặt lớn hơn ReadTimeout khoảng 1s
	})
}

func main() {
	rdb := initTunedClient()
	defer rdb.Close()

	ctx := context.Background()
	if err := rdb.Ping(ctx).Err(); err != nil {
		fmt.Println("Khởi tạo thất bại:", err)
		return
	}
	fmt.Println("Redis Client đã sẵn sàng với cấu hình Tuning!")
	
	// Xem trạng thái Pool hiện tại
	stats := rdb.PoolStats()
	fmt.Printf("Tổng kết nối: %d, Đang rảnh (Idle): %d, Đang bận (Stale): %d\n", 
		stats.TotalConns, stats.IdleConns, stats.StaleConns)
}

3. Hướng dẫn Tuning (Kinh nghiệm Production)

1. Chọn PoolSize bao nhiêu là đủ?

Nhiều người nghĩ set PoolSize = 10000 thì ứng dụng sẽ chạy nhanh hơn. Đây là sai lầm chết người.

• Redis bản chất chạy đơn luồng (Single-threaded). Nó chỉ xử lý 1 lệnh tại 1 thời điểm.

• Nếu bạn gửi 10,000 kết nối cùng lúc, Redis sẽ tốn CPU để chuyển đổi ngữ cảnh (Context Switching) giữa các kết nối thay vì xử lý dữ liệu.

• Công thức gợi ý: PoolSize = (Số Goroutines truy cập Redis đồng thời) + Buffer. Trong hầu hết các hệ thống, PoolSize từ 100 đến 500 là quá đủ để đạt hàng chục ngàn QPS. Nếu QPS cao hơn, hãy sử dụng Pipeline thay vì tăng PoolSize.

2. Bắt bệnh lỗi: redis: connection pool timeout

Lỗi này là cơn ác mộng phổ biến nhất khi dùng go-redis. Nó có nghĩa là Pool đã cạn kiệt kết nối, và request phải xếp hàng chờ quá lâu (PoolTimeout). Nguyên nhân:

• Bị chặn bởi các lệnh chậm: Bạn đang dùng KEYS * (quét toàn DB) hoặc SMEMBERS trên tập hợp quá lớn. Nó làm luồng đơn của Redis bị treo, khiến các kết nối khác không nhận được phản hồi, giữ riệt lấy kết nối không chịu trả về Pool. Giải pháp: Tuyệt đối không dùng KEYS, thay bằng SCAN.

• Quên gọi Close() khi dùng PubSub.

• PoolSize quá bé so với lượng traffic thực tế.

3. Tại sao phải có ReadTimeout?

Nếu cáp mạng bị đứt hoặc Server Redis bị treo cứng, mà bạn không cấu hình ReadTimeout, Goroutine gọi hàm rdb.Get() sẽ bị block (treo) vĩnh viễn chờ kết quả. Khi traffic ập đến, số lượng Goroutine treo ngày càng tăng $\rightarrow$ ngốn sạch RAM $\rightarrow$ ứng dụng Crash (OOM). Đặt ReadTimeout: 3s giúp Goroutine chủ động báo lỗi và giải phóng tài nguyên.

Ngoại lệ: Nếu bạn dùng các lệnh mang tính chất "chờ đợi" (Blocking commands) như BLPOP, BRPOP, XREAD (với block > 0), thời gian chờ ở ứng dụng phải DÀI HƠN thời gian block trong lệnh Redis, nếu không ReadTimeout sẽ văng lỗi trước khi lệnh Redis kịp có dữ liệu. Hãy cấu hình riêng Timeout cho các request này qua Context (context.WithTimeout).