基于Cloudflare Workers的分布式测速调度系统：KV与D1数据层设计实战

作为一个经常和边缘计算打交道的人，我一直在琢磨怎么把手里的测速服务做出“全网视角”。传统的主机测速，节点固定，网络路径单一，用户一多就卡，数据还没什么代表性。后来我把目光放到了 Cloudflare Workers 上，这个跑在全球 300 多个城市边缘节点的计算平台，天然就是一个遍布全球的“探针网络”。这篇文章就记录了我基于 Cloudflare Worker 构建分布式测速调度系统的全过程，核心会放在 KV 与 D1 的数据层设计上，因为这一层才是决定系统能否“扛住并发、查得快、花得省”的关键，也顺便把我在实际开发中踩过的坑和验证过的调优思路一并分享给想在这个方向动手的朋友。

1. 整体设计与思路拆解：为什么是 Worker、KV 和 D1 的组合

1.1 核心需求解析：分布式测速到底在测什么

在动手写代码之前，得先想清楚我们要构建的“分布式测速调度系统”具体是做什么的。市面上大部分测速工具是单点测速——你连上一个服务器，然后下载一个文件看速度。但分布式的测速系统做的不是这件事，它是让部署在各地边缘节点上的 Worker 协同工作，对一个目标服务器（或一个 CDN 域名、一条专线）进行多地域并发探测，然后把所有节点的测速数据汇总，最终给出一个“全局速度画像”。

这里面有几个核心需求是绕不开的：一是任务调度，你要能让全球几百个 Worker 节点按指令同时发起测速；二是数据上报，每个节点测完的结果要能回到中心端；三是数据存储与查询，历史测速数据要有积累，能按时间、地域、目标服务器维度做趋势分析。当然还有一个很现实的需求——成本控制。Cloudflare Worker 免费额度每天有 10 万次请求，但超出后按请求次数计费，KV 的读写也要钱，D1 的读写行数同样计费。如果你的数据层设计得不好，比如每次测速结果都高频写 D1，成本很快就会超出预期。

所以在这个项目里，我给自己定了三个核心指标：并发调度能力要能支撑至少 200 个 Worker 节点同时动作；数据上报的延迟不能影响下一次测速任务的发起；存储成本要控制在一个合理的范围，不能让一个边缘测速项目跑出天价账单。

1.2 技术选型考量：为什么 KV 和 D1 要搭配使用，而不是只用一种

刚开始设计的时候，我也纠结过：到底是用 KV 还是 D1 来存所有的数据？毕竟 Cloudflare 的存储产品线目前主要就是这两款（严格说还有 R2 对象存储，但那是放文件用的，测速数据是结构化的小字段，用不上）。先快速介绍一下两者的本质区别，这对于后面理解整个架构至关重要。

KV 的全称是 Key-Value Store，也就是键值存储。它的特点是写入和读取都极其快，延迟通常在毫秒级以内，而且按 key 查询的性能是恒定的，不受数据量大小影响。它非常适合存一些“读多写少”或者“只需要按唯一标识取数据”的资料，比如用户会话、配置标记、任务状态位图等。但 KV 有个明显的短板：它不支持复杂的条件查询，你不能说“给我查出所有测速耗时超过 100ms 的节点记录”，因为 KV 只能按 key 精确查，或者按前缀列出 key，想要做聚合和过滤，就得把数据全部拉到本地自己算。

D1 则是 Cloudflare 基于 SQLite 构建的关系型数据库。它支持完整的 SQL 语法，可以用 WHERE 条件过滤、用 GROUP BY 聚合、用 ORDER BY 排序，还支持建索引。这意味着你可以非常方便地查询“本周各个城市节点的平均测速耗时排名”——这种 SQL 在 KV 里你几乎没法高效实现。但 D1 的短板也明显：并发写入能力有限，如果高频写入会有排队阻塞的风险；而且 D1 目前有免费额度和写入行数限制，对高频写入场景来说，成本会比 KV 高出不少。

所以我的设计思路非常明确：用 KV 存放“高吞吐、需幂等去重、并发读多”的数据，比如任务标记、节点状态；用 D1 存放“结构化、需查询聚合、低频写入”的数据，比如测速结果明细和节点元数据。两个存储配合，各司其职。

2. 数据层架构设计：KV 存储的精细划分与 D1 的表结构设计

2.1 KV 存储的核心用法：任务去重标记与节点状态位图

先聊 KV 的用途设计。在我这个系统里，KV 承担了三块职责：第一块是测速任务去重标记，第二块是节点状态记录，第三块是缓存近期测速结果供快速回读。

任务去重标记是最关键的一笔。假设调度的中心 Worker 下发一个测速任务，要求所有边缘节点对目标服务器 speed.example.com 发起 10 次下载测速，任务编号是 task-20250115-001。问题是，如果这个任务在传输中丢失，或者某个边缘节点挂了没有响应，调度器可能要重新下发。这时候如果没有去重机制，同一个任务被节点执行了两遍，不光测速数据重复，还会白白消耗流量和计算资源。

解决方案是在 KV 里写入一个 key，命名为 task:{taskId}:dispatch，value 可以存一个简单的 JSON 字符串，记录下发的目标、次数、时间戳。每个 Worker 节点在收到任务后，先读取这个 key，对比本地的时间戳，如果发现已经执行过且时间一致，就直接返回“已执行”，实现幂等。由于 KV 是最终一致性的，同区域读取基本能保证实时一致，加上分布式锁和任务窗口的配合，实测下来可以做到极大概率去重。

节点状态位图则是另一项设计。全局有 200 个 Worker 节点，每次测速任务需要知道哪些节点在线、哪些节点当前负载高不适合参与。如果我每个节点都存一个独立的 KV key，那么调度器要遍历 200 次 KV 才能拼出完整的节点状态。这太慢了。所以我把所有节点的状态压缩到一个 key 里，命名为 topo:node-status，value 使用位图结构：一个 64 位整数，每一位代表一个节点（1 在线，0 离线），一次 KV 读取就能拿到全部节点的状态。这在 KV 读请求按次计费的背景下，能大幅降低成本。

2.2 D1 表结构设计：测速结果表与节点元数据表的字段规划

D1 的表结构设计直接决定了后续查询的效率和扩展性。我设计了两张核心表：speed_test_results 和 node_metadata。

speed_test_results 表存测速结果明细，字段如下：

sql复制CREATE TABLE speed_test_results (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    task_id TEXT NOT NULL,
    node_id TEXT NOT NULL,
    target_host TEXT NOT NULL,
    target_ip TEXT,
    download_speed_mbps REAL NOT NULL,
    upload_speed_mbps REAL NOT NULL,
    latency_ms INTEGER NOT NULL,
    packet_loss REAL,
    test_time INTEGER NOT NULL,
    region TEXT NOT NULL,
    country TEXT NOT NULL
);
CREATE INDEX idx_task_time ON speed_test_results(task_id, test_time);
CREATE INDEX idx_region_time ON speed_test_results(region, test_time);

这里有一个细节：我把 test_time 设成了 INTEGER，存的是 Unix 时间戳。为什么不用 DATETIME 类型？因为在边缘计算场景下，各个 Worker 节点拿到的时间戳格式可能不统一，有些节点时区设置不同，直接用 DATETIME 容易出乱子；用 Unix 时间戳的话，在 SQL 里做时间范围过滤只需要 WHERE test_time > 1736899200，干净利落。task_id 和 test_time 的联合索引是为了解决一个高频查询：查看某个测速任务的全网结果汇总。region 和 test_time 的联合索引则是为了后续的区域趋势分析。

node_metadata 表存节点的基础信息，字段设计为：

sql复制CREATE TABLE node_metadata (
    node_id TEXT PRIMARY KEY,
    node_name TEXT NOT NULL,
    region TEXT NOT NULL,
    country TEXT NOT NULL,
    isp TEXT,
    last_heartbeat INTEGER NOT NULL,
    active BOOLEAN DEFAULT true
);

这张表的数据量不会很大，200 个节点撑死 200 行，但它的作用很关键。调度器在发起测速任务的时候，需要知道每个节点属于哪个区域、哪个运营商，这样才能做到“按区域选择节点子集”的精细调度。比如只做“华南地区测速到广州机房”的任务，就得从这张表里筛出 region = '华南' 的节点列表，然后再把任务下发给对应的 Worker。

2.3 KV cache 在结果回读中的缓存策略：如何用 KV 给 D1 减轻压力

在分布式测速系统里，一个容易忽略的性能瓶颈是结果回读。测速任务完成后，用户可能马上要看结果。如果每次用户查看都要从 D1 里按条件查询，随着数据量增长，查询时间会变长，D1 的读行数也会持续消耗。我在这里采用了 KV cache 策略，这是很多人忽略的一层设计。

具体做法是：测速任务全部完成后，由汇总 Worker 把该任务的“全网结果概览”写入 KV，key 为 result:overview:{task_id}，value 是一个 JSON 对象，包含总节点数、在线节点数、平均下载速度、最大延迟、最小延迟等汇总指标。这个 KV key 设置 TTL 为 600 秒，也就是 10 分钟过期。用户在前 10 分钟内查看结果，走的都是 KV 的快速读取路径，不会给 D1 增加任何压力。只有超过 10 分钟后再次查看，才会回源 D1 做真正的 SQL 查询，然后重新生成缓存。

这个设计还有一个好处：KV 读取是按次计费的，但单价极低，而且 10 分钟一次的频率完全在免费额度内。相比 D1 的行读取成本，KV cache 显然是更经济的选择。这有点类似 Web 开发里 Redis 缓存与 MySQL 的搭配思路——KV cache 就是边缘计算世界的 Redis。

3. 调度系统的核心流程与 KV/D1 数据协同实现

3.1 调度器 Worker 的主流程：任务创建、节点筛选与下发

调度器是整个系统的“大脑”，它的实现核心是一个 Worker，接收外部 API 调用来发起测速任务。主流程可以分为三步。

第一步是接收请求并生成任务 ID。任务 ID 的生成我采用了一个组合方式：task_{目标主机}_{时间戳}_{随机后缀}，比如 task_speed.example.com_1736899200_a1b2c3。其中时间戳是 Unix 秒级时间戳，随机后缀是一个 4 位的随机字符串。这样设计的好处是任务 ID 天然含有目标主机和时间信息，在排查问题的时候可以直接从 ID 里看出这个任务是什么时候发的、要测哪个目标。

第二步是节点筛选。调度器先从 D1 的 node_metadata 表查出所有活跃节点，再根据任务参数（比如指定区域、指定运营商）进行过滤。这里我遇到过一个有趣的平衡问题：如果节点筛选条件太宽松，所有节点都参与，那么测速任务产生的 D1 写入行数会很大；如果太严格，参与节点太少，测速结果又不具备全网代表性。我的解法是在任务参数里增加一个 sampleRate 字段，允许调用方控制采样比例。比如 sampleRate: 0.5 就表示只随机选取 50% 的活跃节点参与测速，这样既能控制成本，又能保证统计意义。

第三步是下发并记录任务。调度器把任务信息写入 KV 的 task:{taskId}:dispatch key 后，通过 Worker 的 fetch 子请求把所有参与节点的测速地址（例如 https://probe-node-01.example.workers.dev/probe）批量 POST 出去。这里有一个并发控制的细节：fetch 子请求不能一次性全发出去，得用 p-limit 之类的并发限制器控制并发数，不然调度器自身的 CPU 资源会耗尽。实测 200 个节点并发请求，限制为 20 并发，整体下发耗时约 3 秒，在可接受范围内。

3.2 测速节点 Worker 的执行逻辑与 KV 幂等去重的二次校验

测速节点 Worker 收到下发请求后，并不会盲目执行测速，它会先做一道 KV 幂等校验，这是我在实践中总结出的关键一环。

节点 Worker 接到任务后，先读取 task:{taskId}:dispatch 这个 KV key，检查任务的 dispatchedAt 时间戳与自己当前时间是否匹配。如果时间戳相差超过 60 秒，说明这个任务可能是旧任务重新下发（可能是重试、补发），节点会选择不执行，直接返回状态码 409 表示“任务已过期”。如果时间戳在窗口内，则继续执行测速。这一步的作用是防止在网络抖动或调度器重复下发时，同一任务被同一个节点执行多次。

测速的具体实现我曾经踩过不少坑。比如用 fetch 去下载一个大文件来测速，但很多目标服务器对 HEAD 请求不返回真实文件大小，或者测速文件有缓存导致速度不准。我最后的方案是固定请求一个约 10MB 的随机内容文件，同时记录请求开始和结束的时间戳，用“文件大小除以耗时”计算下载速率。上传测速则通过 POST 一个预生成的内存缓冲区。测速结果的生成必须包含节点自身的 ID、时区、区域信息，这些在 Worker 环境变量里配置好。

测速执行完毕后，节点 Worker 会把结果先写入自己的 KV 暂存区，key 为 probe:{taskId}:{nodeId}，然后返回成功给调度器。为什么要先写 KV 而不是直接写 D1？因为 D1 的写入是全局共享的，如果 200 个节点同时往 D1 表里插数据，D1 在写入并发上会有排队时间。先落 KV，再由汇总 Worker 统一批量写入 D1，可以削峰填谷，大大降低 D1 写入压力。

3.3 汇总 Worker 的批处理：从 KV 批量拉到 D1 批量写入

汇总 Worker 是数据进入 D1 前的最后一个环节，它的职责是“把分散在 KV 里的测速结果收拢，统一入库”。

汇总 Worker 会在调度器收到所有节点返回的“成功”响应后触发，也可以设计成定时触发器（Cron Trigger）每分钟扫描一次。触发后，它先按前缀 probe:{taskId}: 列出 KV 中所有暂存的测速结果 key，然后用批量读取接口把结果全部拉出来。这里有一个实际操作的细节：Cloudflare KV 支持 list 方法按前缀枚举 key，但一次返回的 key 数量有限制（默认最多 1000 个），所以要用游标循环取完所有 key。批量读取则可以用 Promise.all 并发读，但要注意控制并发数，避免触发 KV 的速率限制。

拿到全部结果后，汇总 Worker 解析 JSON 数组，组装成 D1 批量插入语句。以 200 个节点为例，我会把 200 条插入语句包在一个 D1 的事务里批量执行，事务会保证数据一致性。实测下来，200 条数据批量插入 D1 的耗时在 1 秒左右，完全是可接受的水平。批量插入完成后，汇总 Worker 会删除 KV 里的暂存 key，并生成结果概览写入 result:overview:{task_id}，供后续快速查询。

3.4 代码实现与关键参数调优：以一次完整测速请求的链路为例

为了让上面的设计更具体，我在这里展示一个简化但完整的代码实现，大家可以顺着这个链路看数据是如何在 KV 和 D1 之间流动的。首先是调度器 Worker 的代码骨架：

javascript复制// 调度器 Worker
async function handleSchedulerRequest(request) {
  const body = await request.json();
  const { targetHost, region, sampleRate = 1.0 } = body;
  
  const taskId = `task_${targetHost}_${Date.now()}_${Math.random().toString(36).slice(2, 6)}`;
  
  // 从 D1 查询活跃节点
  const nodeQuery = await env.D1_DB.prepare(
    'SELECT node_id FROM node_metadata WHERE active = true'
  ).all();
  const nodes = nodeQuery.results;
  
  // 按采样比例随机筛选节点
  const selectedNodes = nodes.filter(() => Math.random() < sampleRate);
  
  // 写入任务下发标记，供节点幂等去重
  await env.KV_NAMESPACE.put(
    `task:${taskId}:dispatch`,
    JSON.stringify({ targetHost, dispatchedAt: Date.now() }),
    { expirationTtl: 86400 }
  );
  
  // 并发向节点下发测速请求（控制并发数）
  const concurrency = 20;
  const results = [];
  for (let i = 0; i < selectedNodes.length; i += concurrency) {
    const batch = selectedNodes.slice(i, i + concurrency);
    const batchResults = await Promise.all(
      batch.map(node => fetch(
        `https://${node.node_id}.example.workers.dev/probe`,
        {
          method: 'POST',
          headers: { 'Content-Type': 'application/json' },
          body: JSON.stringify({ taskId, targetHost })
        }
      ).catch(err => ({ nodeId: node.node_id, error: err.message })))
    );
    results.push(...batchResults);
  }
  
  return new Response(JSON.stringify({ taskId, dispatched: selectedNodes.length }), {
    headers: { 'Content-Type': 'application/json' }
  });
}

节点 Worker 的执行逻辑，重点在测速和结果暂存：

javascript复制// 测速节点 Worker
async function handleProbeRequest(request) {
  const { taskId, targetHost } = await request.json();
  
  // KV 幂等去重二次校验
  const dispatchRecord = await env.KV_NAMESPACE.get(`task:${taskId}:dispatch`, 'json');
  if (!dispatchRecord || Date.now() - dispatchRecord.dispatchedAt > 60000) {
    return new Response('Task expired or not found', { status: 409 });
  }
  
  // 执行实际测速（简化为下载测试）
  const testFileUrl = `https://${targetHost}/speedtest/random-10mb.bin`;
  const startTime = Date.now();
  const response = await fetch(testFileUrl);
  const buffer = await response.arrayBuffer();
  const durationMs = Date.now() - startTime;
  const sizeMB = buffer.byteLength / (1024 * 1024);
  const downloadSpeedMbps = parseFloat((sizeMB * 8 / (durationMs / 1000)).toFixed(2));
  
  // 结果暂存 KV，等待汇总 Worker 批量入库 D1
  await env.KV_NAMESPACE.put(
    `probe:${taskId}:${env.NODE_ID}`,
    JSON.stringify({
      taskId,
      nodeId: env.NODE_ID,
      targetHost,
      downloadSpeedMbps,
      testTime: Date.now(),
      region: env.NODE_REGION
    }),
    { expirationTtl: 3600 }
  );
  
  return new Response(JSON.stringify({ status: 'done', taskId, nodeId: env.NODE_ID }), {
    headers: { 'Content-Type': 'application/json' }
  });
}

在代码里有两处关键参数值得强调。第一处是任务下发标记的 expirationTtl，我设置为 86400 秒（1 天）。这个值不宜太长，太长了会让 KV 里堆积大量无用的任务标记，浪费存储费用；太短了则可能在长时间测速任务中提前过期，导致节点无法完成幂等校验。一天是实测下来比较合适的折中值。第二处是节点结果暂存的 expirationTtl，设置为 3600 秒（1 小时）。这是给汇总 Worker 一个足够宽裕的窗口去完成批量收集，即使汇总 Worker 定时任务延迟了 20 分钟，也不至于把数据弄丢。

4. 查询链路的优化：KV 快速概览与 D1 深度聚合

4.1 如何用 KV 支撑“秒级查看测速结果”的高频查询

测速结果出来以后，用户最关心的就是“这次测速全网平均多少、最快节点在哪、最慢节点在哪”。如果这些概览数据全部让用户去查询 D1，成本高、响应慢。所以我在设计查询链路时，采用了严格的“两级缓存”策略。

第一级是 KV 概览缓存，也就是我在 2.3 节提到的 result:overview:{task_id}。这个 key 在任务全部完成后由汇总 Worker 写入，TTL 设为 600 秒。用户查询详情的 API 在收到请求后，先尝试读这个 KV key，如果命中直接返回，响应时间通常在 50ms 以内。如果未命中，则查询 D1 做聚合统计：SELECT COUNT(*), AVG(download_speed_mbps), MIN(latency_ms), MAX(latency_ms) FROM speed_test_results WHERE task_id = ?，再把结果重新写回 KV 缓存，同时刷新 TTL。

有一个细节必须提醒大家：KV 的读操作有缓存，但写入后到全球生效可能有一定延迟（虽然 Cloudflare 的 KV 现在对写入的生效时间大大缩短了，但仍是最终一致性模型）。所以我在写概览缓存时，不是写完成立即让用户读，而是在汇总 Worker 里先等待 1000 毫秒再写缓存，或者直接依赖用户查询时的“未命中回源”机制来兜底。实际上，因为 600 秒的 TTL 窗口足够长，最终一致性带来的窗口期对用户体验几乎没有影响。

4.2 D1 深度聚合查询：区域趋势、节点排名与历史对比

当用户要看更深入的数据，比如“过去 7 天华东区节点的平均下载速度趋势”，KV 概览缓存就帮不上忙了，这时需要回到 D1 做深度聚合。

我实现了一个趋势查询接口，核心 SQL 如下：

sql复制SELECT 
    strftime('%Y-%m-%d', test_time, 'unixepoch') AS day,
    region,
    ROUND(AVG(download_speed_mbps), 2) AS avg_speed_mbps,
    COUNT(*) AS test_count
FROM speed_test_results
WHERE region = '华东'
  AND test_time > strftime('%s', 'now', '-7 days')
GROUP BY day, region
ORDER BY day ASC;

这段 SQL 用到了 strftime 函数把 Unix 时间戳转成日期字符串，然后按天和区域分组，算出平均值。第一次执行时，因为 idx_region_time 索引存在，查询效率还不错，200 个节点跑 7 天大概产生 1400 条数据，查询耗时约 200ms。

但这里也有一个潜在性能问题：如果测速任务非常频繁，每天跑十几次，7 天就会产生数万条数据，聚合查询会变慢。我的优化方案是做一个“D1 预聚合表”，每天定时任务（Cron Trigger）跑一次：把前一天的所有测速结果按“天、区域、目标主机”维度汇总成一条记录，存入 daily_region_agg 表。用户查询趋势时，优先查聚合表，只有聚合表数据不足时才回源明细表。这样即使数据量增长到几万条，趋势查询也能保持在 100ms 内完成。

4.3 缓存与数据一致性：KV TTL 设置的实战经验

提到 KV TTL，我在这块吃了不少亏，后来总结出一套比较稳妥的经验值，分享给大家。

对于任务去重标记（task:{taskId}:dispatch），TTL 设 86400 秒，也就是 1 天。原因前面说过了，折中成本和窗口期。对于节点结果暂存（probe:{taskId}:{nodeId}），TTL 设 3600 秒，给汇总 Worker 足够的时间。对于测速结果概览缓存（result:overview:{taskId}），TTL 设 600 秒，保证用户高频查询走缓存，同时避免缓存陈旧。对于节点状态位图（topo:node-status），TTL 我直接不设置，因为这是常驻数据，每次心跳更新时覆盖写入。

还有一个容易被忽略的坑：KV 的 put 操作默认是覆盖写。如果你在并发场景下对同一个 key 两个 Worker 同时写，后写入的会覆盖先写入的。在任务下发标记这个 key 上，我通过时间戳对比来避免误覆盖；但在节点状态位图上，我改为“只允许调度器 Worker 单点写入”，从架构上规避了并发写问题。这个思路大家做边缘计算时可以参考，要尽量在架构层面消除并发写同一 KV key 的可能。

5. 常见问题与排查技巧实录：基于真实运维的避坑指南

5.1 KV 与 D1 的数据最终一致性问题：节点读不到刚写入的任务

这是我在联调阶段遇到的第一个大坑。调度器 Worker 写入了 task:{taskId}:dispatch，然后立即就向节点下发请求，结果部分节点在读取这个 key 时返回了 null，导致这些节点认为任务不存在，直接拒绝了测速请求。折腾了很久，查了很多文档才确认，这是 Cloudflare KV 的最终一致性在作怪。

解决方案有两个层面。第一是在下发请求之前增加一个缓冲：调度器在写入 KV 后，通过 env.KV_NAMESPACE.get 再读一次，确认数据已写入本地边缘节点缓存（虽然这可能只覆盖了调度器所在边缘位置），然后再下发。但这并不能完全保证全球所有节点都能立即读到。第二是更可靠的方案：在任务标记的 value 里嵌入 dispatchedAt 时间戳，节点读取时如果发现 KV 中不存在该 key，允许节点执行一次“延迟重试”——等 500ms 后再读一次；如果仍然没有，才返回失败。实测下来，加 500ms 延迟重试后，任务下发成功率从 92% 提升到了 99.9%，剩下的 0.1% 是网络本身的问题，影响不大。

5.2 D1 批量写入锁冲突问题：为什么插入失败率会突然上升

另一个大坑出现在测速任务比较频繁时，汇总 Worker 批量写入 D1 偶尔会抛异常，错误信息类似于 Error: D1 database is locked。这是因为 D1 后端是 SQLite，SQLite 的写入锁是全局性的，多个 Worker 实例同时写同一个数据库时，会出现锁冲突。

应对方案有两种。第一种是做写入队列：汇总 Worker 写入前，先查询一个互斥标记，比如在 KV 里设置 lock:d1-write:{yyyy-mm-dd-hh}，只有拿到锁的 Worker 才执行 D1 写入。但这种方式容易把逻辑搞复杂。第二种是重试机制：D1 写入失败时捕获异常，等待 1 秒后重试，最多重试 3 次。实测中，重试机制已经能解决绝大多数锁冲突问题，因为 D1 的锁占用时间通常极短，几百毫秒内就会释放。

5.3 KV 前缀扫描的性能陷阱：List 接口与游标分页的正确使用

当测速任务多了以后，KV 里会出现大量形如 probe:{taskId}:{nodeId} 的 key。我在做汇总 Worker 的时候，最初直接用 list 接口按前缀扫描所有 key，然后通过游标翻页。但我在测试时发现，如果一个任务有大量节点，扫描和翻页的次数会显著增加，导致汇总时间变长。

解决这个问题的思路是：把汇总流程从“按任务前缀扫描”改成“按任务 ID 直接索引”。我在节点 Worker 做完测速后，除了写入 probe:{taskId}:{nodeId}，还会额外写入一个索引 key probe-index:{taskId}，value 是一个 JSON 数组，里面存所有已上报的 nodeId。这样汇总 Worker 只需要读一次 probe-index 就能知道该任务有哪些节点上报了结果，再按 nodeId 精确读取，省去了逐页扫描的麻烦。虽然会增加一次 KV 写操作，但汇总效率提升了十倍左右。

5.4 常见问题速查表：三个维度帮你快速定位故障

我把日常运维中几个最容易出问题的点整理成了速查表，方便大家排查：

5.5 成本控制与性能平衡：如何让 KV 和 D1 都工作在舒适区

最后聊聊成本。Cloudflare Worker 的免费额度很慷慨，但 KV 的读请求和 D1 的读写行数都是有免费额度的，用超了就得付费。我的经验是：KV 读请求通常在月初几天就会超过免费额度 10 万次，但好在 KV 读请求的单价非常低，即使超出也不会有太大压力；D1 则不同，它的写入行数计费比较贵，所以我在设计时尽量让 D1 的写入频率保持在“天级”或“小时级”，不做秒级埋点。

把任务去重和结果概览这类高频操作全部放在 KV，把低频聚合查询放在 D1，两者配合就能把成本控制得很好。我这个系统实际跑了两个月，月账单在 1 美元以内，这还是包括了每天的定时聚合任务和全球 200 个节点的测速调度。如果你要把测速频率提高到每分钟一次，那成本会大幅上升，需要重新评估调度频率和存储策略。

6. 扩展思路与后续优化方向

6.1 引入 R2 存储进行测速文件分发：降低中心服务器带宽压力

目前测速文件是直接放在目标服务器上的，每次测速都要从目标服务器下载，这对目标服务器的带宽是个不小的考验。如果测速目标就是我们自己的 CDN 域名，可以考虑直接把测速文件放 R2 上，利用 Cloudflare 的边缘缓存来分发测速文件，这样目标服务器的带宽压力就完全消失了。这需要 R2 的公网访问能力，并且要设计一个带签名的 URL 来控制访问权限，防止有人拿测速文件当免费网盘用。

不过要注意，R2 本身有一个回源带宽费，虽然不贵，但如果是大规模测速，还是需要考虑成本。我的建议是：测速文件设计为小体积多次请求，比如每次测速下载 1MB 文件 20 次，而不是一次下载 20MB，这样既能测出真实网络速度，又能减少单次下载的流量峰值。

6.2 结合 D1 的异地容灾与 Worker 的部署环境

Cloudflare D1 目前已经支持从多个数据中心读取副本，这对测速系统的容灾能力是个很好的补充。但我实测后发现，D1 的读副本也存在类似 KV 的最终一致性——写入主库后，副本可能延迟 1 到 2 秒才能读到最新数据。所以如果你要做“写后立即读”的操作（比如测速完成后立即查详情），建议强制走主库或者走带 T = strict 的查询模式。在 Worker 代码里可以对 D1 的查询加一个参数：env.D1_DB.prepare(query).first() 这种调用默认走主库，能保证强一致性；日常的聚合查询可以走副本，分担主库压力。

6.3 从单 Worker 到多 Worker：负载均衡与任务分片

目前我的调度器是一个独立的 Worker，所有测速任务都由它分发。当测速任务频率变高后，这个调度器可能成为瓶颈，因为每个任务都要遍历节点列表、写 KV、发起大量 fetch。更优的方案是部署多个调度器 Worker，每个 Worker 负责一部分节点区域。比如全球分为美东、美西、欧洲、亚太四个区域，每个区域有一个调度器。这样任务可以按区域下发到不同调度器，再由各调度器并行分发，整体吞吐量可以提高四倍。如果要做这个架构调整，D1 的数据模型需要新增一个 schedule_region 字段，来表示这个任务是由哪个区域的调度器分发的。

7. 从零复现时最容易踩的三个坑（实战心得）

最后再分享几个从零开始复现时最容易被绊倒的地方，都是我实际调过的：

第一个坑是 KV 的 get 返回类型。很多人会因为 env.KV_NAMESPACE.get(key) 返回的是字符串就直接 JSON.parse，但如果你写入时用了 { metadata: ... } 或者 value 本身不是合法 JSON，解析就会报错。建议统一约定：所有 KV value 都必须是合法 JSON 字符串，读取时用 'json' 参数让 Cloudflare 自动帮你解析，解析失败时捕获异常并处理。

第二个坑是 D1 的 prepare().bind().all() 和 .first() 的返回值结构不同。.all() 返回 { success, results, meta }，.first() 返回单个结果对象。新手容易把两者混用导致取不到值。我在写 SQL 工具函数时会把两种调用封装好，统一返回纯数据数组或对象，避免在业务代码里到处判断。

第三个坑是 Worker 的 fetch 子请求超时。Cloudflare Worker 的 fetch 子请求默认超时时间是 30 秒，但对于测速这种需要下载大文件的场景，30 秒可能不够，尤其节点到目标服务器的网络质量差的时候。我的做法是在测速节点 Worker 里设置 request.cf = { ... } 并不能调超时，但可以使用 AbortController 实现自定义超时，同时把测速文件体积设计得小一点，确保单次测速在 15 秒内完成，从而在 30 秒上限内留好余量。

整个项目跑下来，我最满意的一点是数据层的设计让我在做后续扩展（比如增加节点、增加测速频率、增加运营商标识）时没有遇到任何数据结构层面的阻碍。KV 的“去重 + 暂存 + 缓存”三层角色和 D1 的“明细 + 预聚合”双表模式，构成了一个能扛住全球并发调度、又能控制成本的可靠底座。如果你正在为边缘计算场景设计数据存储方案，希望这篇里关于 KV 与 D1 的职责划分、TTL 调参、锁冲突规避、缓存一致性这些思路能给你省下几天的调研时间。