Tại sao chúng tôi xây dựng thêm một công cụ quản lý kết nối PostgreSQL mới?

Khi làm việc với các hệ thống PostgreSQL quy mô lớn, bài toán quản lý kết nối luôn là một thách thức. Mặc dù đã có nhiều giải pháp như PgBouncer, RDS Proxy, Pgpool-II hay Supavisor, đội ngũ phát triển tại PgDog vẫn quyết định xây dựng một công cụ mới. Bài viết này sẽ phân tích tại sao đây không chỉ là "một công cụ nữa" mà là một bước tiến về tư duy kỹ thuật.

Vấn đề về "Leaky Abstractions" (Trừu tượng hóa rò rỉ)

Phần lớn các công cụ hiện nay tuân thủ triết lý UNIX: "Làm một việc và làm tốt việc đó". Tuy nhiên, cách tiếp cận này vô tình tạo ra các rào cản (leaky abstractions) trong quá trình vận hành cơ sở dữ liệu.

Khi triển khai PgBouncer hoặc RDS Proxy, người vận hành thường phải đánh đổi bằng việc thay đổi code ứng dụng. Với những hệ thống đã chạy lâu năm, việc sửa đổi hàng nghìn dòng code mà không có test coverage đầy đủ là một rủi ro cực lớn. PgDog được tạo ra để xóa bỏ sự cần thiết của việc thay đổi code đó.

Xử lý trạng thái kết nối (Connection State)

Một trong những vấn đề lớn nhất khi sử dụng connection pooler là việc mất kiểm soát đối với các lệnh SET session.

Thách thức với lệnh SET

Các lệnh như SET statement_timeout TO '5m'; thường được dùng để tùy chỉnh cấu hình cho các truy vấn cụ thể. Khi dùng pooler, các kết nối được dùng chung (reused), dẫn đến việc trạng thái của client này "rò rỉ" sang client khác. Điều này có thể dẫn đến hậu quả nghiêm trọng, đặc biệt là với các chính sách Row Level Security (RLS) dựa trên biến phiên.

Giải pháp từ PgDog

PgDog tích hợp sẵn một trình phân tích cú pháp (SQL parser) để:

1. Phát hiện các lệnh SET.
2. Lưu trữ tên biến và giá trị trên mỗi kết nối client trong proxy.
3. Đối chiếu trạng thái giữa client và server trước khi thực thi truy vấn.
4. Nếu không khớp, PgDog sẽ tự động đồng bộ trạng thái bằng các lệnh SET nội bộ.

Nhờ cơ chế truy vấn pipeline (query pipelining), các thay đổi trạng thái được thực hiện trong một round trip duy nhất, đảm bảo hiệu năng vẫn tối ưu.

Hỗ trợ LISTEN/NOTIFY

Đây là tính năng vốn bị hạn chế khi sử dụng các pooler truyền thống ở chế độ transaction. PgDog đã giải quyết điều này bằng cách:

• Xử lý các lệnh LISTEN/NOTIFY nội bộ.
• Sử dụng broadcast channel của Tokio để điều phối tin nhắn giữa các client trong cùng một tiến trình.
• Đối với mô hình đa tiến trình (multi-process), PgDog sử dụng kết nối chuyên dụng tới Postgres để đảm bảo tính nhất quán của Pub/Sub, giúp duy trì đầy đủ các ngữ nghĩa giao dịch (transactional semantics).

Kiến trúc đa luồng với Tokio

PgDog được xây dựng trên Tokio (Rust async runtime) với các worker đa luồng. Việc này mang lại lợi thế lớn so với các kiến trúc shard-pool đơn luồng:

1. Tận dụng tối đa CPU: Khả năng xử lý nhiều client và query trên mỗi giây (QPS) cao hơn trên một tiến trình duy nhất.
2. Hiệu suất ổn định: Không cần phụ thuộc vào cơ chế autoscaling chậm chạp của hạ tầng (như RDS control plane), giúp đáp ứng các yêu cầu về độ trễ (latency SLA).
3. Đơn giản hóa vận hành: Giảm bớt sự phức tạp trong việc quản lý metrics và health check do không cần phải chia nhỏ pool theo từng tiến trình.

Kết luận

PgDog đã được kiểm chứng trong môi trường production hơn một năm qua với khả năng quản lý kết nối lên đến 2 triệu truy vấn mỗi giây (2M QPS). Đây là một giải pháp mã nguồn mở, cho phép bạn mở rộng PostgreSQL theo chiều ngang mà không cần phải thực hiện những thay đổi đau đớn trong code ứng dụng. Nếu bạn đang tìm kiếm một giải pháp hiện đại, hiệu năng cao và linh hoạt, PgDog xứng đáng để thử nghiệm.