分布式缓存场景下跨微服务拆分@CachePut与@Cacheable是否属于反模式

问题结论 #

跨微服务拆分@CachePut和@Cacheable确实属于反模式，你预判的问题完全成立。

反模式的核心问题 #

• 强隐性耦合：两个服务必须严格对齐缓存键生成规则、值序列化/反序列化逻辑、缓存命名空间配置，任意一边的修改没有同步都会导致缓存失效、数据不一致，这类问题排查成本极高，因为不会直接抛出报错，只会出现隐性的业务逻辑异常。
• 领域边界混乱：用户通知配置的所有权归UI侧的配置管理域，跨服务直接写入缓存等于绕过了配置域的权限控制和逻辑校验，后续如果配置新增校验规则，很容易出现脏数据写入缓存。
• 运维复杂度提升：缓存集群的权限、扩容、配置调整都需要同时同步两个服务的配置，不符合微服务独立运维的原则。

Kafka方案的正确打开方式 #

你提到的无意义空方法是对Kafka事件驱动方案的误用，正确的实现完全不需要这类冗余代码，整体流程如下：

1. 明确配置的唯一可信源是UI服务对应的持久化存储，缓存仅作为采集/会话服务的本地加速层，所有权完全归属采集服务。
2. 采集侧仅保留@Cacheable逻辑：首次查询配置时调用UI服务开放的标准拉取接口，获取配置后写入本地分布式缓存，缓存键的生成规则、过期策略完全由采集服务自己管理，和UI服务无任何耦合。

@Cacheable(value = "config", key = "new SimpleKey(#userId, #applicationId)")
public UserApplicationConfig getConfig(Long userId, Long applicationId) {
    // 调用UI服务的配置查询接口获取最新配置
    return uiConfigClient.getConfig(userId, applicationId);
}

3. UI侧用户更新配置完成后，仅需要向Kafka发送一个配置更新事件，事件仅需要携带userId、applicationId、更新时间戳三个核心字段，不需要传递完整配置对象，也不需要任何缓存相关的逻辑。
4. 采集服务监听该Kafka主题，收到更新事件后，直接删除对应缓存键即可：

@KafkaListener(topics = "config-update")
public void handleConfigUpdate(ConfigUpdateEvent event) {
    SimpleKey cacheKey = new SimpleKey(event.getUserId(), event.getApplicationId());
    cacheManager.getCache("config").evict(cacheKey);
    // 也可以选择主动拉取最新配置写入缓存，实现更强的实时性
}

方案优势 #

这个实现方案同时解决了你提到的两个痛点：

• 没有跨服务的缓存逻辑耦合，两个服务的缓存、配置逻辑完全独立迭代，不会出现键不同步的问题。
• 代码逻辑清晰可维护，不存在无意义的空方法，所有代码都对应实际业务语义。

如果你的业务规模不大，也可以选择更简单的折中方案：UI服务更新配置后直接调用采集服务暴露的缓存刷新接口，不需要引入Kafka，但这个方案在采集服务多实例扩缩容时会有调用漏发的问题，不如Kafka方案稳定。

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