PHP Symfony Cache 怎样选择标签失效策略

Symfony Cache 的标签失效，解决的是“一个业务对象被多个缓存键引用”的问题。比如商品详情、分类列表和首页推荐都包含同一商品，商品修改后逐个记住这些键很容易漏删。更稳妥的做法是：单个明确键用 delete()，同一业务对象的关联键用标签，时间敏感的数据再用 TTL 做兜底。

官方地址：https://symfony.com/doc/current/cache.html

本文只讨论 Symfony Cache 组件的标签策略，不把标签当成万能的缓存刷新按钮。读者需要先确定“什么变化会影响哪些缓存”，再决定标签粒度。

先分清直接删除、标签失效和 TTL

如果调用方已经知道唯一缓存键，例如 profile.user.42，直接删除最简单，也最容易定位。标签适合一个对象对应许多键的情况，例如商品 ID 为 42 的详情、搜索结果和推荐卡片都挂上 product.42。TTL 则适合允许短时间旧数据存在，或者无法完整枚举依赖关系的结果。

标签要跟业务对象绑定，不要跟页面绑定

标签最好描述稳定的领域对象，而不是某个控制器或 URL。例如 product.42、category.7、tenant.3 比 homepage 更容易复用。一次读取可以给缓存项挂多个标签，用一个标签表达对象归属，另一个标签表达租户或权限边界。

标签命名还要保持可预测。不要把用户输入直接拼进标签，也不要把一次临时查询条件当成永久标签；否则标签数量会快速膨胀，失效动作也变得难以解释。

配置可失效标签的缓存池

Symfony 可以为池启用标签能力，也可以直接注入 TagAwareCacheInterface。Redis 场景优先考虑专门的 tag-aware adapter；文件系统适合单机或低并发场景。下面的配置让自定义池具备标签接口：

# config/packages/cache.yaml
framework:
    cache:
        pools:
            product_cache:
                # Redis 标签适配器适合多实例共享失效标记
                adapter: cache.adapter.redis_tag_aware
                tags: true

代码中给缓存项打标签，并按业务对象清除关联项：

cache->get('product.summary.' . $productId, function (ItemInterface $item) use ($productId): array {
            $item->tag(['product.' . $productId, 'catalog']);
            $item->expiresAfter(900); // 标签失效之外，再给缓存一个时间上限

            return $this->loadSummary($productId);
        });
    }

    public function invalidateProduct(int $productId): void
    {
        // 商品写入成功后，按稳定标签清理所有关联键
        $this->cache->invalidateTags(['product.' . $productId]);
    }

    private function loadSummary(int $productId): array
    {
        // 真实项目中这里调用仓储；示例只保留缓存边界
        return ['id' => $productId, 'name' => '示例商品'];
    }
}

如果项目已经按类型注入 TagAwareCacheInterface，Symfony 会提供可打标签的应用缓存池；自定义池更适合需要独立命名空间、后端或标签存储的团队。

把失效动作放在写入成功之后

标签失效应当跟领域写操作绑定，而不是散落在读取控制器里。先提交商品或分类的新状态，再清理对应标签，能避免“数据库仍是旧值，却先删了缓存”的短暂反复。若写操作跨越多个服务，建议把失效事件放入可靠的消息或事务后处理机制，并让消费者可以重复执行。

有三个边界值得提前写进团队约定：第一，标签失效不是跨缓存池的自动广播，多个池要明确谁负责；第二，标签名必须包含租户或权限边界，避免误删或串数据；第三，TTL 仍然要保留，作为漏发事件、部署切换或冷数据的最终兜底。

常见问题

已经知道所有键，还需要标签吗？

不一定。键数量少且关系稳定时，delete() 更简单；只有当关联键会持续增加或分散到多个读取场景时，标签才明显降低维护成本。

标签越细越好吗？

不是。标签应表达可复用的业务对象或边界。过细会增加管理成本，过粗又会造成大量无关缓存一起失效，通常从“对象 + 租户”这类稳定组合开始。

Redis 和文件系统该怎么选？

单机、低并发且允许本地缓存时可用文件系统；多实例共享缓存或需要更快传播标签失效时，选择 Redis 相关的 tag-aware adapter 更合适。

小结

Symfony Cache 的标签策略可以归纳为三句话：已知唯一键就直接删除；一个对象关联多个键就用稳定标签；依赖不完整或允许短暂陈旧时用 TTL 兜底。把标签接口、命名边界和写入后的失效动作统一起来，缓存才会从“到处删键”变成可维护的领域约定。