Exponential Backoff & Jitter: Chìa Khóa Vàng Giúp Ứng Dụng Của Bạn Bất Chấp Lỗi Mạng!

Lê Lân

28/07/2025

Thuật Toán Exponential Backoff Trong Retry Request: Giải Pháp Tối Ưu Cho Hệ Thống Phân Tán

Mở Đầu

Trong thế giới lý tưởng, mọi yêu cầu mạng sẽ hoàn thành ngay lập tức và thành công. Nhưng trong thực tế, API có thể lỗi, mạng đứt kết nối, máy chủ có thể bị quá tải hoặc gặp sự cố tạm thời. Thay vì bỏ cuộc ngay sau lần thử đầu tiên thất bại, việc retry với chiến lược thông minh sẽ giúp ứng dụng của bạn trở nên kiên cường và ổn định hơn.

Thuật toán Exponential Backoff đã được chứng minh là một phương pháp hiệu quả và tôn trọng tài nguyên hệ thống khi retry các yêu cầu mạng hay API. Bài viết sẽ giải thích chi tiết tại sao yêu cầu mạng thường thất bại, những vấn đề khi retry sơ khai, cơ chế hoạt động của exponential backoff, cách thêm jitter, ví dụ triển khai thực tế và các best practice mà bạn cần biết khi áp dụng.

Tại Sao Yêu Cầu Mạng Thường Thất Bại? 🚧

API hoặc các dịch vụ bên dưới có thể gặp các lỗi tạm thời khiến câu request không thành công như:

🌐 Timeout mạng: kết nối bị ngắt quãng hoặc mất thời gian phản hồi lâu

📶 Sự cố internet tạm thời: đứt cáp, mất tín hiệu hoặc chuyển vùng

🚦 Rate limiting (429 Too Many Requests): máy chủ giới hạn số lượng yêu cầu trong một khoảng thời gian

🔧 Quá tải máy chủ (5xx errors): server xử lý không kịp hoặc đang bảo trì

Trong các trường hợp này, việc thử lại request sau một khoảng thời gian chờ hợp lý thường sẽ thành công.

Vấn Đề Với Retry Đơn Giản ✅

Nếu mọi client đều cố gắng retry ngay tức thì sau khi thất bại, server sẽ bị quá tải do lượng request đồng thời tăng đột biến. Hiện tượng này còn gọi là thundering herd problem (bầy cừu đồng loạt lao vào làm server quá tải). Kết quả là hệ thống càng thêm suy yếu dẫn đến lỗi nghiêm trọng hơn.

Chúng ta cần một cách retry thông minh hơn — không retry ngay lập tức mà có sự điều chỉnh về thời gian chờ giữa các lần thử, giúp giảm tải cho server trong giai đoạn phục hồi.

Exponential Backoff Là Gì? ⏳

Exponential backoff là thuật toán tăng thời gian chờ giữa các lần retry theo hàm mũ để tránh gây tắc nghẽn cho hệ thống.

Công Thức Tính Thời Gian Chờ

﻿

Trong đó:

baseDelay là khoảng thời gian chờ cơ bản (ví dụ 500ms)

attemptNumber là số lần retry đã thực hiện

Ví Dụ Thời Gian Chờ Với Base Delay = 500ms

Lần retry	Thời gian chờ (ms)
1	500
2	1,000
3	2,000
4	4,000
5	8,000

Việc tăng dần thời gian chờ giúp giảm nhanh số request đồng thời, tạo cơ hội cho server phục hồi.

Thêm Jitter Để Tránh Đồng Bộ Hóa 🔀

Khi tất cả client đều retry theo cùng một chu kỳ, chúng sẽ đồng loạt gửi request sau khoảng thời gian chờ nhất định gây ra hiện tượng “đồng hồ sinh học” (synchronized retries), làm tăng áp lực lên server.

Jitter là cách thêm yếu tố ngẫu nhiên vào thời gian delay giúp phân tán request đồng thời tránh tắc nghẽn.

const jitter = Math.random() * 100;
const delay = baseDelay * 2 ** attempt + jitter;

Ví Dụ Triển Khai Trong JavaScript (Node.js) 🧪

async function fetchWithRetry(url, options = {}, maxRetries = 5, baseDelay = 500) {
  for (let attempt = 0; attempt <= maxRetries; attempt++) {
    try {
      const response = await fetch(url, options);
      if (!response.ok && response.status >= 500) {
        throw new Error(`Server error: ${response.status}`);
      }
      return response;
    } catch (error) {
      if (attempt === maxRetries) {
        throw new Error(`Failed after ${maxRetries + 1} attempts: ${error.message}`);
      }
      const backoff = baseDelay * 2 ** attempt;
      const jitter = Math.random() * 100;
      const delay = backoff + jitter;
      console.warn(`Attempt ${attempt + 1} failed. Retrying in ${delay.toFixed(0)}ms...`);
      await new Promise((r) => setTimeout(r, delay));
    }
  }
}

Phần code trên minh họa cách retry với exponential backoff cộng jitter, giúp giảm áp lực server và tăng khả năng thành công.

Lỗi Nào Nên Retry? 💡

Không phải tất cả lỗi đều phù hợp để thử lại. Dưới đây là phân loại các lỗi thường gặp:

Mã lỗi	Mô tả	Retry?
500	Internal Server Error	✅ Có
503	Service Unavailable	✅ Có
429	Too Many Requests	✅ Có
400	Bad Request	❌ Không
401/403	Unauthorized/Forbidden	❌ Không

Ngoài ra, khi gặp lỗi rate limiting (429), nên kiểm tra header <u>Retry-After</u> nếu có để chờ đúng khoảng thời gian mà server yêu cầu:

HTTP/1.1 429 Too Many Requests
Retry-After: 120

Ví Dụ Thực Tiễn Trong Thế Giới Thực 🌍

Stripe API: Tự động retry các lỗi 409, 429 và 5xx với exponential backoff.

Google Cloud APIs: Khuyến cáo dùng exponential backoff với jitter để xử lý lỗi tạm thời.

AWS SDKs: Áp dụng jitter mở rộng (full jitter) để tối ưu việc phân phối request retry.

Các Best Practices Bạn Cần Biết 📋

✅ Retry chỉ cho các lỗi tạm thời có khả năng thành công khi thử lại.

✅ Giới hạn số lần retry để tránh vòng lặp vô hạn.

✅ Thêm jitter để giảm sự đồng bộ các retry.

✅ Sử dụng header Retry-After từ server nếu có.

✅ Ghi log đầy đủ metadata retry để dễ dàng debug.

Tích Hợp Redis Để Quản Lý Retry Thông Minh 🧠

Trong những trường hợp cần độ bền vững retry cao hoặc các tác vụ đắt giá, việc sử dụng Redis làm bộ nhớ trung gian giúp:

Lưu số lần retry để tránh retry quá giới hạn dù process khởi động lại.

Đồng bộ trạng thái retry trên nhiều instance phân tán.

Thiết lập TTL để tự động xóa metadata khi không cần nữa.

const retryKey = `retry:${jobId}`;
const attempt = await redis.get(retryKey) || 0;
if (attempt > maxRetries) throw new Error('Too many retries');
await redis.set(retryKey, attempt + 1, 'EX', retryExpirySeconds);

Các API Thử Nghiệm Dễ Dàng Tại Nhà 🌐

httpstat.us — Trả về HTTP status code theo yêu cầu, có hỗ trợ delay.

https://httpstat.us/503 — Giả lập lỗi 503

https://httpstat.us/500?sleep=2000 — Lỗi 500 với delay 2 giây

https://httpstat.us/429 — Lỗi Rate Limiting

https://httpstat.us/200 — Thành công

reqres.in — Fake API REST dùng để thử nghiệm.

https://reqres.in/api/users/2 — Yêu cầu hợp lệ

https://reqres.in/api/users/23 — Trả về 404 Not Found

Kết Luận 🚀

Trong hệ thống phân tán hiện đại, lỗi không phải là ngoại lệ mà là điều được mong đợi. Việc cập nhật chiến lược retry thông minh với thuật toán exponential backoff kèm jitter giúp hệ thống trở nên kiên cường hơn, thân thiện hơn với server và phù hợp triển khai trong môi trường thực tế.

Đừng retry một cách mù quáng! Hãy cân nhắc kỹ thuật thuật toán, giới hạn retry và tránh đồng bộ để có hiệu quả tối ưu. Việc xử lý lỗi có dụng ý cũng là cách giúp ứng dụng của bạn hoàn thiện và tạo ra trải nghiệm người dùng tốt hơn.

Bonus: Tích Hợp Exponential Backoff Với Axios ✍️

const axios = require('axios');

async function axiosRetry(url, options = {}, retries = 3, baseDelay = 300) {
  for (let i = 0; i <= retries; i++) {
    try {
      return await axios(url, options);
    } catch (err) {
      if (i === retries || !shouldRetry(err)) throw err;
      const delay = baseDelay * 2 ** i + Math.random() * 100;
      await new Promise(r => setTimeout(r, delay));
    }
  }
}

function shouldRetry(err) {
  return [429, 500, 503].includes(err.response?.status);
}

Tham Khảo

AWS: Exponential Backoff and Jitter

Google Cloud: Retry Guidelines

Stripe: Idempotent Requests

Fetch API Error Handling

Redis Node.js Client

httpstat.us - HTTP Testing

reqres.in - Fake API

Mocky - Custom Mock API