配方
我们的索引每月更新一次，因此大多数查询可由内存服务。这是一种缓存方案，既能节省积分，又不会向用户展示过时的错误数据。
规则
由于数据大约每月变化一次，按小时设置 TTL 除了增加成本外并无益处。按月范围的密钥在整个月内提供相同的答案，并在更新时一次性失效。
刚接触链接数据的团队往往会复制排名追踪器的习惯。习惯一：按小时缓存，因为排名会变动。但链接图谱几乎不会变动。
一次 backlinks 调用需 2 个积分，成本为 $0.0002。这听起来微不足道，但如果一个列表视图在每次页面加载时触发 50 次调用，且涉及 400 个活跃工作区，并且每小时重复以获取相同答案，成本就会累积。
下面的计算示例仅供参考，并非对任何实际流量的测量。假设 400 个工作区，每个工作区每天查看 20 个域名，每次查看消耗 2 个积分，且 1 小时缓存的命中率约为五分之一。大多数查看请求仍会命中 API。如果使用按月密钥，相同的流量每月每个域名仅会命中一次 API，这就是该配方的核心价值所在。
关键词研究工具需要更新的数据，对于这些场景，大型套件仍是更好的选择。但对于链接上下文，月度数据已足够作为产品标准。
| 操作 | 积分 | 建议 TTL | 原因 |
|---|---|---|---|
| 概览、统计 | 0 | 至月底 | 免费，但你的服务器仍能节省延迟 |
| bulk_dr | 1 | 至月底 | 一次性调用获取整个客户表 |
| refdomains, backlinks | 2 | 至月底，按 page 参数 | 将 page、per、sort 包含在密钥中 |
| anchors, toppages | 2 | 至月底 | 在刷新之间保持稳定 |
| search, keyword | 3 | 7 天 | 很少重复，跳过缓存成本更低 |
每个客户调用一次 bulk_dr，而非每行调用一次。最多 2,000 个域名可包含在一个 POST 请求体中，成本为一个积分。
curl -X POST "https://alfalinks.net/api.php?action=bulk_dr&key=sk_live_..." \
-d "domains=stripe.com,notion.so,linear.app,figma.com,vercel.com"
# billed once, whatever the row count每个步骤各司其职。跳过任何一步，故障稍后才会显现，通常表现为账单激增。
使用操作、域名、分页和排序参数以及索引月份。排除用户可更改但不影响答案的任何内容，例如显示颜色或标签页名称。
保留解码后的 JSON 及其 ok 标志和数据，而非原始字节。这样后续视图可以从内存中重建整个表，无需进行第二次调用。
将过期时间设置为当月月底，加上上述规则中的宽限期。对每个操作使用相同的规则，这样逻辑只存在于一个函数中，而不是分散在五个地方。
在每个经过身份验证的响应中读取 _credits 对象，并将剩余余额写入您自己的日志。该行数据的缓慢下降通常是缓存键错误的第一个迹象。
跟踪视图从缓存中服务的频率。低命中率意味着键过于具体，或者用户每次访问都打开一个新域名。无论哪种情况，在规划预算时都很有用。
链接数据可能是一个月前的，但对于其来源的索引来说仍然是正确的。您的屏幕是否显示这一点才是真正的问题。大多数关于旧数据的工单都是标签问题。标签通常可以解决这些问题。
为每个数据标注其索引月份。向用户展示它。一旦他们能看到日期，这个数字看起来就不会像损坏的 feed，而这短短一行文字的作用比缩短 TTL 要大得多。
我们的索引大约每月刷新一次，因此第一天缓存的数据与最后一天缓存的数据描述的是同一个索引。一个月内答案不会发生变化。当用户期望看到昨天的链接时，问题就出现了，此时的修复方法是清晰的标签，如 评分标签 中所述。
概览操作不消耗积分，因此这里的缓存保护的是速度而非余额。您的服务器仍会为每次往返付费，如果一分钟内打开五十次页面，服务器会感受到压力。也存储免费答案，使用相同的月份键，这样页面保持快速，同时代理保持安静。公开查询说明 对访问者解释了相同的理念。
通常不需要。绕过缓存会消耗积分，但得到的答案可能与缓存中的相同。如果客户坚持，请解释索引月份，并提供每个工作区每月一次的手动刷新，而不是一个任何人都可以循环按下的开放按钮。
_credits.remaining 并在低于您设定的阈值时发出警报。
需要大规模检查页面反向链接的团队通常从直接查询搜索引擎的脚本开始。这些脚本会停滞。它们在第一天看起来很便宜，这就是为什么团队保留它们的时间比应有的时间长得多。在稳定的 API 前面加一个缓存通常是更便宜的设计，需要照看的移动部件更少。
差异体现在工程工时上，而不是第一张发票上。保持缓存的简单性，大多数这些工时就不会发生。
搜索引擎会限制自动查询，因此一个在五十个 URL 上运行良好的脚本在五十万个 URL 时可能会停滞。重试、代理池和随机延迟都会增加成本，这些成本不会出现在积分行中，并且当目标更改响应时，它们会毫无预警地失效。
在任务进行中，将每个完成的域名写入缓存。如果任务中途停止，重启时会跳过所有已有存储答案的域名，并从停止的地方继续。不会为同一个月重复收费，因为键已经包含了答案。
以稳定的速度运行任务，而不是一次性爆发。间隔调用可使日志易读，并使信用使用量的变化易于解释。
假设您需要为一个客户端检查 22,000 个链接 URL。其中许多共享一个域名，因此首先去重到域名。这 22,000 个链接可能会减少到几千个唯一域名，一次 bulk_dr 调用最多可以处理 2,000 个，仅消耗一个积分。按域名和月份存储每个结果，该列表就不再是逐个 URL 的任务。在任务旁边保留简短的算术说明，以便下一个人可以用不同的列表大小重新运行。带有计算过程的数字比单独的总数更容易让人信任。
缓存是 计数器设置 中的中间层。一旦它正常工作，每个用户的成本变得可预测，您可以使用 每用户比较 围绕它制定计划。简短的页面需要一个清晰的结尾。这个页面做到了。
短暂的浏览器缓存有助于后退按钮导航，但服务器上的共享缓存才是真正节省成本的地方。将客户端存储限制在几分钟内，因为否则不同机器上的用户在同一天对同一域名会看到不同的数字。
检查 UI 中显示的索引月份。如果链接是在上次刷新后添加的，它将在下次刷新后出现。提供说明，而不是退款，因为没有任何东西损坏。
可以，但每次绕过都会消耗积分，得到的答案可能相同。仅向管理员提供，并对每个工作区进行速率限制，以避免意外循环。
分页曾让每个人吃过一次亏。将其包含在键中。
backlinks 和 refdomains 操作每次调用最多返回 1,000 行，page 和 per 在 10 到 5000 之间，深度分页上限为 50,000 行，因此缺少这些参数的键将为每次请求提供第一页。
排序也应包含在键中。从 DR 降序切换到字母顺序的用户期望看到不同的列表，缓存必须在已存储完整集的情况下提供不同结果，而无需新的上游调用。
一个简单的测试可以捕获大多数键错误。请求第二页，更改排序，然后检查缓存的第二页是否与缓存的第一页不同。如果相同，则键缺少参数。早期发现只需几分钟。客户永远不会看到它。在每次发布前再次运行测试，因为新的排序选项通常是键失效的原因。将其写入发布检查清单。
单独规划导出按钮：一个后台作业，一个存储的文件，以及一个就绪通知。
