Báo Cáo Thực Nghiệm Affiliate Website & Tăng Trưởng

Báo Cáo Thực Nghiệm Affiliate Website & Tối Ưu Hiệu Năng Phân Tán

Báo cáo thực nghiệm này tổng hợp các phát hiện kỹ thuật, kết quả kiểm thử chịu tải (Stress Testing), thiết kế kiến trúc bộ nhớ đệm đa tầng (Multi-tier Cache Architecture), và bài học kinh nghiệm vận hành hệ thống Affiliate E-commerce quy mô lớn tại learn.tanhdev.com.

1. Bối Cảnh & Mục Tiêu Thực Nghiệm (Benchmarking Scope)

Hệ thống Affiliate E-commerce chịu trách nhiệm xử lý hàng triệu lượt chuyển hướng liên kết (Affiliate Redirection Links), theo dõi hành vi nhấp chuột (Click Tracking), tính toán hoa hồng (Commission Processing) và cung cấp API danh mục sản phẩm thời gian thực.

1.1. Thách Thức Kỹ Thuật

• Traffic Spike: Lưu lượng truy cập đột biến trong các chiến dịch Mega Sale (11/11, 12/12) với đỉnh chịu tải có thể gấp 20-50 lần lưu lượng bình thường.
• Low-Latency Redirection: Yêu cầu độ trễ chuyển hướng URL (302 Redirect / Tracking Pixel) < 15ms để tránh làm giảm tỷ lệ chuyển đổi (Conversion Rate) của người dùng.
• Database Bottleneck: Truy vấn trực tiếp SQL Database cho mỗi nhấp chuột sẽ gây ngẽn kết nối (Connection Exhaustion) và tăng tỷ lệ rớt gói.

1.2. Môi Trường Thực Nghiệm (Testbed Setup)

• Backend Services: 3 instances Go Backend (Gin Engine / gRPC) chạy trên Docker Containers (2 vCPU, 4GB RAM per instance).
• Caching Layer: Redis Cluster 3 Nodes (Master-Replica configuration, 8GB RAM).
• Database: PostgreSQL 15 Primary-Replica cluster kèm PgBouncer connection pool.
• Load Generation Tools: k6, wrk, và vegeta chạy từ các VPS độc lập trong cùng mạng VPC 10Gbps.

2. Kiến Trúc Bộ Nhớ Đệm Đa Tầng (Multi-Tier Cache Architecture)

Để giải quyết triệt để nghẽn cổ đống I/O và đạt độ trễ sub-millisecond cho các tài nguyên đọc nhiều (Read-Heavy), hệ thống áp dụng mô hình cache 3 tầng:

[User Request] 
      │
      ▼
┌──────────────┐    Cache Hit (90%)
│ L3 Edge CDN  ├───────────────────────► [Return HTTP 200/302]
└──────┬───────┘
       │ Cache Miss
       ▼
┌──────────────┐    Cache Hit (8%)
│ L1 In-Memory ├───────────────────────► [Return Data < 1ms]
└──────┬───────┘
       │ Cache Miss
       ▼
┌──────────────┐    Cache Hit (1.9%)
│ L2 Redis     ├───────────────────────► [Return Data < 5ms]
└──────┬───────┘
       │ Cache Miss (0.1%)
       ▼
┌──────────────┐
│  PostgreSQL  ├───────────────────────► [Query & Populate Cache]
└──────────────┘

2.1. Tầng L1: In-Memory Microservice Cache (Go sync.Map / Ristretto)

• Lưu trữ cấu hình campaign, danh mục sản phẩm hot và rules theo dõi liên kết hot ngay tại bộ nhớ RAM của Microservice.
• Thời gian truy xuất: < 0.05ms (nanosecond scale).
• Hạn chế ghi quá nhiều vào network socket.

2.2. Tầng L2: Distributed Redis Cluster

• Cấu hình Redis Cluster với thuật toán sharding dựa trên Hash Slots.
• Áp dụng cấu trúc dữ liệu tối ưu: Redis Hashes cho thông tin sản phẩm, Bitmaps / HyperLogLog cho thống kê Unique Click Counter.
• Sử dụng chiến lược Cache-Aside Pattern kết hợp với TTL ngẫu nhiên (Jittered TTL) để tránh hiện tượng nổ cache đồng loạt (Cache Expiration Avalanche).

2.3. Phòng Chống Cache Stampede Với Singleflight

Khi một khóa cache hết hạn đúng thời điểm có hàng ngàn request truy cập cùng lúc, hệ thống sử dụng thư viện golang.org/x/sync/singleflight:

• Chỉ cho phép 01 goroutine duy nhất thực thi truy vấn cơ sở dữ liệu.
• Các goroutine khác chờ kết quả từ goroutine duy nhất này và đồng thời nhận kết quả nạp lại cache.

3. Kết Quả Đo Lường Hiệu Năng & Tải (Traffic Performance & Metrics)

3.1. So Sánh Hiệu Năng Trước & Sau Khi Tối Ưu Cache

3.2. Phân Tích Độ Trễ (Latency Distribution Chart under 50,000 RPS)

• p50 (Median Latency): 1.8 ms — 90% truy vấn được phục vụ ngay tại L1 In-Memory Cache.
• p90: 4.2 ms — Xử lý các request truy xuất L2 Redis Cluster.
• p99: 12.5 ms — Phục vụ các request lọt lưới qua Database và các tác vụ nạp cache ban đầu.
• p99.9: 28.0 ms — Tác vụ ghi vết giao dịch bất đồng bộ qua Kafka/RabbitMQ.

4. Bài Học Kiến Trúc & Khuyến Nghị Vận Hành (Architecture Insights)

1. Giảm thiểu Serialization Overheads:
   • Sử dụng Protocol Buffers (Protobuf) hoặc JSON Fast Parsers (như goccy/go-json) thay thế cho thư viện JSON tiêu chuẩn giúp giảm 30% CPU overhead khi encode/decode payload lớn.
2. Quản Lý Kết Nối Database Kết Hợp Connection Pool:
   • Sử dụng PgBouncer ở chế độ Transaction Pooling giúp duy trì hàng chục ngàn kết nối client mà không làm ngợp PostgreSQL backend.
3. Cơ Chế Graceful Degradation (Suy Ha Cấp Mềm):
   • Khi Redis Cluster gặp sự cố tạm thời, hệ thống tự động chuyển sang chốt chặn Fallback Mode (trả về URL chuyển hướng cơ bản từ L1 Cache mà không ghi nhận analytics nặng) giúp duy trì uptime 99.99%.

Báo cáo được chuẩn hóa và lưu trữ tại hệ thống kiến trúc learn.tanhdev.com.