Trong thế giới hệ thống phân tán, cân bằng tải (load balancing) là yếu tố sống còn để đảm bảo hiệu năng và độ sẵn sàng cao (High Availability). Một trong những thuật toán cơ bản và phổ biến nhất được sử dụng trong các Load Balancer là Round Robin – phương pháp xoay vòng phân phối yêu cầu.

Vậy Round Robin là gì, hoạt động như thế nào, và khi nào nên (hoặc không nên) sử dụng? Hãy cùng tìm hiểu chi tiết trong bài viết này.

1. Round Robin là gì?

Round Robin (tạm dịch: “xoay vòng”) là một thuật toán phân phối tải đơn giản, trong đó mỗi yêu cầu (request) được gửi lần lượt đến từng máy chủ trong danh sách, theo thứ tự tuần tự và lặp lại liên tục.

Ví dụ, giả sử bạn có ba server:

  • Server A

  • Server B

  • Server C

Thứ tự phân phối yêu cầu sẽ như sau:

Request 1 → Server A  
Request 2 → Server B  
Request 3 → Server C  
Request 4 → Server A  
Request 5 → Server B  
...

Cứ như vậy, các server được “xoay vòng” để đảm bảo mỗi máy chủ nhận số lượng yêu cầu gần như ngang nhau.

2. Cách hoạt động của Round Robin

Round Robin thường được triển khai ở tầng Load Balancer, chẳng hạn như Nginx, HAProxy, Traefik, hoặc Application Load Balancer (ALB) trên AWS.

Thuật toán hoạt động theo nguyên tắc:

  1. Duy trì một danh sách các backend server đang hoạt động.

  2. Khi có một yêu cầu mới, load balancer sẽ chọn server kế tiếp trong danh sách.

  3. Sau khi tới server cuối cùng, con trỏ quay lại đầu danh sách.

  4. Nếu một server bị lỗi hoặc tạm ngưng, nó sẽ bị loại ra khỏi danh sách phân phối cho đến khi hoạt động trở lại.

Ví dụ cấu hình Nginx:

upstream backend_servers {
    server 192.168.0.1;
    server 192.168.0.2;
    server 192.168.0.3;
}

server {
    listen 80;
    location / {
        proxy_pass http://backend_servers;
    }
}

Với cấu hình mặc định này, Nginx sẽ sử dụng Round Robin để phân phối request.

3. Ưu điểm của Round Robin

  • Đơn giản và dễ triển khai: Không yêu cầu thu thập dữ liệu hiệu năng hay trạng thái server.

  • Phù hợp với các hệ thống đồng nhất: Khi các server có cấu hình và hiệu năng tương đương, Round Robin mang lại hiệu quả tối ưu.

  • Không cần lưu trạng thái (stateless): Dễ mở rộng theo chiều ngang, đặc biệt trong microservices hoặc container environments.

4. Hạn chế của Round Robin

Dù đơn giản, Round Robin không phải lúc nào cũng tối ưu:

  • Không quan tâm đến tải thực tế: Một server có thể đang xử lý nhiều request nặng, trong khi server khác nhàn rỗi, nhưng load balancer vẫn tiếp tục gửi yêu cầu theo vòng.

  • Không phù hợp cho session-based systems: Nếu ứng dụng yêu cầu người dùng duy trì session (ví dụ: giỏ hàng, đăng nhập), việc chuyển request liên tục giữa các server có thể gây lỗi hoặc mất session (trừ khi dùng sticky session hoặc session storage chung).

  • Không cân bằng được hiệu năng không đồng đều: Trong môi trường có server mạnh – yếu khác nhau, phương pháp này dẫn đến hiệu suất không tối ưu.

5. Các biến thể phổ biến của Round Robin

a. Weighted Round Robin (Round Robin có trọng số)

Trong phiên bản này, mỗi server được gán một trọng số (weight) phản ánh khả năng xử lý.

Server mạnh hơn sẽ nhận nhiều request hơn.

Ví dụ:

Server A (weight = 3)
Server B (weight = 1)
Server C (weight = 2)

Thứ tự phân phối có thể như:

A, A, A, B, C, C, ...

Cấu hình ví dụ trong Nginx:

upstream backend_servers {
    server 192.168.0.1 weight=3;
    server 192.168.0.2 weight=1;
    server 192.168.0.3 weight=2;
}

b. Dynamic Round Robin

Một số load balancer hiện đại (như HAProxy) có thể điều chỉnh trọng số theo thời gian thực dựa trên metric CPU, memory hoặc response time.

6. Khi nào nên dùng Round Robin

Round Robin rất phù hợp trong các trường hợp:

  • Hệ thống có các backend đồng nhất về cấu hình và năng lực xử lý.

  • Ứng dụng stateless (không phụ thuộc session).

  • Nhu cầu đơn giản, cần phân phối nhanh, không muốn theo dõi health metrics phức tạp.

  • Muốn giảm chi phí và dễ bảo trì load balancer.

Ví dụ điển hình:

  • API Gateway phân phối request đến nhiều instance backend giống nhau.

  • Web service scale bằng nhiều container (Docker, Kubernetes Deployment).

  • Các hệ thống có traffic ổn định và tải trung bình.

7. Khi nào không nên dùng Round Robin

Bạn nên cân nhắc thuật toán khác (Least Connection, IP Hash, hoặc Dynamic Load Balancing) nếu:

  • Server có hiệu năng khác nhau.

  • Ứng dụng có session hoặc state lưu ở memory.

  • Tải (load) không đồng đều theo thời điểm.

  • Cần tối ưu hiệu suất ở quy mô lớn (ví dụ hàng chục nghìn request/giây).

8. Kết luận

Round Robin là thuật toán nền tảng trong cân bằng tải – đơn giản, dễ hiểu, và vẫn được sử dụng rộng rãi trong thực tế.

Dù không hoàn hảo, nhưng với những hệ thống đồng nhất, stateless, và yêu cầu tốc độ triển khai nhanh, Round Robin luôn là lựa chọn hợp lý.

Khi hệ thống phát triển và yêu cầu phức tạp hơn, bạn có thể nâng cấp sang Weighted Round Robin hoặc Least Connection để đạt hiệu năng tốt hơn.

Round Robin giống như một chiếc vòng quay công bằng – mỗi server đều có cơ hội được “phục vụ” request, giúp hệ thống của bạn hoạt động trơn tru mà không cần quá nhiều cấu hình phức tạp.