PCF部署的Spring Boot服务如何调用REST API实现全实例缓存失效

以下是3种可落地的实现方案，你可以根据自身场景选择：

方案1：基于PCF原生路由能力批量调用（推荐，适配你当前1~3实例的场景） #

PCF的Gorouter原生支持指定实例转发请求，不需要修改任何应用代码即可实现：

• 首先调用PCF Cloud Controller API获取应用当前所有运行实例的索引：
  1. 执行cf app <你的应用名称> --guid获取应用的唯一GUID
  2. 执行cf curl /v3/apps/<替换为应用GUID>/processes/web/instances，返回结果中所有状态为RUNNING的条目就是当前存活的实例，提取对应索引值即可
• 遍历所有实例索引，调用缓存失效接口时给请求添加X-CF-APP-INSTANCE请求头，值格式为<应用GUID>:<实例索引>，Gorouter会直接将请求转发到指定实例，不会走默认的负载均衡策略，遍历完成后即可完成所有实例的缓存清理。

优点：零应用代码改造，实现成本极低，完全匹配你当前实例规模小的场景
注意事项：如果调用期间触发实例扩缩容，建议调用前再拉一次实例列表避免漏调，也可以加1~2次重试覆盖异常场景。

方案2：应用内引入发布订阅广播失效事件 #

如果你不想依赖PCF平台特性，可以轻量改造应用逻辑：

• 所有实例接入同一个公共发布订阅组件，比如Redis Pub/Sub、RabbitMQ Fanout交换机
• 调整现有缓存失效接口逻辑：收到清理请求后，不再只清理当前实例缓存，而是先向公共通道广播一条缓存失效事件
• 所有实例都监听该公共通道，收到失效事件后执行本地缓存清理逻辑

优点：无平台绑定，后续迁移部署架构不需要调整逻辑，扩缩容时新启动的实例只要完成订阅就能正常接收失效事件
注意事项：需要保证发布订阅组件的可用性，对一致性要求高的场景可以额外增加缓存版本号校验逻辑，避免消息丢失导致数据不一致。

方案3：替换本地缓存为分布式缓存 #

如果业务允许，直接将现有自定义本地缓存替换为Redis等分布式缓存：

• 所有实例的缓存读写都访问同一个分布式缓存集群，缓存失效只需要清理一次分布式缓存的对应key即可，所有实例自然会拿到最新数据
• 完全不需要处理多实例缓存一致性问题

优点：从根本上解决多实例缓存一致性问题，后续不需要额外维护广播/批量调用逻辑
注意事项：会增加缓存访问的网络开销，需要提前评估对接口性能的影响。

如果你当前没有跨平台部署的需求，优先选择方案1即可，开发成本最低，上线最快。

内容的提问来源于stack exchange，提问作者gechu