Connection Pool cho Backend: Định cỡ, Timeout và Chống nghẽn Database

Connection pool không phải là một chiếc van mở càng lớn thì ứng dụng càng nhanh. Pool là hàng đợi có giới hạn đặt trước database: nó tái sử dụng kết nối đắt đỏ, giới hạn số truy vấn đồng thời và buộc backend thể hiện backpressure khi năng lực dữ liệu đã bão hòa. Nếu đặt quá nhỏ, request chờ dù database còn dư sức; nếu đặt quá lớn, database phải tranh chấp CPU, bộ nhớ và I/O trong khi latency tăng mạnh.

Bài viết này trình bày cách xây dựng ngân sách kết nối từ toàn hệ thống, tìm kích thước pool bằng kiểm thử tải, đặt timeout theo từng giai đoạn, giữ transaction ngắn và quan sát đúng tín hiệu. Ví dụ dùng PostgreSQL và tên cấu hình gần với HikariCP, nhưng phương pháp áp dụng được cho hầu hết driver, ORM và nền tảng backend.

1. Hiểu đúng ba lớp giới hạn

Một request đi tới database thường gặp ba giới hạn khác nhau. Concurrency của ứng dụng là số request hoặc job có thể chạy đồng thời. Kích thước pool là số connection mà một process hoặc instance được giữ. Giới hạn database là tổng connection server chấp nhận từ mọi ứng dụng, công cụ quản trị, worker và tác vụ vận hành. Ba con số không được cấu hình độc lập.

Điểm dễ bỏ sót nhất là phép nhân theo replica. Một service có pool 20 và 12 replica có thể yêu cầu 240 connection. Nếu có thêm worker, cron, trang quản trị và ba service khác dùng cùng cluster, tổng lý thuyết cao hơn rất nhiều so với con số nhìn thấy trong một file cấu hình. Autoscaling còn làm tổng này thay đổi đúng lúc hệ thống đang chịu tải.

2. Lập ngân sách connection từ database trở ra

Bắt đầu bằng giới hạn thực tế của database, nhưng không cấp hết cho ứng dụng. PostgreSQL mô tả max_connections là số kết nối đồng thời tối đa và lưu ý rằng tăng giá trị này làm tăng một số cấp phát tài nguyên, trong đó có shared memory. Hệ thống cũng có các slot dành cho vai trò vận hành và superuser. Vì vậy cần giữ một phần ngân sách cho migration, giám sát, quản trị, failover và tình huống khẩn cấp.

app_budget = database_limit
             - reserved_operations
             - admin_and_monitoring
             - migration_and_batch
             - safety_margin

pool_per_instance = floor(app_budget_for_service / max_expected_instances)

Ví dụ minh họa: sau khi trừ các phần dự phòng, service API được cấp 72 connection và có thể scale tối đa 8 instance. Điểm bắt đầu là 9 connection mỗi instance, không phải 72. Nếu rollout có lúc chạy đồng thời bản cũ và bản mới, hãy tính số pod cực đại trong giai đoạn chuyển tiếp. Với nhiều service, phân bổ theo độ quan trọng và tải đã đo thay vì chia đều.

Ngân sách là trần an toàn chứ chưa phải kích thước tối ưu. Database có thể đạt throughput tốt nhất ở mức thấp hơn. Đừng tăng max_connections chỉ để che việc ứng dụng giữ connection quá lâu; đó thường là cách chuyển hàng đợi từ application sang database, nơi khó kiểm soát và tốn tài nguyên hơn.

3. Định cỡ pool bằng throughput, latency và thời gian giữ connection

Công thức theo số core chỉ nên là điểm khởi đầu. Kích thước đúng phụ thuộc loại query, tỷ lệ cache hit, I/O, lock, transaction và phần tải khác trên server. Hãy kiểm thử với dữ liệu gần production, phân phối request thực tế và nhiều mức pool. Ở mỗi mức, đo throughput, p95/p99 latency, CPU database, I/O wait, lock wait và thời gian chờ pool.

Một ước lượng hữu ích dựa trên Little's Law là số connection bận xấp xỉ throughput database nhân với thời gian trung bình giữ connection. Nếu service thực hiện 400 transaction/giây và mỗi transaction giữ connection trung bình 20 ms, mức đồng thời trung bình khoảng 8. Đây không phải câu trả lời cuối vì tải có burst và phân phối đuôi dài, nhưng nó giúp phát hiện pool 100 là thiếu căn cứ.

busy_connections ≈ database_transactions_per_second × hold_time_seconds
                 ≈ 400 × 0.020
                 ≈ 8

Tăng pool từng bước cho tới khi throughput không còn tăng hoặc latency database bắt đầu xấu đi. Sau “điểm gối” đó, thêm connection thường chỉ tạo thêm tranh chấp. Chọn mức có khoảng đệm hợp lý trước điểm bão hòa, rồi kiểm tra lại khi schema, query, phần cứng hoặc mẫu traffic thay đổi. HikariCP cũng nhấn mạnh rằng pool nhỏ, bận hợp lý thường tốt hơn pool khổng lồ với nhiều connection nhàn rỗi.

4. Pool đầy phải tạo backpressure có giới hạn

Khi không còn connection rảnh, request nên chờ trong một hàng đợi hữu hạn và thất bại sau một khoảng ngắn, có chủ đích. Chờ vô hạn khiến thread, coroutine, socket và bộ nhớ tích tụ; đến lúc database hồi phục, backlog đồng loạt tràn xuống tạo một đợt tải mới. Pool không có timeout thực chất đã bỏ mất chức năng bảo vệ.

connectionTimeout hoặc acquire timeout phải nằm trong deadline end-to-end. Một request có ngân sách 800 ms không thể chờ pool 30 giây. Hãy dành riêng ngân sách cho chờ pool, chạy query, xử lý ứng dụng và trả response. Nếu hết thời gian lấy connection, trả lỗi có thể quan sát được hoặc giảm cấp chức năng; không retry mù quáng ở nhiều tầng.

request deadline:       800 ms
  queue/acquire budget: 100 ms
  database work:        450 ms
  application work:     150 ms
  response margin:      100 ms

Giới hạn concurrency phía trước pool giúp giảm số waiter. Với endpoint nặng, có thể dùng semaphore hoặc hàng đợi riêng. Với job nền, giới hạn số worker theo ngân sách database thay vì để hàng nghìn job đồng thời chặn ở pool. Khi quá tải, fail fast có kiểm soát thường phục hồi nhanh và dự đoán được hơn việc nhận mọi công việc rồi để tất cả cùng timeout.

5. Giữ connection ngắn và luôn trả lại bằng cấu trúc an toàn

Pool chỉ hiệu quả khi mỗi tác vụ mượn connection muộn, dùng ngắn và trả ngay. Đừng lấy connection trước khi gọi HTTP bên ngoài, render template, xử lý file hoặc chờ người dùng. Không gửi email, gọi payment hay publish message chậm trong lúc transaction database đang mở. Những khoảng chờ đó làm connection bị chiếm mà không tạo giá trị cho database.

const connection = await pool.acquire({ timeout: 100 });
try {
  await connection.begin();
  const order = await createOrder(connection, input);
  await connection.commit();
  return order;
} catch (error) {
  await connection.rollback();
  throw error;
} finally {
  connection.release();
}

Dùng finally, context manager hoặc API callback của thư viện để bảo đảm release trên mọi nhánh lỗi. Đặt query timeout và transaction timeout để một truy vấn treo không giữ slot vô hạn. Cẩn thận với streaming result: connection thường chỉ được trả sau khi stream được đọc hết hoặc đóng. Tương tự, “open session in view” có thể kéo tuổi thọ connection qua cả bước serialize response.

Leak detection hữu ích như cảnh báo, không phải cơ chế sửa lỗi. Ngưỡng quá thấp tạo false positive cho query hợp lệ; ngưỡng quá cao phát hiện quá muộn. Kết hợp stack trace lúc acquire với metric thời gian giữ connection để tìm đường code không release, transaction dài hoặc N+1 query.

6. Phân biệt các timeout và vòng đời connection

Maximum lifetime giúp thay kết nối cũ trước khi proxy, firewall hoặc database đóng chúng bất ngờ. Không đặt mọi instance thay toàn bộ connection cùng một thời điểm; thư viện tốt thường có độ lệch để tránh reconnect storm. Keepalive chỉ kiểm tra connection nhàn rỗi còn sống, không thay thế query timeout hay cơ chế hủy công việc.

Validation query trước mỗi lần mượn có thể tăng latency và tải. Ưu tiên cơ chế kiểm tra chuẩn của driver, validation khi connection nhàn rỗi hoặc xử lý lỗi kết nối đúng cách. Nếu hạ tầng có timeout idle, phối hợp keepalive và maximum lifetime với con số đó thay vì sao chép một cấu hình chung.

7. Tách workload có hành vi khác nhau

Request tương tác ngắn và báo cáo dài không nên tranh cùng một pool mà không giới hạn. Một vài báo cáo giữ connection hàng phút có thể chiếm hết slot khiến API đơn giản timeout. Hãy tách pool hoặc ít nhất tách concurrency cho traffic thời gian thực, job nền, migration và analytics. Mỗi nhóm có timeout, ưu tiên và ngân sách riêng.

Read replica có thể giảm tải đọc nhưng không làm mọi truy vấn an toàn để định tuyến. Cần hiểu độ trễ sao chép và yêu cầu read-after-write. Tạo một pool cho primary và một pool cho replica, đồng thời giới hạn tổng kết nối của từng database. Khi replica lỗi, không tự động dồn toàn bộ traffic vào primary nếu primary không có ngân sách tiếp nhận.

Với PostgreSQL và rất nhiều client ngắn, PgBouncer có thể gom kết nối ở lớp ngoài. Session pooling giữ server connection suốt phiên client; transaction pooling chỉ gán server connection trong thời gian transaction và vì vậy tiết kiệm hơn, nhưng làm thay đổi kỳ vọng đối với các tính năng dựa trên session. Cần kiểm tra SET, temporary table, advisory lock, prepared statement và hành vi ORM trước khi chọn mode.

8. Quan sát pool như một hàng đợi

Bốn gauge cơ bản là active, idle, pending/waiting và maximum. Thêm histogram acquire time, connection usage/hold time, connection creation time, timeout count và error count. Luôn ghép chúng với query latency, transaction rate, lock wait, database CPU, I/O và số connection thực tế phía server. Một metric riêng lẻ hiếm khi đủ kết luận.

• Active gần max, pending tăng, database còn nhẹ: có thể pool nhỏ hoặc code giữ connection ngoài đoạn làm việc database.
• Active gần max, database CPU/lock cao: tăng pool có khả năng làm sự cố nặng hơn; cần tối ưu query hoặc giảm concurrency.
• Idle cao trên nhiều replica: ngân sách bị giữ lãng phí và autoscaling có thể vượt trần database.
• Acquire time tăng nhưng query time ổn: backlog nằm trước database; kiểm tra pool, concurrency và transaction dài.
• Connection creation tăng đột biến: kiểm tra lifetime đồng bộ, mạng, database restart hoặc pool churn.

Đặt cảnh báo theo xu hướng và ảnh hưởng: tỷ lệ acquire timeout, p95 acquire time, thời gian pending kéo dài và tổng connection gần ngân sách. Không cảnh báo chỉ vì active đạt max trong một burst ngắn; một pool được định cỡ tốt có thể thường xuyên bận mà vẫn giữ thời gian chờ thấp.

9. Kiểm thử các failure mode trước production

Load test phải tăng đồng thời cả traffic và số replica dự kiến. Đo giai đoạn warm-up, burst, steady state và recovery. Thử query chậm, lock contention, mất mạng, database restart, failover và một instance bị leak. Xác nhận waiter bị giới hạn, deadline được giữ, connection lỗi bị loại và hệ thống không reconnect đồng loạt.

1. Chạy baseline với pool nhỏ; ghi throughput, latency và tài nguyên database.
2. Tăng pool theo bước nhỏ, giữ nguyên workload và dữ liệu.
3. Tìm điểm throughput phẳng hoặc latency tăng, rồi quay về mức có khoảng đệm.
4. Nhân cấu hình với số replica tối đa, kể cả surge khi deploy.
5. Tiêm lỗi và xác nhận acquire timeout tạo backpressure thay vì backlog vô hạn.
6. So sánh metric client với số session phía database để phát hiện pool ngoài dự kiến.

Lưu cấu hình pool cùng code và ghi lại giả định: database limit, số instance, workload, kết quả benchmark và ngày đo. Khi đội ngũ thay đổi autoscaling hoặc thêm worker mới, review lại ngân sách connection là một phần bắt buộc của thay đổi kiến trúc.

Checklist triển khai

• Tổng pool của mọi instance và service nằm dưới ngân sách sau khi trừ slot vận hành.
• Kích thước pool được kiểm chứng bằng load test, không lấy từ số user đồng thời.
• Acquire, connect, query và transaction timeout đều hữu hạn và nằm trong deadline.
• Connection được mượn muộn, release trong finally và không giữ qua I/O bên ngoài.
• Workload dài được tách concurrency hoặc pool khỏi request tương tác.
• Dashboard có active, idle, pending, acquire time, usage time và timeout count.
• Autoscaling, rolling deployment, failover và reconnect storm đã được kiểm thử.

Tài liệu tham khảo

• PostgreSQL: Connections and Authentication
• HikariCP: Configuration
• HikariCP Wiki: About Pool Sizing
• PgBouncer: Features and pooling modes