EZRA：基于 Erlang/OTP 与 SQLite 的轻量级持久化任务队列深度解读

背景

在现代应用架构中，几乎所有服务都需要处理异步任务——例如发送电子邮件、生成 PDF 报告或调用响应缓慢的外部 API。为了保持用户体验的流畅性，开发者通常希望立即向用户返回响应，而在后台处理这些耗时操作。如果处理失败，系统需要能够重试；如果服务器重启，已提交的任务不能丢失。这就是任务队列（Task Queue）存在的核心价值。

然而，现有的成熟解决方案（如 RabbitMQ、Kafka 或云厂商托管的消息队列服务）往往伴随着巨大的运维开销。对于不需要每秒处理百万级请求（RPS）的团队来说，部署集群、维护专用服务器、积累复杂的运维知识或依赖特定的云提供商，属于典型的“过度工程”（Overengineering）。许多团队因此选择放弃持久化队列，转而使用内存中的作业系统，但这导致了服务器重启时任务静默丢失的风险。

在此背景下，EZRA 作为一个极简主义的项目应运而生。它由单一作者维护，旨在提供一种无需复杂配置、无集群依赖、基于标准协议且易于调试的持久化任务队列方案。

核心内容

EZRA 是一个基于 Erlang/OTP 运行时环境构建的持久化任务队列，其底层数据存储依赖于 SQLite。它的核心理念是“轻量”与“零额外依赖”，通过复用现有的 Redis 客户端协议，使得任何语言编写的生产者或消费者都能无缝接入。

1. 架构设计与技术选型

• 运行时与存储：EZRA 运行在 Erlang/OTP 之上，利用其高并发和稳定性优势。数据持久化使用 SQLite 单文件数据库（ezra.db），所有数据均落盘，确保服务重启后任务不丢失。
• 通信协议：EZRA 实现了 RESP3 协议（Redis 使用的网络协议）的子集，具体对应 Redis Streams 的功能。这意味着任何支持 Redis 客户端的编程语言（Python, Node.js, Go, Ruby, Java 等）都可以直接连接 EZRA，无需安装新的 SDK。
• 部署极简：整个服务仅需一个二进制文件或 Docker 容器。无需配置 Broker，无需集群设置，无需预创建队列（首次推送时自动创建）。

2. 核心工作机制

EZRA 暴露了一个 TCP 端口（默认 42002），外部客户端通过标准 Redis 命令与之交互。它主要实现了以下命令：

• XADD：将任务推入指定名称的队列。
• XREADGROUP：从队列中弹出下一个任务并认领。支持阻塞模式（Blocking），当没有任务时，连接保持打开状态直到有新任务到达，从而避免轮询（Polling）开销。
• XACK：确认任务已成功处理。
• XDEL / XNACK：报告任务失败。EZRA 会将任务返回以供重试，而不是直接删除。

3. 任务生命周期

EZRA 强调“显式追踪”，任务不会静默丢失。其状态流转如下：

1. Available（可用）：任务被推入队列后的初始状态。
2. In-flight（进行中）：Worker 通过 XREADGROUP 领取任务。此时任务对该 Worker 可见，其他 Worker 无法领取。
3. Done（完成）：Worker 处理成功后发送 XACK，任务被标记为完成并从活跃队列移除。
4. Dead（死信）：如果任务失败次数超过 max_attempts（默认 3 次）或超时且无重试次数，任务进入死信队列（<queue>::dead），但仍可通过查询接口读取，确保数据可审计。

异常处理机制：

• Worker 崩溃/断开：任务保持 in-flight 状态。经过 visibility_timeout（默认 30 秒）后，EZRA 的调度器会回收该任务，将其重置为 available，并增加尝试次数。
• EZRA 服务崩溃：重启后，EZRA 会立即将所有 in-flight 的任务重置为 available，然后才接受新连接。这保证了“至少一次”（At-least-once）交付语义，即任务可能会重复执行，但绝不会丢失。
• Worker 缓慢：如果 Worker 在超时前未发送 XACK，任务会被重新分配给其他 Worker。

4. 并发与扩展性

• 多生产者/多消费者：任意数量的生产者可以同时向同一队列推送任务；任意数量的 Worker 可以从同一队列拉取任务。每个任务仅被一个 Worker 处理，不会重复。
• Worker 标识：每个 Worker 进程需要提供唯一的名称（如 worker-1），EZRA 据此追踪哪些任务由哪个进程处理。
• 按需分发：Worker 主动拉取任务。一旦任务可用，EZRA 立即交付，无需轮询。
• 扩展方式：通过增加运行在任意机器上的 Worker 实例来扩展吞吐量，无需修改 EZRA 配置或进行节点协调。

5. 性能与权衡

• 吞吐量限制：由于底层是 SQLite，吞吐量受限于磁盘写入速度。引擎本身的开销极低，每调用约增加 1–5 µs。
• 单节点限制：EZRA 是单节点架构，所有数据存储在运行该服务的同一台机器上。如果该机器宕机，队列服务将不可用。但数据本身是安全的（SQLite 文件），可通过标准文件同步工具（如 rsync, litestream）进行备份或复制。
• 非 Exactly-once：EZRA 不提供“恰好一次”（Exactly-once）语义，而是“至少一次”。这是为了在网络环境中简化设计而做出的有意选择。

关键要点

• 零 SDK 依赖：通过实现 RESP3 协议，EZRA 兼容所有现有的 Redis 客户端库，开发者无需学习新的 API 或安装特定语言的 SDK。
• 持久化与安全性：基于 SQLite 的持久化存储确保了任务在服务重启后不丢失；所有任务状态显式追踪，无静默丢弃。
• 极简部署：单二进制/Docker 镜像，单文件数据库，无集群、无 Broker、无预配置，开箱即用。
• 显式确认机制：采用类似 Redis Streams 的 XACK 机制，确保任务在成功处理前不会被移除，支持失败重试和死信队列。
• 阻塞式拉取：Worker 使用阻塞模式连接，EZRA 在有任务时立即推送，消除了轮询带来的资源浪费和延迟。
• 单节点架构：适用于中小规模场景或作为轻量级替代方案，不适合高可用集群需求；数据安全性依赖于宿主机和文件备份策略。
• 语言无关性：生产者（Producer）和消费者（Worker）可以使用任何拥有 Redis 客户端的语言（Python, Go, Node.js 等）编写，并部署在任意可达的机器上。

意义与影响

EZRA 的出现填补了“内存队列”与“重型分布式消息中间件”之间的空白。对于大多数中小型应用、初创公司或内部工具而言，引入 RabbitMQ 或 Kafka 往往意味着巨大的运维成本和复杂性，而使用内存队列又带来了数据丢失的风险。

EZRA 提供了一种“恰到好处”的中间方案：

1. 降低技术门槛：通过复用 Redis 协议，它消除了开发者学习新协议或维护新基础设施的成本。
2. 提升可靠性：将任务持久化到 SQLite，解决了内存队列重启丢失数据的核心痛点，同时保持了极低的延迟和开销。
3. 促进架构简化：它证明了在不需要极高并发（百万级 RPS）的场景下，单节点、单文件的架构足以满足需求，且具备足够的可观测性（可直接查看 SQLite 数据库内容）。

尽管 EZRA 明确声明不接受 Pull Requests 且仅由单一作者维护，限制了其在企业级大规模定制方面的潜力，但它作为一个概念验证和轻量级解决方案，为开发者提供了一种摆脱“过度工程”的可行路径。它提醒我们，在解决工程问题时，有时最简单的工具往往是最有效的。