Workers on HanGR的碎碎念

Cloudflare Workers 异步任务处理与 CPU 限制

Wed, 26 Jun 2024 00:00:00 +0000

问题背景

RuiToolAI 的图片生成流程是：

1
2


用户提交 prompt → 调用大模型 → 返回预测 ID
 → 轮询获取结果 → 下载图片 → 存到 R2 → 返回给用户

图片生成需要 10-30 秒，这就需要一个异步任务处理机制。

最初的方案：waitUntil + 后台轮询

最开始，我想用 Cloudflare Workers 的 waitUntil API 在后台轮询：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


// 提交任务
const predictionId = await SubmitImage({ model, prompt });

// 保存任务到 DB
await db.insert(generatedImageTable).values({
 id: taskId,
 userId,
 status: IMAGE_GEN_STATUS.PROCESSING,
 predictionId,
});

// 启动后台轮询
waitUntil(
 runBackgroundPoll({ taskId, userId, predictionId })
);

// 立即返回给前端
return { taskId };

后台轮询函数：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


async function runBackgroundPoll({ taskId, predictionId }) {
 for (let attempt = 1; attempt <= 60; attempt++) {
 await new Promise(r => setTimeout(r, 3000));

 const prediction = await CheckPrediction(predictionId);

 if (prediction.status === "completed") {
 // 下载 + 存 R2 + 更新 DB
 return;
 }
 }
}

为什么失败了

部署上线后，发现任务永远停留在 processing 状态。

根本原因：Cloudflare Workers 的 setTimeout 不会真正 sleep。

Workers 的运行时是 V8 引擎，不是 Node.js。在 Workers 中：

1

await new Promise(r => setTimeout(r, 3000));

这行代码不会等待 3 秒。它几乎立即继续执行，导致 60 次轮询瞬间跑完，Workers 进程结束，但是大模型还没完成。

此外，waitUntil 在 Workers 中也有 CPU 时间限制：

计划	CPU 限制
免费	10ms
付费	30s（wall clock）
`waitUntil`	30s（wall clock）

即使 setTimeout 能正常 sleep，30 秒的 wall clock 限制也不够轮询完 60 次 × 3 秒 = 3 分钟。

最终方案：前端轮询 Server Action

核心思路： 不在后台轮询，而是让前端每次请求时去问一下状态。

1. 提交任务（同步返回）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


export const generateImageAction = actionClient
 .inputSchema(generateImageSchema)
 .action(async ({ parsedInput }) => {
 // 扣积分
 await ensureBillingAccess({ userId, creditsRequired: 10 });

 // 提交到大模型
 const predictionId = await SubmitImage({ model, prompt });

 // 存 DB（状态 = processing）
 await db.insert(generatedImageTable).values({
 id: taskId,
 userId,
 status: IMAGE_GEN_STATUS.PROCESSING,
 predictionId,
 });

 // 立即返回，不等待结果
 return { taskId };
 });

2. 前端轮询

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


// 每 3 秒调用一次
useEffect(() => {
 if (!pollingTaskId) return;

 const interval = setInterval(() => {
 executePoll({ taskId: pollingTaskId });
 }, 3000);

 return () => clearInterval(interval);
}, [pollingTaskId]);

3. 状态查询 Action（关键）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44


export const checkImageStatusAction = actionClient
 .inputSchema(checkImageStatusSchema)
 .action(async ({ parsedInput }) => {
 const task = await db.query.generatedImageTable.findFirst({
 where: eq(generatedImageTable.id, parsedInput.taskId),
 });

 // 已经完成或失败 → 直接返回
 if (task.status === IMAGE_GEN_STATUS.COMPLETED) {
 return { status: "completed", r2Key: task.r2Key };
 }
 if (task.status === IMAGE_GEN_STATUS.FAILED) {
 return { status: "failed" };
 }

 // 还是在 processing → 查看状态
 const prediction = await CheckPrediction(task.predictionId);

 if (prediction.status === "completed") {
 // 下载图片 + 存 R2 + 更新 DB
 const imageRes = await fetch(prediction.url);
 const buffer = await imageRes.arrayBuffer();
 await env.USER_UPLOADS_BUCKET.put(r2Key, buffer);

 await db.update(generatedImageTable)
 .set({ status: "completed", r2Key })
 .where(eq(generatedImageTable.id, task.id));

 return { status: "completed", r2Key };
 }

 if (prediction.status === "failed") {
 // 退款 + 更新 DB
 await db.update(generatedImageTable)
 .set({ status: "failed" })
 .where(eq(generatedImageTable.id, task.id));

 await addUserCredits(userId, task.creditsCharged);
 return { status: "failed" };
 }

 // 还在处理中
 return { status: "processing" };
 });

用户关闭浏览器后的恢复机制

用户关闭浏览器，再打开时，怎么恢复任务状态？

页面加载时查 DB 里有没有 processing 的任务：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


// page.tsx (Server Component)
const processingTask = await db.query.generatedImageTable.findFirst({
 where: and(
 eq(generatedImageTable.userId, userId),
 eq(generatedImageTable.status, IMAGE_GEN_STATUS.PROCESSING),
 ),
 orderBy: (table, { desc }) => [desc(table.createdAt)],
});

// 传给客户端组件
return <ImageGenClient processingTaskId={processingTask?.id} />;

1
2
3
4
5
6


// site.client.tsx
useEffect(() => {
 if (processingTaskId) {
 setPollingTaskId(processingTaskId);
 }
}, []);

历史页面也自动轮询：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


// 找到所有 processing 状态的任务
const processingIds = items
 .filter(item => item.status === IMAGE_GEN_STATUS.PROCESSING)
 .map(item => item.id);

// 每 4 秒轮询一次
useEffect(() => {
 if (processingIds.length === 0) return;
 const interval = setInterval(() => {
 for (const id of processingIds) {
 pollStatus({ taskId: id });
 }
 }, 4000);
 return () => clearInterval(interval);
}, [processingIds.length]);

总结

方案演进：

版本	方案	问题
v1	waitUntil + setTimeout	setTimeout 不 sleep
v2	前端轮询 + checkImageStatusAction	每个请求独立，无时间限制

关键设计原则：

每次轮询是一个独立的 Worker 请求，不受 CPU 时间限制
用户关闭浏览器后，DB 保留任务状态，回来后可恢复
历史页面自动轮询所有 processing 任务，不需要手动刷新

参考资源

为什么选择 Cloudflare Workers 而不是传统 VPS

Tue, 26 Mar 2024 00:00:00 +0000

背景

在开发 RuiToolAI 这个全栈 SaaS 项目时，面临一个核心问题：部署在哪里？

传统方案是买一台 VPS（如阿里云、AWS EC2），装 Docker，跑 Node.js 服务。但作为一个独立开发者，我不希望把时间花在运维上。于是我调研了 Cloudflare Workers 这个 Serverless 方案，最终决定把整个项目跑在它上面。

这篇文章就来聊聊为什么做出这个选择，以及实际使用中的经验和教训。

方案对比

传统 VPS 方案

架构：

1

用户 → Nginx → Node.js 服务 → 数据库

优点：

成熟稳定，生态丰富
无运行时限制，可以跑长时间任务
完全控制服务器环境

缺点：

需要自己管理服务器（安全补丁、系统更新、证书续期）
需要自己配置负载均衡和扩容
单地域部署，国内访问国外 VPS 延迟高，反之亦然
费用固定，即使没流量也要付月费

Cloudflare Workers 方案

架构：

1

用户 → Cloudflare 全球边缘节点 → Workers → D1/KV/R2

优点：

全球 330+ 边缘节点，就近响应
零运维，不用管服务器
按量付费，没流量不花钱
D1、KV、R2 原生集成，不需要额外配置连接

缺点：

CPU 时间限制（免费版 10ms，付费版 30s）
不支持 WebSocket 长连接
生态相对较新，部分 npm 包不兼容

Cloudflare Workers 的优势

1. 全球边缘部署，零冷启动

Workers 部署在 Cloudflare 的全球边缘网络上，用户请求会被路由到最近的节点处理。我测试过从国内访问部署在 Workers 上的 RuiToolAI，响应时间在 100-200ms 左右，而同样的应用部署在美西 VPS 上，延迟在 300-500ms。

2. 原生集成 D1/KV/R2

这一点非常重要。传统方案里，你需要：

配置数据库连接字符串
处理连接池
管理文件存储（如 S3 SDK）

而在 Workers 里，这些都是原生 binding：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


const { env } = await getCloudflareContext();

// D1 数据库
const db = getDB();

// KV 缓存
await env.NEXT_INC_CACHE_KV.put(key, value);

// R2 文件存储
await env.USER_UPLOADS_BUCKET.put(key, buffer);

3. GitHub Actions 自动化部署

推送代码到 GitHub → 自动 lint → typecheck → e2e 测试 → 构建 → 部署到 Workers → 执行 D1 迁移。整个过程全自动，不需要手动操作服务器。

成本分析

以 RuiToolAI 为例，目前的使用情况：

服务	免费额度	当前用量	费用
Workers	10 万请求/天	~5000/天	免费
D1	5GB 存储 + 500 万读/天	<1%	免费
KV	1GB 存储 + 10 万读/天	~50%	免费
R2	10GB 存储	<1GB	免费

对比传统 VPS：

最低配置 VPS：$5-10/月
Cloudflare Workers：$0/月（当前用量），流量增长后 $5/月起步

踩过的坑

1. CPU 时间限制导致异步任务失败

最开始我用 waitUntil 在后台轮询 AI 生成结果，但 Workers 的 setTimeout 不会真正 sleep，导致轮询瞬间跑完。

解决方案： 改用前端轮询 Server Action。每次轮询是一个独立请求，不受 30 秒限制。

2. D1 不支持事务

SQLite 在 D1 上不支持多语句事务，这在处理积分退款时很麻烦。

解决方案： 补偿式设计。先扣积分，失败时插入退款记录补充余额。

3. 某些 npm 包不兼容

Workers 不支持 Node.js 原生模块（如 fs、net、crypto 的部分 API）。需要用 Web Crypto API 替代，或者找 Workers 兼容的替代包。

总结

场景	推荐方案
SaaS 产品、API 服务、静态网站	Cloudflare Workers
长时间任务（视频处理、模型训练）	传统 VPS
需要 WebSocket 长连接	传统 VPS
低预算、低流量项目	Cloudflare Workers

对于 RuiToolAI 这种 SaaS 产品，Workers 是完美的选择。零运维、按量付费、全球低延迟，让独立开发者可以专注于产品本身。