DDevArchive
Đăng nhập

Load balancing, API gateway và rate limiting

Khi có nhiều instance chạy cùng một dịch vụ, ai chia request cho chúng? Đó là load balancer. Và khi hệ thống mọc thêm nhiều service, ai là "cổng vào" duy nhất? Đó là API gateway.

Load balancer: chia đều công việc

Load balancer nằm giữa client và các instance. Nó chọn instance nào nhận request tiếp theo theo thuật toán: round-robin, ít kết nối nhất, hay theo hash (sticky). Kèm health check: instance hỏng tự bị loại khỏi vòng.

Thuật toánCách hoạt độngDùng khi
Round-robinChia đều theo lượtInstance giống hệt nhau
Least connectionsChọn instance ít kết nối nhấtRequest nặng nhẹ không đều
IP hashCùng client luôn về cùng instanceCần giữ session

API gateway: cổng vào duy nhất

Gateway là lớp đứng trước mọi service: định tuyến request, xác thực tập trung, rate limiting, giới hạn payload, log. Client chỉ biết một URL, không biết bên trong có bao nhiêu service.

Gateway là "single point of failure"

Mọi request đi qua gateway → nếu nó chết, cả hệ thống chết. Phải chạy nhiều bản gateway sau load balancer, và giữ gateway mỏng — đừng nhét logic nghiệp vụ vào.

Rate limiting nâng cao

Rate limiting giới hạn số request mỗi client trong một khoảng thời gian. Có nhiều thuật toán: Fixed window, Sliding window, Token bucket, Leaky bucket. Lưu đếm trong Redis để dùng chung giữa các instance.

// File: ratelimit.js
// Token bucket dùng Redis, chia sẻ giữa nhiều instance
async function rateLimit(key, max = 100, windowSec = 60) {
  const current = await redis.incr(`rl:${key}`);
  if (current === 1) {
    await redis.expire(`rl:${key}`, windowSec);
  }
  if (current > max) {
    return { allowed: false, retryAfter: 60 };
  }
  return { allowed: true, remaining: max - current };
}

❓ Rate limit đếm trong Redis thay vì bộ nhớ từng instance vì sao?

  • Nói được 3 thuật toán load balancing
  • Biết gateway làm gì và rủi ro của nó
  • Triển khai rate limit bằng Redis
  • Chọn được khi nào cần gateway