独立做产品，最怕用户还没几个，免费额度先用完了。 这篇专门算两笔账： - D1 的读取行数 - Queues 的操作次数。 这两个额度最容易在用户不多的时候… · @Sukiea1008 · TwKit

@Sukiea1008

独立做产品，最怕用户还没几个，免费额度先用完了。 这篇专门算两笔账： - D1 的读取行数 - Queues 的操作次数。 这两个额度最容易在用户不多的时候就算错，你上线前值得花五分钟对一遍。 假设你的小工具刚上线，一天也就几百个人用。你心想，D1 每天 500 万行、Queues 每天 1 万次操作，怎么都够了吧？ 资源消耗取决于你的应用怎么工作，和用户多不多、产品赚没赚钱都没有直接关系。 > D1：返回 10 行，可能读了 1 万行 D1 Free： - 每天读 500 万行 - 每天写 10 万行 - 账户总存储 5GB - 最多 10 个数据库，单库上限 500MB 账户总量和单库上限要分开看。 计费按读取的行数算。没有合适的索引，数据库会先扫一大批记录，再从里面筛出你要的那 10 行。 算一笔： 一天只有 1,000 次查询，每次扫 1 万行，合计 1,000 万行，已经超过每天 500 万行。 这时候你该查的是查询条件和索引，用户数量说明不了额度够不够。 > 索引怎么加 围绕你实际在跑的查询建。比如报告工具经常按用户 ID 查报告，就检查这条查询有没有用上索引。 索引也占空间，更新数据时还会增加写入。每个字段都加一个，写入额度反过来会被吃掉。 > 额度用完会怎样 D1 Free 用完当天额度，查询会直接报错，不会自动扩容。 你的应用要能处理这种失败：页面给出清楚的提示，别让用户对着一个空白页。 > D1 第一步 先建库： npx wrangler d1 create my-app-db 然后在 Worker 配置里加绑定，用迁移文件建表，本地测好插入和查询，再应用到远程库。 动线上库之前，确认目标环境、做好备份。没检查过的删除或改表脚本，别直接跑。 > Queues：1 万次操作，装不下 1 万个任务 Queues Free 每天 1 万次操作，消息保留 24 小时。 一条小消息一次处理成功，通常要写入、读取、删除三次操作。操作按每 64KB 分块计量，重试还会增加读取次数。 算一笔： 一天 3,000 条小消息，每条一次成功，约 9,000 次操作，已经接近 1 万。再来一些失败重试或大消息，就超了。 > Queues 最容易踩的坑 同一条消息可能被处理不止一次。 比如你的工具在报告生成后给用户发邮件。邮件已经发出去，后面的确认步骤失败了，队列重试时可能再发一封。换成扣款、创建订单，后果更严重。 怎么防： - 每个任务给一个稳定的任务 ID - 记录哪些业务操作已经完成 - 在真正发信、扣款、创建订单的地方做防重复检查 队列会帮你重新投递，业务到底做没做完，它判断不了。 > 另外两个容易误会的额度 KV Free 每天 10 万次读、1,000 次写。同一个 key 每秒最多写一次，付费计划也一样。你要是拿一个 key 做计数器，每次访问都去写它，很快就会撞上这条限制。 Hyperdrive Free 每天 10 万次查询。这里的 query 包括查询、增删改和部分管理语句，不只指 SELECT。Worker 自身的计算和原数据库的费用还要另算。 > 额度快到顶之前，先做这三件事 1. 配用量监控和预算告警，同时确认它的行为：通知你接近预算，不一定会自动停 2. 公开接口限请求大小和频率 3. 耗时任务限并发、重试次数和执行时间 再准备好出问题时检查和暂停功能的办法。 > 用真实任务和数据来计算预测 别拿用户数直接乘。先跑一次真实操作，记下： - 数据库每次扫描或写入多少行 - 每个任务触发多少后台操作，失败最多重试几次 拿到这两个数，再按你预期的用户量放大，才知道免费额度适不适合现在的功能。

曝光 107 · 评论 0 · 点赞 0 · 书签 0