Offline Queue: nguyên tắc, chiến lược và cơ chế hoạt động

Hàng đợi ngoại tuyến là gì?

Offline Queue là một tập hợp có thứ tự các thao tác (tạo, cập nhật, xóa) mà ứng dụng lưu cục bộ khi thiết bị không có quyền truy cập mạng. Sau khi kết nối được khôi phục, hàng đợi sẽ gửi các thao tác đến máy chủ theo đúng thứ tự người dùng đã thực hiện.

Hãy tưởng tượng một kịch bản: người dùng ứng dụng nhắn tin gõ tin nhắn trong tàu điện ngầm khi không có internet. Mỗi lần chạm «Gửi» được thêm vào Offline Queue. Khi tàu ra khỏi đường hầm và mạng khả dụng, tất cả tin nhắn được gửi tự động. Trải nghiệm người dùng — liền mạch: họ không nhận thấy mình đã ngoại tuyến, ngoại trừ một chút chậm trễ khi gửi.

Theo Uber Engineering (2024), hàng đợi ngoại tuyến của họ xử lý hơn 2 triệu thao tác mỗi ngày ở các khu vực có chất lượng kết nối kém. Hàng đợi sử dụng bộ nhớ cục bộ Room với thứ tự FIFO và cơ chế phân phối đảm bảo exactly-once.

data class QueuedOperation(
    val id: String,
    val type: OperationType,
    val endpoint: String,
    val payload: String,
    val timestamp: Long,
    val retryCount: Int = 0,
    val idempotencyKey: String
)

Mỗi thao tác chứa tất cả dữ liệu cần thiết để gửi lại: điểm cuối, nội dung yêu cầu, dấu thời gian và idempotencyKey. Cơ sở dữ liệu Room đảm bảo tính bền vững của hàng đợi khi khởi động lại ứng dụng và sự cố hệ điều hành.

Tại sao cần hàng đợi thao tác trong ứng dụng di động

Đảm bảo phân phối — mục đích chính của hàng đợi. Người dùng phải chắc chắn rằng hành động của họ (gửi tin nhắn, thích, đặt hàng) sẽ được hoàn thành, ngay cả khi mạng không khả dụng tại thời điểm đó. Offline Queue với cơ chế thử lại đảm bảo phân phối cuối cùng.

Cải thiện UX trong điều kiện kết nối kém — theo GSMA Mobile Economy Report (2025), khoảng 40% người dùng di động trên thế giới có kết nối internet không ổn định. Offline Queue làm cho ứng dụng có thể sử dụng được trong tàu điện ngầm, thang máy, vùng sâu vùng xa — bất cứ nơi nào kết nối không liên tục.

Giảm mất dữ liệu — không có hàng đợi, tất cả các hành động thực hiện ngoại tuyến đều bị mất. Người dùng có thể điền một biểu mẫu dài, chạm «Gửi» và thấy lỗi mạng — toàn bộ dữ liệu nhập bị mất. Offline Queue lưu dữ liệu và gửi chúng ở cơ hội đầu tiên. Tự động lưu trong Google Docs là một ví dụ kinh điển về hàng đợi ngoại tuyến cho tài liệu.

Đồng bộ hóa bất đồng bộ — hàng đợi cho phép ứng dụng không chặn giao diện người dùng trong khi gửi. Người dùng tiếp tục làm việc trong khi trình quản lý đồng bộ xử lý hàng đợi trong nền. Điều này tuân theo các nguyên tắc của Kiến trúc phản ứng và cải thiện khả năng phản hồi của giao diện.

Kiến trúc hàng đợi ngoại tuyến: lưu trữ và xử lý

Ba lớp của hàng đợi: lưu trữ (bền vững), bộ lập lịch (scheduler) và bộ thực thi. Lưu trữ — Room với bảng QueuedOperation. Bộ lập lịch — WorkManager (Android) hoặc BGTaskScheduler (iOS) khởi động đồng bộ khi mạng khả dụng. Bộ thực thi — một vòng lặp FIFO tuần tự gửi từng thao tác một.

Thứ tự xử lý — quan trọng cho tính nhất quán dữ liệu. Nếu người dùng tạo một bản ghi rồi chỉnh sửa nó, cả hai thao tác phải được gửi theo cùng một thứ tự. Nếu không, máy chủ sẽ nhận được bản cập nhật cho một bản ghi không tồn tại — lỗi. FIFO tuần tự — thứ tự nghiêm ngặt với kiểm soát phụ thuộc giữa các thao tác.

Chiến lược hợp nhất — nếu hàng đợi có CREATE và ngay sau đó là DELETE cùng một đối tượng, cả hai thao tác có thể được xóa mà không cần gửi: trạng thái cuối cùng là đối tượng không được tạo. Tương tự, CREATE + UPDATE có thể được hợp nhất thành một CREATE với dữ liệu mới nhất. Tối ưu hóa hàng đợi giảm số lượng yêu cầu HTTP và tăng tốc đồng bộ hóa.

Theo Android Developers (2025), WorkManager là cách ưa thích để xử lý Offline Queue trên Android: nó đảm bảo thực thi ngay cả sau khi khởi động lại thiết bị, hỗ trợ các ràng buộc mạng và cho phép cấu hình chính sách thử lại thông qua NetworkType.CONNECTED.

class SyncWorker(
    private val context: Context,
    private val params: WorkerParameters
) : CoroutineWorker(context, params) {

    override suspend fun doWork(): Result = runCatching {
        queueRepository.processNextBatch(batchSize = 10)
        Result.success()
    }.getOrDefault(Result.retry())
}

CoroutineWorker xử lý các lô thao tác và trả về Result.retry() khi thất bại — WorkManager tự động thử lại với backoff theo cấp số nhân. Đây là cách đơn giản nhất để có được Offline Queue đáng tin cậy trên Android.

Chiến lược thử lại: exponential backoff và chính sách thử lại

Exponential Backoff — chiến lược thử lại tiêu chuẩn với khoảng thời gian tăng dần: 2 giây, 4 giây, 8 giây, 16 giây và tiếp tục đến ngưỡng tối đa. Điều này ngăn quá tải lặp lại máy chủ nếu máy chủ tạm thời không khả dụng. Thư viện Java Resilience4j (2024) cung cấp triển khai Retry sẵn sàng với backoff có thể cấu hình.

Số lần thử tối đa — một tham số quan trọng. Nếu sau 5–10 lần thử thao tác vẫn thất bại, việc thử lại thêm là lãng phí và vô ích. Một dead letter queue được khuyến nghị: sau khi cạn kiệt số lần thử, thao tác được chuyển đến một bảng riêng để phân tích thủ công. Theo Microsoft Patterns & Practices (2024), dead letter queue đơn giản hóa việc gỡ lỗi các vấn đề đồng bộ và ngăn các thao tác lỗi làm tắc nghẽn hàng đợi.

Jitter — biến thiên ngẫu nhiên — thêm một số ngẫu nhiên vào khoảng thời gian backoff. Nếu một nghìn thiết bị đồng thời khôi phục mạng sau khi mất kết nối, tất cả chúng đều bắt đầu đồng bộ cùng lúc. Jitter phân tán chúng theo thời gian, ngăn Cache Stampede trên máy chủ. Jitter hoàn toàn: delay = random(0, backoff) — được AWS (2024) khuyến nghị cho các ứng dụng khách API.

Giải quyết xung đột: cách giải quyết va chạm dữ liệu

Last Write Wins (LWW) — chiến lược đơn giản nhất: khi xung đột, thao tác có dấu thời gian muộn hơn sẽ thắng. LWW yêu cầu đồng bộ thời gian — dấu thời gian phải được tạo trên máy chủ hoặc sử dụng Đồng hồ logic (đồng hồ Lamport). Nhược điểm: dữ liệu của người dùng này có thể bị ghi đè bởi dữ liệu của người dùng khác mà không có cảnh báo.

OT (Biến đổi thao tác) — thuật toán được Google Docs và Figma sử dụng cho chỉnh sửa cộng tác thời gian thực, bao gồm cả chế độ ngoại tuyến. OT biến đổi các thao tác để chúng có thể áp dụng cho mọi trạng thái tài liệu, đảm bảo tính nhất quán mà không cần khóa. CRDT (Kiểu dữ liệu sao chép không xung đột) — một giải pháp thay thế cho OT đang trở nên phổ biến trong các ứng dụng di động: dữ liệu được cấu trúc để xung đột có thể giải quyết bằng toán học mà không cần máy chủ trung tâm.

Hợp nhất tùy chỉnh — cho các ứng dụng có mô hình dữ liệu đơn giản (ghi chú, danh bạ), có thể triển khai các quy tắc hợp nhất tùy chỉnh. Ví dụ, cho một ghi chú: nếu văn bản được sửa đổi trong hai phiên bản, hợp nhất chúng dưới dạng nối chuỗi với dấu phân cách. Xung đột do người dùng giải quyết — nếu không thể hợp nhất tự động, hiển thị cho người dùng cả hai phiên bản và để họ chọn. Dropbox (2024) sử dụng cách tiếp cận này cho xung đột tệp ngoại tuyến, tạo các bản sao với tiền tố «Conflicted Copy».

Idempotency keys — bảo vệ khỏi trùng lặp

Idempotency Key — một định danh thao tác duy nhất mà máy chủ sử dụng để phát hiện các yêu cầu trùng lặp. Nếu máy khách gửi cùng một yêu cầu với cùng một khóa, máy chủ trả về kết quả của thao tác đã hoàn thành mà không thực hiện lại. Điều này cực kỳ quan trọng đối với Offline Queue, nơi có thể xảy ra gửi lại do lỗi mạng.

Định dạng của idempotency key là UUID hoặc hàm băm của các tham số yêu cầu. Máy chủ phải lưu trữ các khóa đã hoàn thành cùng với kết quả trong một khoảng thời gian (thường 24 giờ) để phát hiện trùng lặp. API Stripe (2024) là ví dụ tham chiếu: khóa được truyền trong tiêu đề Idempotency-Key và các yêu cầu lặp lại với cùng khóa trả về phản hồi được lưu trong bộ nhớ đệm.

Tạo phía máy khách — khóa được tạo trên máy khách trước khi gửi thao tác và được lưu trong bảng QueuedOperation. Khi thử lại, khóa không thay đổi. Kiến trúc exactly-once — sự kết hợp của idempotency key trên máy khách và khử trùng lặp trên máy chủ là cách duy nhất để đảm bảo rằng một thao tác không được thực hiện hai lần.

fun createOperation(type: OperationType, payload: String): QueuedOperation =
    QueuedOperation(
        id = UUID.randomUUID().toString(),
        type = type,
        endpoint = type.endpoint,
        payload = payload,
        timestamp = currentTimeMillis(),
        idempotencyKey = UUID.randomUUID().toString()
    )

Mỗi thao tác nhận được hai UUID: một — định danh bản ghi trong hàng đợi, thứ hai — idempotency key cho máy chủ. Khử trùng lặp phía máy chủ bằng idempotencyKey đảm bảo rằng ngay cả khi gửi lại, đơn hàng sẽ không bị trùng lặp.