Serverless Framework 如何为 AppSync 启用服务端缓存并用 flush-cache 命令清除缓存？

Serverless Framework 如何为 AppSync 启用服务端缓存并用 flush-cache 命令清除缓存？

【免费下载链接】serverless⚡ Serverless Framework – Effortlessly build apps that auto-scale, incur zero costs when idle, and require minimal maintenance using AWS Lambda and other managed cloud services.项目地址: https://gitcode.com/GitHub_Trending/se/serverless

如果你的 AppSync GraphQL API 存在重复请求打满数据源、或数据更新后仍返回旧结果的问题，可以在 Serverless Framework 中通过appSync.caching配置启用 AppSync 的服务端数据缓存，之后再用sls appsync flush-cache命令随时手动清空缓存。AppSync 集成已内置于 Framework，无需安装任何插件，原有的appSync配置会被直接沿用。本文适用于provider.name为aws、serverless.yml中已定义appSync块的服务；前提是该服务已能正常部署。

启用服务端缓存：配置appSync.caching

在服务目录的serverless.yml中，appSync块下添加caching子配置即可开启缓存。文档给出的最小配置如下：

appSync: name: my-api caching: behavior: 'PER_RESOLVER_CACHING' type: 'SMALL' ttl: 3600 atRestEncryption: false transitEncryption: false

各属性的含义与默认值（来源：caching.md）：

• behavior：缓存行为，只能取FULL_REQUEST_CACHING（按整个请求缓存）或PER_RESOLVER_CACHING（按 resolver 缓存）；
• type：Redis 实例规格，可选SMALL、MEDIUM、LARGE、XLARGE、LARGE_2X、LARGE_4X、LARGE_8X、LARGE_12X，默认SMALL；
• ttl：缓存默认有效期（秒），默认3600，最大3600；
• enabled：布尔值，是否启用缓存；只要存在caching定义，默认即为true；
• atRestEncryption/transitEncryption：布尔值，分别控制静态加密与传输加密，默认均为false。

也就是说，caching块一旦出现缓存就默认开启；如需关闭，显式写enabled: false。

可选分支：按 resolver 细化缓存

全局behavior设为PER_RESOLVER_CACHING时，可以在单个 resolver 上进一步自定义 TTL 和缓存键（来源：resolvers.md 的 Caching 一节）：

appSync: resolvers: Query.user: dataSource: myDataSource caching: ttl: 60 keys: - '$context.arguments.id'

• 直接写caching: true表示使用全局ttl、不指定keys；
• 写成对象时可覆盖该 resolver 的ttl（秒）并提供keys数组作为缓存键。

这只影响单个 resolver 的缓存策略，与后文整库清除缓存的flush-cache命令互不冲突。

部署使配置生效

缓存配置随 CloudFormation 栈下发，修改appSync.caching后需要部署服务使配置生效：

sls deploy

部署成功后，API 的 Redis 缓存实例才会按type、ttl、加密等配置创建或更新。

用 flush-cache 命令清除缓存

当源数据发生变化、希望立即丢弃已缓存的结果时，在服务目录下执行（来源：commands.md）：

sls appsync flush-cache

该命令的用途是"当你的 API 使用服务端缓存时，清空该 API 的缓存"。从实现看（appsync/index.js），它会先从已部署的栈中读取 AppSync API ID，再调用 AWS AppSync 的flushApiCache接口，成功后在终端输出：

Cache flushed successfully

因此这条命令有两个明确前提：

1. 服务已通过sls deploy部署过，栈中存在可解析的 API ID；
2. API 启用了服务端缓存（即存在appSync.caching配置），未启用缓存的 API 不存在可清除的缓存。

验证与后续排查

• 成功判定：命令返回Cache flushed successfully即表示flushApiCache调用成功；
• 控制台核对：如果需要在 AWS 控制台查看该 API 的缓存状态，可运行sls appsync console，它会打开一个新浏览器标签页跳转到该 API 的 AppSync 控制台页面；
• 辅助命令：排查缓存行为时，sls appsync logs（支持--filter、--startTime、--tail等选项）可以查看该 API 的日志；sls appsync get-introspection可导出 schema 用于确认 resolver 结构。

限制与注意事项

• ttl上限就是3600秒，不能配置更长的全局缓存有效期；需要更短的生命周期时，用 resolver 级别的caching.ttl覆盖；
• type只能从文档列出的八种规格中选取，写其他值没有依据；
• flush-cache作用于整条 API 的缓存，没有按 resolver 或按字段部分清除的选项；
• 缓存的加密（atRestEncryption、transitEncryption）默认关闭，如果合规要求传输或存储加密，需要在caching块中显式置为true后再部署。

更多 AppSync 配置项（认证、API Keys、数据源、自定义域名等）见 AppSync 文档目录。

【免费下载链接】serverless⚡ Serverless Framework – Effortlessly build apps that auto-scale, incur zero costs when idle, and require minimal maintenance using AWS Lambda and other managed cloud services.项目地址: https://gitcode.com/GitHub_Trending/se/serverless