2026西湖龙井茶官网DTC发售：茶农直供，政府溯源防伪到农户家
本文最初发布于 Jo4 博客。
你删除了该统一资源定位符（URL）。雷迪斯（Redis）显示它已消失。数据库也确认了这一点。但用户点击链接后仍然被重定向到目标地址。cf-cache-status: HIT。云弗莱尔（Cloudflare）正在愉快地提供缓存副本，而没有人通知它忘记该副本。
问题所在
我们在云弗莱尔内容分发网络（CDN）后面运行一个 URL 缩短服务。为了提高性能，我们在边缘节点缓存重定向响应，生存时间（TTL）为 2 小时。这意味着热门的短 URL 可以在全球范围内以低于 50 毫秒的速度解析，且无需访问我们的源站。
当一位客户删除了一个短 URL 并随后点击它以进行验证时，问题浮出水面。链接仍然有效。30 分钟后他们再次尝试。仍然有效。于是他们提交了一张支持工单。
URL 更新的情况也是如此。用户将目标地址从 https://old-site.com 更改为 https://new-site.com。但该短 URL 继续重定向到旧的目标地址。开放图谱（OG）元数据更新也存在同样的问题——由于超文本标记语言（HTML）页面在边缘节点被缓存，社交卡片显示的是过时的标题和图片。
三种不同的变更操作均出现故障：
- 删除 URL — 链接通过 CDN 缓存继续保持活动状态
- 更新 URL — CDN 提供旧的目标地址，雷迪斯（Redis）中保留旧的元数据
- 管理员强制过期 — 雷迪斯（Redis）和 CDN 均未失效
根本原因：分层缓存，部分失效
我们的缓存架构包含两层：
用户请求 → 云弗莱尔 CDN（边缘缓存） → Spring Boot API → 雷迪斯 Redis（应用缓存） → PostgreSQL
当删除 URL 时，服务正确地使雷迪斯（Redis）缓存失效。但它从未通知云弗莱尔（Cloudflare）。CDN 层继续提供过时的响应，直到生存时间（TTL）自然过期。
更新路径的问题更严重。UrlService.updateUrl() 将新的目标地址写入数据库，但未使雷迪斯（Redis）或云弗莱尔（Cloudflare）失效。读取操作首先命中雷迪斯（Redis），获取旧的缓存值，因此从未看到数据库的更新。
管理员操作的问题最严重。AdminService.forceExpireUrl() 和 AdminService.deleteUrl() 直接更新数据库，完全跳过了两个缓存层。管理员代码被编写为直接调用仓库层，绕过了常规用户操作所经过的服务层缓存失效逻辑。
修复方案：每次变更时清除两层缓存
步骤 1：向 CloudflareService 添加 purgeUrls()
云弗莱尔（Cloudflare）暴露了接口 POST /zones/{zone_id}/purge_cache，其请求体为 {"files": [...]}。我们将其封装在一个服务方法中：
@Async
public void purgeUrls(List<String> urls) {
if (!isEnabled() || urls == null || urls.isEmpty()) {
return;
}
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
