Faktory工作协议(FWP)深度解析

Faktory工作协议(FWP)深度解析

faktory Language-agnostic persistent background job server 项目地址: https://gitcode.com/gh_mirrors/fa/faktory

协议概述

Faktory工作协议(FWP)是Faktory工作服务器与客户端交互的核心协议，它定义了客户端如何与服务器通信、提交工作任务、获取任务并报告执行结果。作为分布式任务处理系统的基础，FWP协议的设计直接影响着系统的可靠性、性能和扩展性。

协议基础架构

连接层

FWP协议建立在可靠的TCP数据流之上，默认监听7419端口。协议采用请求-响应模式，每个客户端命令后跟随一个服务器响应。

消息格式

客户端命令采用CRLF终止的文本行格式，格式严格规范：

命令动词 [参数1 参数2...]\r\n

服务器响应采用Redis RESP协议格式，这是一种简单高效的二进制安全协议，支持多种数据类型：

• 简单字符串：以"+"开头
• 错误：以"-"开头
• 整数：以":"开头
• 批量字符串：以"$"开头
• 数组：以"*"开头

工作任务(Work Unit)详解

工作任务(或称作业)是FWP协议的核心概念，采用JSON格式表示，包含以下关键字段：

必填字段

• jid：全局唯一任务ID
• jobtype：任务类型标识符
• args：任务执行参数数组

可选字段

• queue：任务队列名称(默认"default")
• reserve_for：任务保留时间(秒，默认1800)
• at：计划执行时间(RFC3339格式)
• retry：重试次数(默认25次)
• backtrace：失败信息保留行数

任务生命周期状态

1. SCHEDULED：任务已提交但未到执行时间
2. ENQUEUED：任务已进入执行队列
3. WORKING：任务已被消费者获取并执行中
4. RETRIES：任务执行失败等待重试
5. DEAD：任务重试次数耗尽

状态转换图展示了任务从创建到完成的完整生命周期，开发者需要理解每个状态的转换条件和触发机制。

客户端生命周期管理

FWP客户端具有明确的状态机模型：

1. 未认证状态：初始状态，必须发送HELLO命令
2. 已认证状态：可执行各类命令
3. 静默状态：收到服务器Quiet指令，停止获取新任务
4. 终止状态：收到服务器Terminate指令，准备关闭
5. 结束状态：连接终止

消费者客户端必须定期发送BEAT心跳命令(推荐15秒间隔)，以接收服务器状态变更指令。

核心命令详解

基础命令

HELLO

• 功能：客户端认证
• 参数：包含版本号等信息的JSON对象
• 安全认证：支持SHA256加盐哈希密码
• 消费者需额外提供wid、hostname等信息

FLUSH

• 功能：清空服务器数据库
• 使用场景：测试环境重置

INFO

• 功能：获取服务器信息
• 返回：服务器状态统计信息

END

• 功能：优雅关闭连接
• 最佳实践：消费者应先处理完现有任务

生产者命令

PUSH

• 功能：提交新任务
• 参数：完整的工作任务JSON对象
• 注意事项：需包含必填字段

消费者命令

FETCH

• 功能：获取待执行任务
• 参数：可选队列名称列表
• 行为：阻塞式获取(最长2秒)
• 后续操作：必须发送ACK或FAIL

ACK

• 功能：确认任务成功完成
• 参数：任务jid
• 注意事项：确保幂等性

FAIL

• 功能：报告任务失败
• 参数：失败详情(errtype, message等)
• 后续处理：根据retry策略决定重试或标记为DEAD

BEAT

• 功能：消费者心跳
• 响应：可能包含状态变更指令(Quiet/Terminate)
• 频率：5-60秒之间(推荐15秒)

协议实现建议

1. 严格遵循协议规范：空格、参数顺序等细节都会影响交互
2. 错误处理：妥善处理各种错误响应
3. 连接管理：实现自动重连机制
4. 状态管理：完整实现客户端状态机
5. 性能优化：复用连接、批量操作等

安全考虑

1. 生产环境必须启用密码认证
2. 敏感信息不应放在任务参数中
3. 实现适当的权限控制
4. 考虑网络传输加密(TLS)

Faktory工作协议通过简洁而严谨的设计，为分布式任务处理提供了可靠的基础。理解并正确实现这一协议，是构建稳定高效的任务处理系统的关键。

faktory Language-agnostic persistent background job server 项目地址: https://gitcode.com/gh_mirrors/fa/faktory