Offline Queue：原理、策略与工作机制

什么是离线队列？

Offline Queue — 是应用程序在设备无法访问网络时本地存储的操作（创建、更新、删除）的有序集合。一旦连接恢复，队列将按照用户执行操作的顺序将操作发送到服务器。

设想一个场景：即时通讯应用的用户在地铁中无网络情况下输入消息。每次点击 “发送” 都会添加到 Offline Queue。当列车驶出隧道且网络恢复时，所有消息将自动发送。用户体验 — 无缝衔接：除发送时稍有延迟外，用户完全察觉不到自己曾处于离线状态。

根据 Uber Engineering (2024) 的数据，他们的离线队列在网络质量较低的地区每天处理超过 200 万次操作。该队列使用 Room 本地存储，采用 FIFO 顺序和 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
)

每个操作包含重新发送所需的所有数据：端点、请求体、时间戳和 idempotencyKey。Room 数据库 可确保在应用重启和操作系统崩溃时队列不丢失。

为什么移动应用需要操作队列

投递保证 — 队列的主要任务。用户必须确信其操作（发送消息、点赞、下单）即使网络在执行时不可用也能被执行。带有重试机制的 Offline Queue 确保最终投递。

改善弱网环境下的用户体验 — 根据 GSMA Mobile Economy Report (2025)，全球约 40% 的移动用户网络连接不稳定。Offline Queue 使应用在地铁、电梯、偏远地区等所有连接断断续续的地方都能正常使用。

减少数据丢失 — 没有队列，所有离线操作都将丢失。用户可能填写了很长的表单，点击 “发送” 后却看到网络错误——所有输入都丢失了。Offline Queue 保存数据并在第一时间发送。Google Docs 的自动保存 就是离线队列在文档中的经典示例。

异步同步 — 队列允许应用在发送期间不阻塞 UI。用户继续工作，而同步管理器在后台处理队列。这符合 Reactive Architecture 原则，并能改善界面响应速度。

离线队列架构：存储与处理

队列的三层结构：存储层（persistence）、调度层（scheduler）和执行层（executor）。存储层 — 使用 QueuedOperation 表的 Room。调度层 — WorkManager（Android）或 BGTaskScheduler（iOS），在网络恢复时启动同步。执行层 — 顺序 FIFO 迭代器，逐个发送操作。

处理顺序 — 对数据一致性至关重要。如果用户创建了一条记录，随后又编辑了它，这两个操作必须按相同顺序发送。否则，服务器会先收到对不存在记录的更新——导致错误。Sequential FIFO — 严格顺序，操作之间带有依赖关系控制。

合并策略 — 如果队列中有同一对象的 CREATE 后紧跟 DELETE，可以删除这两个操作而不发送：最终状态是该对象未被创建。同样，CREATE 后的 UPDATE 可以合并为一条包含最新数据的 CREATE。队列优化 可减少 HTTP 请求数量并加速同步。

根据 Android Developers (2025) 的说明，WorkManager 是在 Android 上处理 Offline Queue 的首选方式：它能保证即使在设备重启后也能执行，支持网络约束条件，并允许通过 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 处理操作批次，在失败时返回 Result.retry() — WorkManager 自动以指数延迟重新启动。这是在 Android 上获得可靠 Offline Queue 的最简单方法。

重试策略：指数退避和重试策略

Exponential Backoff — 标准的递增间隔重试策略：2 秒、4 秒、8 秒、16 秒，依此类推直到最大阈值。这可以防止在服务器暂时不可用时重复过载。Java 库 Resilience4j (2024) 提供了带有可配置退避策略的现成 Retry 实现。

最大重试次数 — 关键参数。如果操作在 5–10 次尝试后仍未成功，继续重试只会浪费资源。建议使用 dead letter queue：尝试耗尽后，操作移至单独的表进行人工分析。根据 Microsoft Patterns & Practices (2024)，dead letter queue 可简化同步问题的调试，并防止错误操作阻塞队列。

Jitter — 随机抖动 — 在退避间隔中添加随机数。如果上千台设备在断网后同时恢复网络，它们将同时启动同步。Jitter 将它们分散到不同时间，防止服务器上出现缓存雪崩。完全抖动：delay = random(0, backoff) — AWS (2024) 推荐用于 API 客户端。

冲突解决：如何解决数据冲突

Last Write Wins (LWW) — 最简单的策略：发生冲突时，时间戳较新的操作获胜。LWW 需要时间同步——时间戳必须在服务器上生成或使用逻辑时钟（Lamport clocks）。缺点：一个用户的数据可能被另一个用户的数据覆盖而不发出警告。

OT (Operational Transformation) — Google Docs 和 Figma 用于实时协作（包括离线模式）的算法。OT 转换操作，使其适用于任何文档状态，从而在不加锁的情况下确保一致性。CRDT (Conflict-Free Replicated Data Types) — OT 的替代方案，在移动应用中日益流行：数据以数学方式解决冲突，无需中央服务器。

自定义合并 — 对于数据模型简单的应用（笔记、联系人），可以实现自定义合并规则。例如，对于笔记：如果文本在两个版本中都被修改，则将其作为带分隔符的连接进行合并。用户解决冲突 — 如果自动合并不可行，则向用户显示两个版本并让其选择。Dropbox (2024) 对离线文件冲突采用这种方法，创建带前缀 “Conflicted Copy” 的副本。

Idempotency keys — 防重复保护

Idempotency Key — 服务器用于检测重复请求的唯一操作标识符。如果客户端使用相同的键发送相同的请求，服务器返回已执行操作的结果，而不会再次执行。这对 Offline Queue 至关重要，因为在网络错误时可能发生重复发送。

Idempotency key 的格式 — UUID 或请求参数的哈希值。服务器必须存储 已执行的键及其结果一段时间（通常为 24 小时），以便检测重复。Stripe API (2024) 是典范：键在 Idempotency-Key 标头中传递，使用相同键的重复请求返回缓存的响应。

客户端生成 — 键在发送操作之前在客户端创建，并保存在 QueuedOperation 表中。重试时键不会更改。Exactly-once 架构 — 客户端上的 idempotency key 与服务器上的去重相结合，是确保操作不会被执行两次的唯一方法。

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()
    )

每个操作获得两个 UUID：一个是队列中的记录标识符，另一个是用于服务器的 idempotency key。基于 idempotencyKey 的服务端去重 可确保即使重新发送，订单也不会被重复。