Java后端缓存失效最佳实践：Setter还是Service实现？

分析你的两个方案 #

先分别拆解你提出的两个方案的优缺点，再给出更符合最佳实践的替代方案。

方案一：新增saveAndInvalidateCache方法

这个方案的核心问题是侵入性极强，违反关注点分离原则：

• 所有修改firstName的业务方法都需要明确调用特殊的保存方法，意味着每个业务逻辑都要知晓缓存失效的规则，完全把缓存细节耦合进了业务代码里。
• 后续新增或修改业务方法时，很容易忘记调用正确的保存方法，导致缓存不一致，维护成本极高——尤其是团队协作时，新人很容易踩坑。
• 本质上是把缓存失效的责任推给了业务代码编写者，这绝对不是最佳实践。

方案二：在setFirstName中标记缓存失效

这个方案解决了业务代码耦合的问题，但引入了新的隐患：

• 违反单一职责原则：setFirstName原本只是负责修改属性值，现在额外承担了缓存失效的标记逻辑，让实体类的职责变得模糊。
• 存在触发漏洞：如果通过非setter的方式修改firstName（比如直接使用反射、JPA的批量更新语句、或者DTO转换时绕过setter），这个标记就不会被触发，导致缓存无法失效。
• 实体类持有mustInvalidateCache标记后，状态管理会变复杂——比如修改firstName又改回去时，标记是否需要重置？这些细节很容易出错。

推荐的最佳实践：领域事件（Domain Event） #

针对你的场景，领域事件是最符合DDD（领域驱动设计）和关注点分离的解决方案，既能避免业务代码耦合，又不污染实体的核心职责。

具体实现步骤如下：

1. 定义领域事件：

public class PersonFirstNameUpdatedEvent {
    private final Person person;

    public PersonFirstNameUpdatedEvent(Person person) {
        this.person = person;
    }

    // getter for person
}

2. 在Person实体中跟踪firstName变化并收集事件：
   我们在实体中添加事件列表，仅当firstName真正发生变化时，生成对应的领域事件：

public class Person {
    private Long id;
    private String firstName;
    private String lastName;
    // 存储领域事件，由Service后续处理
    private final List<Object> domainEvents = new ArrayList<>();

    public void setFirstName(String firstName) {
        // 仅当值真正变化时才添加事件
        if (!Objects.equals(this.firstName, firstName)) {
            this.firstName = firstName;
            this.domainEvents.add(new PersonFirstNameUpdatedEvent(this));
        }
    }

    // 提供事件访问方法，Service处理后清空
    public List<Object> getDomainEvents() {
        return Collections.unmodifiableList(domainEvents);
    }

    public void clearDomainEvents() {
        domainEvents.clear();
    }

    // 其他getter/setter
}

3. 在PersonService中发布领域事件：
   Service在保存实体后，提取并发布事件，交给专门的监听器处理：

public class PersonService {
    private final PersonRepository personRepository;
    private final ApplicationEventPublisher eventPublisher; // Spring事件发布器，或自定义事件总线

    public PersonService(PersonRepository personRepository, ApplicationEventPublisher eventPublisher) {
        this.personRepository = personRepository;
        this.eventPublisher = eventPublisher;
    }

    public Person save(Person person) {
        doSomeValidation(person);
        Person saved = personRepository.save(person);
        
        // 发布所有收集到的领域事件
        person.getDomainEvents().forEach(eventPublisher::publishEvent);
        person.clearDomainEvents();
        
        return saved;
    }

    // 其他业务方法
}

4. 编写事件监听器处理缓存失效：

@Component
public class PersonCacheInvalidationListener {
    private final EverySecondPersonJob everySecondPersonJob;

    public PersonCacheInvalidationListener(EverySecondPersonJob everySecondPersonJob) {
        this.everySecondPersonJob = everySecondPersonJob;
    }

    @EventListener
    public void handlePersonFirstNameUpdated(PersonFirstNameUpdatedEvent event) {
        everySecondPersonJob.invalidateCache();
    }
}

这个方案的核心优势 #

• 完全解耦：业务代码（比如ServiceA的doStuffA/doStuffB）只需要正常调用personService.save()，完全不需要关心缓存失效的逻辑。
• 职责清晰：
  • Person实体只负责管理自身状态和发布领域事件（这属于领域模型的一部分，不违反单一职责）；
  • Service负责保存实体并发布事件；
  • 监听器专门处理缓存失效，后续如果缓存规则变化，只需要修改监听器即可。
• 无触发漏洞：只要是通过实体的setter修改firstName，就会触发事件；如果是通过JPA的更新语句，可以在Repository层额外监听JPA生命周期事件，对比属性变化。
• 可扩展性强：如果后续需要在firstName修改时做其他操作（比如发送通知、更新其他关联数据），只需要新增一个事件监听器即可，无需修改现有代码。

补充：AOP方案（备选） #

如果你不想引入领域事件，也可以用AOP实现：

1. 编写切面拦截PersonService.save()方法；
2. 在切面中查询数据库中该Person的旧数据，对比新旧数据的firstName是否变化；
3. 如果变化了，调用everySecondPersonJob.invalidateCache()。

不过这个方案需要额外的DB查询（查询旧数据），对比逻辑也需要手动实现，不如领域事件直观，但对于简单场景，也是一个可行的备选。

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