Magento2中GraphQL Schema缓存失效问题分析与解决方案

问题背景

在Magento 2.4.7-p2版本中，当使用Redis 7.x作为缓存后端时，开发者发现GraphQL Schema无法被正常缓存。这导致每次GraphQL查询都需要重新生成Schema，显著增加了响应时间，在某些情况下查询时间甚至达到7秒以上。

问题现象

开发者通过调试发现，在vendor/magento/framework/Config/Data.php文件的108行处，GraphQL Schema的缓存数据没有被正确存储到Redis中。正常情况下，第二次查询应该直接从缓存读取，但实际上系统仍在重新生成Schema。

技术分析

深入分析后发现，问题的根源在于Magento 2.4.7版本中引入的一个改动。在vendor/magento/module-catalog-graph-ql/etc/di.xml文件中，新增了一个虚拟类型配置：

<virtualType name="Magento\Framework\GraphQl\Config\Data" type="Magento\Framework\Config\Data">
    <arguments>
        <argument name="cacheTags" xsi:type="array">
            <item name="EAV" xsi:type="string">EAV</item>
        </argument>
    </arguments>
</virtualType>

这个配置为GraphQL Schema缓存添加了EAV标签，目的是在属性变更时自动清除相关缓存。然而，在Redis 7.x版本中，当尝试缓存带有标签的数据时，credis客户端库在处理参数时出现问题，导致缓存写入失败。

影响范围

该问题主要影响以下环境配置：

• Magento 2.4.7-p2及以上版本
• Redis 7.x作为缓存后端
• 启用了L2缓存配置（使用外部Redis服务器和本地应用实例缓存）
• 设置了requirepass的Redis认证

值得注意的是，在Redis 6.x版本中此问题不会出现，仅在7.x版本中复现。

解决方案

社区开发者提出了一个修复方案，主要修改了缓存标签的处理逻辑。该方案通过以下方式解决问题：

1. 确保缓存标签参数被正确处理，不会影响主缓存数据的存储
2. 保持原有的EAV标签功能，不影响属性变更时的缓存清除机制
3. 兼容Redis 7.x的参数处理方式

应用此修复后，GraphQL查询性能得到显著提升，从原来的7秒多降至约100毫秒。

实施建议

对于遇到此问题的用户，建议：

1. 检查当前Redis版本是否为7.x
2. 确认是否使用了外部Redis作为缓存后端
3. 评估GraphQL查询性能是否受到影响
4. 考虑应用社区提供的修复方案

总结

Magento 2.4.7版本中引入的GraphQL Schema缓存标签机制与Redis 7.x存在兼容性问题，导致缓存失效。通过分析问题根源并应用适当的修复，可以恢复缓存功能并显著提升GraphQL查询性能。这提醒我们在升级系统组件时需要全面测试缓存机制，特别是当引入新的缓存标签或使用新版缓存后端时。