Skip to content
Dán nhãn

Load Balancer là gì? Tìm hiểu cân bằng tải và cách hoạt động

Featured image of post Load Balancer là gì? Tìm hiểu cân bằng tải và cách hoạt động

Load Balancer (cân bằng tải) là giải pháp phân phối traffic đến nhiều server, giúp tăng hiệu năng, độ ổn định và khả năng mở rộng hệ thống. Tìm hiểu load balancer hoạt động ra sao, các thuật toán phổ biến và cách triển khai.

Load Balancer là thành phần quan trọng trong kiến trúc hệ thống hiện đại, giúp phân phối traffic thông minh đến nhiều server. Bài viết giải thích chi tiết load balancer là gì, các thuật toán cân bằng tải phổ biến, health check, session persistence và kiến trúc triển khai thực tế.

Load Balancer là gì?

Load Balancer (cân bằng tải) là một thiết bị hoặc phần mềm đứng giữa client và nhóm server (server pool/server farm), có nhiệm vụ phân phối các request đến từ người dùng đến các server backend sao cho tải được chia đều, không server nào bị quá tải trong khi server khác lại nhàn rỗi.

Khi website hoặc ứng dụng của bạn phát triển và lượng người dùng tăng lên, một server đơn lẻ sẽ không thể đáp ứng hết tất cả request. Đây là lúc Load Balancer phát huy vai trò — phân phối traffic thông minh đến nhiều server, đảm bảo hệ thống luôn ổn định và phản hồi nhanh.

Ví dụ thực tế

Hãy tưởng tượng một nhà hàng có 5 quầy thu ngân. Nếu tất cả khách hàng xếp hàng ở cùng một quầy, thời gian chờ sẽ rất lâu dù 4 quầy còn lại trống. Load Balancer giống như người hướng dẫn khách — phân phối khách hàng đến các quầy đang rảnh nhất, đảm bảo tất cả quầy đều phục vụ và khách hàng chờ ít nhất.

Tại sao cần Load Balancer?

Đảm bảo High Availability (Khả dụng cao)

Nếu chỉ có một server và server đó gặp sự cố, toàn bộ dịch vụ sẽ ngừng hoạt động. Với load balancer:

  • Traffic tự động được chuyển đến các server còn hoạt động.
  • Hệ thống có thể chịu được sự cố của một hoặc nhiều server mà không ảnh hưởng người dùng.
  • Đạt được uptime 99.99% hoặc cao hơn.

Khả năng mở rộng (Scalability)

Load balancer cho phép bạn scale horizontally — thêm server mới vào pool khi traffic tăng, thay vì phải nâng cấp phần cứng của server hiện có (scale vertically). Horizontal scaling linh hoạt và hiệu quả chi phí hơn nhiều.

Hiệu năng tối ưu

Phân phối tải đều giữa các server đảm bảo:

  • Không server nào bị quá tải.
  • Thời gian phản hồi ổn định cho mọi người dùng.
  • Tận dụng tối đa tài nguyên phần cứng.

Bảo trì không gián đoạn

Bạn có thể gỡ từng server khỏi pool để bảo trì hoặc cập nhật mà không ảnh hưởng dịch vụ. Load balancer sẽ tự động phân phối traffic đến các server còn lại.

Các loại Load Balancer

Layer 4 Load Balancer (Transport Layer)

Hoạt động ở tầng Transport (TCP/UDP) của mô hình OSI. Quyết định routing dựa trên thông tin mạng như IP nguồn/đích và port number, không kiểm tra nội dung request.

Đặc điểm:

  • Tốc độ nhanh hơn vì không cần phân tích nội dung.
  • Phù hợp cho các dịch vụ không phải HTTP (database, email, game server).
  • Không thể routing dựa trên URL path hoặc HTTP headers.

Layer 7 Load Balancer (Application Layer)

Hoạt động ở tầng Application, có khả năng đọc và phân tích nội dung HTTP request. Quyết định routing dựa trên URL, headers, cookies, request body.

Đặc điểm:

  • Linh hoạt hơn — có thể routing /api đến API servers và /images đến image servers.
  • Hỗ trợ SSL termination, compression, caching.
  • Chậm hơn Layer 4 một chút do phải phân tích nội dung.
  • Phổ biến nhất cho web applications.

Global Server Load Balancing (GSLB)

Phân phối traffic ở cấp độ toàn cầu, routing người dùng đến datacenter gần nhất. Thường sử dụng DNS-based routing kết hợp với health checks.

Các thuật toán cân bằng tải phổ biến

Round Robin

Phân phối request lần lượt theo vòng tròn: Server 1 → Server 2 → Server 3 → Server 1 → ...

Ưu điểm: Đơn giản, dễ triển khai. Nhược điểm: Không xét đến năng lực thực tế của từng server. Nếu các server có cấu hình khác nhau, server yếu sẽ bị quá tải.

Weighted Round Robin

Tương tự Round Robin nhưng gán trọng số cho mỗi server. Server mạnh hơn được gán trọng số cao hơn, nhận nhiều request hơn.

Ví dụ: Server A (weight 5), Server B (weight 3), Server C (weight 2) → Cứ 10 request thì A nhận 5, B nhận 3, C nhận 2.

Least Connections

Gửi request đến server có ít kết nối đang hoạt động nhất. Phù hợp khi thời gian xử lý request không đồng đều — server xử lý xong sớm hơn sẽ nhận request mới sớm hơn.

Weighted Least Connections

Kết hợp Least Connections với trọng số. Xét cả số kết nối hiện tại và năng lực server.

IP Hash

Sử dụng hash của IP client để quyết định server. Cùng một IP luôn được gửi đến cùng một server — đảm bảo session persistence mà không cần cơ chế sticky session phức tạp.

Least Response Time

Gửi request đến server có thời gian phản hồi nhanh nhất và ít kết nối nhất. Đây là thuật toán thông minh nhất, đảm bảo người dùng luôn được phục vụ bởi server nhanh nhất.

Random

Chọn server ngẫu nhiên. Đơn giản và hiệu quả đáng ngạc nhiên khi số lượng server lớn và traffic cao (theo law of large numbers).

Bảng so sánh thuật toán

Thuật toán Độ phức tạp Use Case phù hợp Nhận biết Session Nhận biết Capacity
Round Robin O(1) Server đồng nhất, request ngắn Không Không
Weighted Round Robin O(1) Server khác cấu hình Không Có (tĩnh)
Least Connections O(n) Request thời gian xử lý khác nhau Không Có (động)
Weighted Least Conn. O(n) Server khác nhau, request đa dạng Không Có (cả hai)
IP Hash O(1) Cần session persistence Không
Least Response Time O(n) Yêu cầu hiệu năng cao nhất Không Có (động)

Kiểm tra sức khỏe server (Health Checks)

Load balancer liên tục kiểm tra tình trạng của các server backend để đảm bảo chỉ gửi traffic đến server đang hoạt động bình thường.

Active Health Check

Load balancer chủ động gửi request kiểm tra (health check probe) đến mỗi server theo chu kỳ:

  • HTTP Health Check: Gửi GET request đến endpoint cụ thể (thường là /health), kiểm tra status code 200.
  • TCP Health Check: Kiểm tra kết nối TCP có thành công không.
  • Custom Check: Kiểm tra điều kiện phức tạp hơn (database connection, disk space, memory usage).

Passive Health Check

Theo dõi response từ server khi xử lý request thực tế. Nếu server trả về quá nhiều error (5xx) hoặc timeout, load balancer đánh dấu server đó là unhealthy.

Failure Handling

Khi một server bị đánh dấu unhealthy:

  1. Load balancer ngừng gửi request mới đến server đó.
  2. Request hiện tại có thể được retry trên server khác.
  3. Health check tiếp tục chạy — khi server phục hồi, load balancer tự động đưa server trở lại pool.

Duy trì phiên làm việc (Session Persistence)

Một số ứng dụng yêu cầu tất cả request từ cùng một người dùng phải đến cùng một server (ví dụ: giỏ hàng, phiên đăng nhập). Có nhiều cách xử lý:

Load balancer thêm cookie vào response, chứa thông tin server đã phục vụ. Request tiếp theo mang theo cookie này sẽ được gửi đến cùng server.

Source IP Affinity

Dùng IP client để gắn kết với một server cụ thể (tương tự IP Hash).

Application-Level Solution

Giải pháp tốt nhất là thiết kế ứng dụng stateless — lưu session data vào shared storage (Redis, database) thay vì trên server. Khi đó, bất kỳ server nào cũng có thể phục vụ bất kỳ request nào.

Các giải pháp Load Balancer phổ biến

Software Load Balancer

  • Nginx: Vừa là web server vừa là reverse proxy/load balancer. Hiệu năng cao, cấu hình linh hoạt, miễn phí. Phổ biến nhất hiện nay.

  • HAProxy: Load balancer chuyên dụng, hiệu năng cực cao. Được sử dụng bởi nhiều công ty lớn như GitHub, Stack Overflow.

  • Traefik: Thiết kế cho môi trường container (Docker, Kubernetes). Tự động phát hiện và cấu hình services.

  • Envoy: Proxy hiện đại cho kiến trúc microservices, được phát triển bởi Lyft. Thường dùng làm sidecar proxy trong service mesh.

Cloud Load Balancer

  • AWS Elastic Load Balancing (ELB): Application Load Balancer (ALB) cho Layer 7, Network Load Balancer (NLB) cho Layer 4.

  • Google Cloud Load Balancing: Hỗ trợ global load balancing, tự động scale.

  • Azure Load Balancer: Tích hợp với hệ sinh thái Azure.

Hardware Load Balancer

  • F5 BIG-IP: Giải pháp enterprise với hiệu năng và tính năng bảo mật cao cấp.
  • Citrix ADC: Application Delivery Controller cho doanh nghiệp lớn.

Load Balancer và Proxy

Load balancer có mối liên hệ chặt chẽ với proxy:

Reverse Proxy as Load Balancer

Nginx và HAProxy vừa là reverse proxy vừa là load balancer. Chúng nhận request từ client, quyết định server backend phù hợp và chuyển tiếp request — đây chính là chức năng của reverse proxy kết hợp với thuật toán cân bằng tải.

Reverse Proxy là gì?

Proxy Load Balancing

Trong các hệ thống sử dụng proxy (web scraping, ad verification), load balancer phân phối request qua các proxy khác nhau để tối ưu hiệu năng và tránh overload một proxy đơn lẻ. TMProxy tích hợp cơ chế cân bằng tải nội bộ để tự động phân phối request qua pool hơn 10 triệu IP.

Kiến trúc triển khai thực tế

Single Load Balancer

Kiến trúc đơn giản nhất — một load balancer phía trước nhiều server. Nhược điểm: load balancer là single point of failure.

Active-Passive (Failover)

Hai load balancer — một active xử lý traffic, một passive ở chế độ standby. Khi active gặp sự cố, passive tự động tiếp quản (failover).

Active-Active

Cả hai load balancer đều active, chia sẻ traffic. Tận dụng tốt tài nguyên hơn Active-Passive và loại bỏ single point of failure.

Giám sát và các chỉ số quan trọng

Vận hành load balancer hiệu quả đòi hỏi hệ thống giám sát toàn diện. Dưới đây là các metrics quan trọng nhất cần theo dõi:

Requests Per Second (RPS)

Số lượng request mà load balancer xử lý mỗi giây. Metric này cho biết tải hiện tại của hệ thống và giúp dự đoán khi nào cần scale thêm server. Theo dõi RPS theo thời gian để nhận biết pattern traffic và lên kế hoạch capacity.

Active Connections

Số kết nối đang hoạt động đồng thời trên mỗi backend server. Nếu một server có active connections cao bất thường so với các server khác, có thể thuật toán cân bằng tải cần điều chỉnh hoặc server đó đang gặp vấn đề xử lý request chậm.

Error Rate

Tỷ lệ request lỗi (HTTP 4xx và 5xx). Error rate tăng đột ngột có thể chỉ ra: server backend gặp sự cố, deployment lỗi, hoặc hệ thống đang bị quá tải. Đặt alert khi error rate vượt quá ngưỡng bình thường (thường là 1-5%).

Response Time (p50, p95, p99)

Thời gian phản hồi ở các phân vị khác nhau quan trọng hơn giá trị trung bình. p50 cho biết trải nghiệm của đa số người dùng, p95 cho biết trải nghiệm của 5% người dùng chậm nhất, và p99 phát hiện các outlier nghiêm trọng. Nếu p99 cao hơn p50 nhiều lần, hệ thống có vấn đề về tail latency.

Backend Health Status

Trạng thái health check của từng backend server: healthy, unhealthy, hoặc draining. Theo dõi lịch sử health status giúp phát hiện server "flapping" (liên tục chuyển giữa healthy và unhealthy) — dấu hiệu của vấn đề phần cứng hoặc cấu hình.

Bandwidth (Throughput)

Lượng dữ liệu (bytes) đi qua load balancer mỗi giây. Giám sát bandwidth giúp đảm bảo không vượt quá giới hạn network interface và lên kế hoạch nâng cấp khi cần. Bandwidth bất thường có thể chỉ ra DDoS attack hoặc data leak.

Công cụ giám sát phổ biến: Prometheus + Grafana là combo được sử dụng rộng rãi nhất cho monitoring load balancer. Datadog, New Relic và AWS CloudWatch cũng là các lựa chọn phổ biến cho môi trường cloud.

Đừng bỏ qua p99 latency
Giá trị trung bình (average) có thể che giấu vấn đề nghiêm trọng. Nếu p99 cao hơn p50 gấp 10 lần, 1% người dùng đang trải nghiệm tệ hại — đủ để ảnh hưởng đến conversion rate và brand image. Luôn alert dựa trên **p95/p99**, không phải average.

Nghiên cứu điển hình thực tế

Netflix — Cân bằng tải quy mô toàn cầu

Netflix phục vụ hơn 200 triệu người dùng trên toàn thế giới, sử dụng kiến trúc multi-layered load balancing. Ở tầng global, Netflix dùng DNS-based load balancing để routing người dùng đến AWS region gần nhất. Ở tầng region, Zuul (API gateway tự phát triển) hoạt động như Layer 7 load balancer, phân phối request đến hàng nghìn microservice instances. Netflix cũng phát triển Eureka cho service discovery và Ribbon cho client-side load balancing, giúp mỗi service tự cân bằng tải khi gọi service khác.

GitHub — HAProxy cho hàng triệu developer

GitHub sử dụng HAProxy làm load balancer chính, xử lý hàng triệu git operations và web requests mỗi ngày. HAProxy được chọn vì hiệu năng cực cao và khả năng xử lý hàng trăm nghìn concurrent connections. GitHub triển khai kiến trúc Active-Active với nhiều HAProxy instances, kết hợp health checks tùy chỉnh để đảm bảo chỉ routing traffic đến server hoạt động bình thường. Khi cần maintenance, từng server được drain traffic một cách graceful thông qua load balancer.

Flash Sale thương mại điện tử — Xử lý traffic spike

Trong các sự kiện flash sale (Shopee 11.11, Black Friday), traffic có thể tăng 10-50 lần so với bình thường chỉ trong vài giây. Các platform e-commerce sử dụng chiến lược multi-tier load balancing: Global load balancer phân phối đến các datacenter, Application load balancer phân phối đến các server group (product catalog, cart, payment), mỗi group auto-scale dựa trên metrics từ load balancer. Queue systems (Redis, RabbitMQ) được đặt sau load balancer để throttle traffic vào các service nhạy cảm như payment processing.

Kết luận: Load Balancer là thành phần thiết yếu trong kiến trúc hệ thống hiện đại, đảm bảo ứng dụng luôn sẵn sàng, nhanh chóng và có khả năng mở rộng. Dù bạn đang vận hành một website nhỏ hay một hệ thống microservices phức tạp, hiểu về cân bằng tải sẽ giúp bạn thiết kế hạ tầng vững chắc và sẵn sàng đối phó với mọi mức tải.

Nguồn & Tài liệu tham khảo
1. [Nginx — HTTP Load Balancing](https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/) 2. [HAProxy — Documentation](https://www.haproxy.org/#docs) 3. [AWS — What is Load Balancing?](https://aws.amazon.com/what-is/load-balancing/) 4. [Google Cloud — Load Balancing Overview](https://cloud.google.com/load-balancing/docs/load-balancing-overview) 5. [DigitalOcean — An Introduction to HAProxy](https://www.digitalocean.com/community/tutorials/an-introduction-to-haproxy-and-load-balancing-concepts)

Câu hỏi thường gặp

Load Balancer là gì và hoạt động như thế nào?
Load Balancer (cân bằng tải) là thiết bị hoặc phần mềm đứng giữa client và nhóm server, phân phối request đến các server backend sao cho tải được chia đều. Nó liên tục kiểm tra sức khỏe server và chỉ gửi traffic đến server đang hoạt động bình thường.
Layer 4 và Layer 7 Load Balancer khác nhau thế nào?
Layer 4 hoạt động ở tầng Transport, routing dựa trên IP và port — nhanh nhưng không linh hoạt. Layer 7 hoạt động ở tầng Application, đọc được HTTP request — linh hoạt hơn, có thể routing theo URL path, headers, cookies.
Thuật toán cân bằng tải nào phổ biến nhất?
Round Robin là đơn giản và phổ biến nhất cho server đồng nhất. Least Connections phù hợp khi thời gian xử lý khác nhau. Weighted Round Robin dùng khi server có cấu hình khác nhau. Least Response Time thông minh nhất nhưng phức tạp hơn.
Load Balancer có cần thiết cho website nhỏ không?
Website nhỏ với 1 server có thể chưa cần load balancer. Tuy nhiên, khi traffic tăng hoặc cần đảm bảo uptime cao (99.99%), load balancer trở nên cần thiết để tránh single point of failure và cho phép scale horizontally.
Sticky session là gì và khi nào cần dùng?
Sticky session (session persistence) đảm bảo request từ cùng user luôn đến cùng server. Cần dùng khi ứng dụng lưu session data trên server (giỏ hàng, đăng nhập). Giải pháp tốt hơn là thiết kế stateless app với shared storage như Redis.

article.share