Đã đăng vào khoảng 10 giờ trước 5 phút đọc

[System Design] Load Balancing: "Người Điều Phối" Thầm Lặng Đứng Sau Hệ Thống Triệu View

Nếu anh em từng làm việc với những hệ thống có lượng traffic lớn, hoặc đơn giản là một ngày đẹp trời con server "cưng" của anh em bỗng dưng lăn ra chết vì quá tải

Hôm nay, hãy cùng mình "mổ xẻ" món này một cách thực chiến nhất nhé.

1. Đặt vấn đề: Tại sao phải "Cân"?

Hãy tưởng tượng anh em mở một quán Phở. Ban đầu vắng khách, anh em vừa nấu, vừa bưng bê, vừa tính tiền vẫn ổn (Single Server). Nhưng khi quán nổi tiếng, khách xếp hàng dài từ đầu ngõ đến cuối phố, anh em bắt đầu cuống, khách đợi lâu bỏ về, quán sập tiệm.

Trong thế giới Software cũng vậy. Một con Server dù mạnh đến đâu (Vertical Scaling - Tăng RAM/CPU) cũng có giới hạn của nó. Để giải quyết, chúng ta mua thêm 3, 4 con Server nữa (Horizontal Scaling). Nhưng làm sao để điều phối khách vào đúng bàn đúng chỗ? Đó chính là lúc Load Balancer (LB) xuất hiện.

Phân phối request: Chia đều "tải" cho các server phía sau.
Tính sẵn sàng (High Availability): Nếu một server "ngỏm" LB sẽ tự động điều hướng khách sang server khác.
Tối ưu nguồn lực: Đảm bảo không có ông nào ngồi chơi xơi nước trong khi ông khác đang "cày" hì hục.

2. Các thuật toán điều phối - "Luật chơi" của LB

Tùy vào thuật toán mà anh em chọn cho phù hợp, dưới đây là những loại phổ biến nhất:

Round Robin: Chia lần lượt (1, 2, 3 rồi quay lại 1). Công bằng nhất nếu có các cấu hình như nhau.
Least Connections: Đẩy request vào ông nào đang rảnh tay nhất (ít kết nối nhất). Cực hay cho các tác vụ tốn thời gian không đều nhau.
IP Hash: Dựa vào IP của người dùng để quyết định server. Điều này giúp khách quen (Client A) luôn gặp đúng server cũ (Server B), rất hữu ích khi xử lý Session/Cache.

3. Load Balancing ở đâu trong mô hình OSI?

Anh em làm Network chắc chắn không lạ gì mô hình OSI. LB thường hoạt động ở hai tầng chính:

Layer 4 (Transport Layer) LB chỉ nhìn vào IP và Port. Nó nhận gói tin và chuyển tiếp đi ngay mà không cần biết bên trong chứa gì (Header, Cookie...).

Ưu điểm: Cực nhanh, tốn ít tài nguyên
Nhược điểm: Không thông minh, không thể tự điều hướng URL (ví dụ: /api sang server A, /images sang server B).

Layer 7 (Application Layer)

LB lúc này "thông thái" hơn. Nó soi được cả nội dung HTTP, Header, Cookie, URL.

Ưu điểm: Rất linh hoạt, hỗ trợ Microservices cực tốt.
Nhược điểm: Tốn tài nguyên hơn vì giải mã và đọc dữ liệu

4. Các "Gương mặt vàng" trong làng LB

Nếu anh em đang phân vân không biết dùng gì thì đây là vài gợi ý:

NGINX: "Hoa hậu" trong giới Web Server kiêm luôn Load Balancer. Dễ cấu hình, cộng đồng cực lớn.
HAProxy: Chuyên dụng cho cân bằng tải. Nếu anh em cần hiệu năng thuần túy và độ ổn định cao nhất, hãy chọn HAProxy.
Cloud Load Balancers: AWS (ALB/NLB), Google Cloud Load Balancing, Azure LB. Phù hợp cho anh em làm Cloud-native, lười cấu hình tay và muốn tự động scale.

5. Những lưu ý "xương máu" khi triển khai\

Nhiều anh em cứ dựng LB lên là xong, nhưng thực tế thường phát sinh vài vấn đề:

Session Persistence (Sticky Sessions): Nếu Server 1 giữ phiên đăng nhập của User, mà request sau LB đẩy sang Server 2 thì User sẽ bị... văng ra ngoài. Giải pháp là dùng Redis để quản lý Session tập trung hoặc dùng Sticky Sessions trên LB.
Health Checks: Đừng chỉ đẩy request đi rồi mặc kệ. LB cần phải liên tục "hỏi thăm" (Health Check) các server phía sau. Ông nào không trả lời là phải "cách ly" ngay lập tức.
Single Point of Failure: LB mà chết thì cả hệ thống chết. Vì vậy, bản thân LB cũng phải có ít nhất 2 con chạy song song (Active-Passive hoặc Active-Active) thông qua các cơ chế như Keepalived hoặc Floating IP.

Lời kết

Load Balancing không chỉ là cài đặt một phần mềm, nó là tư duy về việc xây dựng hệ thống Scalable và Reliable. Hy vọng bài viết này giúp anh em có cái nhìn tổng quan và tự tin hơn khi bắt tay vào thiết kế kiến trúc cho dự án của mình.

Anh em có kinh nghiệm gì hay về việc "vật lộn" với Load Balancer không? Hãy để lại comment phía dưới để chúng ta cùng thảo luận nhé!

Chúc anh em code ít bug và hệ thống luôn uptime 99.99%! 🚀