Cloudflare Workers Cache：处理器休息，请求照样计费

摘要

启用 Workers Cache 后，对该 Worker 的请求按标准请求费率计费，包含原本免费的静态文件请求。缓存命中可以省掉代码执行和 CPU 费用，却没有省掉请求计数。
官方计算密集型示例因缓存省下 11.20 美元；将缓存规则用于官方另一份静态流量示例，在月度额度完整可用的条件下，费用反而增加 1.50 美元。

处理器终于可以歇一歇，计价器却招来了新客人。

Cloudflare 的 Workers Cache 会在运行代码之前查找缓存。找到响应，直接交付，Worker 无须执行。这是很实在的工程收益。它同时还有一条很实在的价格规则：启用这项功能后，对该 Worker 的每个请求都按标准请求费率计费，包括通常免费的静态文件请求。

“没有单独定价”听起来像一道简单的省钱题。Cloudflare 的文档确实这样描述这项功能，也明确列出了扩大的收费范围。缓存没有另开一张价目表；它把更多流量带进了原有的那一张。

先看基础账本。Workers Paid Standard 每个账户每月最低 5 美元，包含 1,000 万次请求与 3,000 万毫秒 CPU。超额部分，每百万次请求 0.30 美元，每百万毫秒 CPU 0.02 美元。额度属于账户，每加一个 Worker 不会重新领一份。

Cloudflare 的官方示例 2 有每月 1,500 万次请求，其中 1,200 万次服务静态文件，300 万次执行动态代码。每次动态执行平均用 7 毫秒 CPU，总计 2,100 万毫秒。静态请求免费，动态请求和 CPU 都在包含额度内，月费合计 5 美元。

现在保留同一份流量，只把该 Worker 整体置于 Workers Cache 的启用范围内。这个推算假设使用一个 Standard 付费账户、月度额度完整可用，没有其他用量、产品或税费折扣调整。1,500 万次请求都进入收费计数，超过额度的 500 万次产生 1.50 美元请求费。

CPU 怎么办？哪怕动态请求一次缓存也没命中，2,100 万毫秒仍低于 3,000 万毫秒额度。CPU 超额费原来是零，现在还是零。动态命中继续减少执行量，也无法把这一项从零再往下减。合计因此成为 6.50 美元。

这是把两份官方文档中的规则用于同一组流量的条件推算。Cloudflare 没有把它列作真实客户账单，也没有在示例 2 直接印出这个缓存后结果。它说明的事情很具体：原来已经免费的计算，被优化后腾出的余地，未必抵得上新进入收费范围的请求。

官方还有一个对缓存很友好的场景。每月 1 亿次请求，每次平均消耗 7 毫秒 CPU。基础费 5 美元，请求超额费 27 美元，CPU 超额费 13.40 美元，总计 45.40 美元。

在对应的缓存示例中，命中率达到 80%，只剩 2,000 万次请求执行代码。CPU 用量降至 1.4 亿毫秒，超额费降至 2.20 美元。请求费仍为 27 美元，最后的总账是 34.20 美元。

省下的 11.20 美元是真的，但总账只下降约四分之一。80% 的缓存命中率，省掉的是大量执行，账单上还有交付请求这门生意。CPU 额度又会影响 CPU 用量与 CPU 费用之间的比例，不能把命中率直接当成节费率。

两个例子放在一起，购买决定才有了着落。高计算量的动态响应，原本就在付 CPU 超额费，缓存省下的资源有机会直接变成钱。静态文件占大头、动态执行尚在额度内的服务，首先碰到的则可能是请求收费范围扩大。

这项规则针对的是启用 Workers Cache 的 Worker。它既有别于在代码内部使用的旧 Cache API，也有别于普通网站的区域 CDN 缓存。文档说明它不依赖网站区域；区域层的 Cache Rules 或 Page Rules 不负责配置它。

它还会让该 Worker 收到的某些 Worker 间调用进入标准请求计费，而普通 Standard 服务绑定调用通常没有额外请求费。把程序拆成多个部件时，具体在哪个 Worker 启用功能，也就成为成本设计的一部分。没有实际调用路径与配置，无法凭部件个数算出一张链式调用账单。

分层缓存、相同请求合并，都可以减少重复执行。送到使用者手里的请求仍然是请求。后台干活次数和前台交付次数，在合同里各有名字。

实际账单还缺各类流量、CPU 用量、账户额度被其他任务占用的情况，以及适用合同。把这些数补齐，就能判断哪种效果占上风。

Cloudflare 卖的价值包含交付响应，成本也包含计算之外的服务。买家当然可以为这种交付付钱。但预算会上那句“命中率提高了”，必须再接一句：“哪些请求从今天开始要钱？”处理器休息得很好，采购不能跟着打盹。