Series Cloud Database Neon #2: Nghệ thuật Quản trị Kết nối (Connection Pooling) và Driver Serverless

1. Tại sao Connection Pooling là bắt buộc?

Neon sử dụng kiến trúc Proxy (PgBouncer). Nếu bạn dùng kết nối trực tiếp (Port 5432), bạn sẽ bị giới hạn số lượng kết nối tối đa. Nhưng nếu bạn dùng Pooling Mode (Port 6543), Neon sẽ gom nhóm các kết nối của Laravel lại, tái sử dụng các đường ống hiện có.

Quy tắc vàng cho Senior Backend:

• Kết nối trực tiếp (Port 5432): Chỉ dùng cho các tác vụ quản trị, Migration, hoặc chạy các lệnh DDL (ALTER TABLE).
• Kết nối qua Pooling (Port 6543): Luôn luôn dùng cho các tác vụ ứng dụng hàng ngày (SELECT, INSERT, UPDATE).

2. Định hình lại Driver cho Laravel

Mặc định, Laravel sử dụng PDO của PHP. Khi bạn cấu hình .env, hãy đảm bảo sử dụng port 6543 của Neon.

# Sử dụng Port 6543 (PgBouncer)
DB_PORT=6543

# Thêm tham số sslmode=verify-full để bảo mật tuyệt đối
DB_URL=postgres://user:password@ep-host.region.aws.neon.tech/neondb?sslmode=verify-full

Tuy nhiên, PDO của PHP vẫn tồn tại một nhược điểm: Nó duy trì kết nối TCP đến hết vòng đời của request. Nếu ứng dụng của bạn có hàng ngàn request đồng thời, số lượng kết nối sẽ tăng vọt.

3. Tuyệt kỹ: Sử dụng "Neon Serverless Driver" (Dành cho công việc nặng)

Nếu ứng dụng của bạn có những tiến trình chạy nền (như Job đồng bộ dữ liệu Hitachi) cần xử lý khối lượng lớn, hãy cân nhắc sử dụng thư viện Neon Serverless Driver (tương thích với các hệ thống cần kết nối nhanh qua HTTP/WebSocket nếu bạn dùng các runtime như Edge Functions).

Nhưng với Laravel/PHP, chúng ta tập trung tối ưu PDO Persistent Connections. Đây là cách "lừa" PHP-FPM giữ lại kết nối để tái sử dụng cho request sau, giảm thiểu latency từ việc tạo mới TCP Handshake.

Mở config/database.php:

'pgsql' => [
    'driver' => 'pgsql',
    'host' => env('DB_HOST', '127.0.0.1'),
    'port' => env('DB_PORT', '6543'), // Nhớ trỏ về 6543
    // ...
    'options' => [
        // Bật kết nối bền vững để tái sử dụng kết nối qua Pooling
        PDO::ATTR_PERSISTENT => true, 
        PDO::ATTR_TIMEOUT => 5,
    ],
],

4. Chiến lược "Branching" trong CI/CD (Thực chiến)

Đây là giá trị cốt lõi của Neon. Thay vì dùng chung 1 database cho mọi môi trường, hãy làm thế này trong GitHub Actions:

# Ví dụ pipeline khi mở Pull Request
- name: Create Neon Branch
  run: |
    # Tạo một nhánh database tạm từ main
    BRANCH_URL=$(neon branches create --name pr-${{ github.event.number }} --parent main --json | jq -r '.connection_uri')
    echo "DB_URL=$BRANCH_URL" >> $GITHUB_ENV

- name: Run Migrations
      run: php artisan migrate --database=pgsql_dynamic # Cấu hình db url động

Với cách này:

1. Mỗi khi Dev mở một Pull Request, hệ thống sẽ tự động sinh ra một "cái Database riêng" cho code đó.
2. Migration chạy trên Database nhánh.
3. Chạy Unit Test, Integration Test trên database này.
4. Xong việc, dùng Neon CLI xóa nhánh (neon branches delete ...).

Kết quả: Bạn có 100% sự tự tin là migration không làm hỏng dữ liệu thật, và hệ thống test của bạn hoàn toàn tách biệt, không bao giờ bị "dirty data" (dữ liệu rác) từ người khác đổ vào.

Tổng kết Bài 2

Chúng ta đã học cách "thuần hóa" kết nối tới Neon thông qua Port 6543 (PgBouncer) và cách dùng Persistent Connections để tối ưu sức mạnh Serverless. Quan trọng nhất, bạn đã nhìn thấy được sức mạnh của Branching trong CI/CD – thứ khiến Neon trở thành "đối thủ đáng gờm" nhất của mọi dịch vụ database truyền thống.