Spring Boot+MySQL环境下产品创建后15分钟锁定编辑的最优实现方案

现有两个思路的优劣分析 #

思路1：数据库新增字段校验 #

首先要注意你这里用lastUpdate字段不准确，应该用**创建时间createTime**做校验，这个方案的优缺点如下：

• 优势
  • 数据一致性高：校验规则和业务数据同库存储，不受服务重启、多实例部署影响，不会出现状态不一致的问题，完全符合业务可靠性要求
  • 实现成本极低：JPA实体类新增createTime字段，加@CreatedDate注解即可自动填充，不需要额外维护状态，编辑/删除接口加前置校验逻辑即可，代码量极小
  • 可溯源性强：所有时间数据落地存储，出现业务争议可以直接查库核对，排查问题成本低
• 劣势
  • 每次编辑/删除操作需要多一次单表主键查询，不过这个操作的性能损耗在毫秒级，对绝大多数业务来说完全可以忽略

思路2：内存数组存新创建产品校验 #

这个方案仅在理想单实例场景下可用，缺陷非常明显：

• 劣势
  • 分布式场景完全不可用：多实例部署时，内存数组不共享，会出现同一条产品在A实例允许编辑、B实例禁止编辑的逻辑冲突
  • 状态可靠性差：服务重启、实例宕机都会直接清空内存数组，所有刚创建的产品会被提前放开编辑权限，不符合业务规则
  • 逻辑存在漏洞：每15分钟统一清空数组的逻辑，会导致刚创建1分钟的产品刚好赶上清空周期被提前放行，完全不满足15分钟禁改的要求
  • 资源消耗不可控：短时间大量创建产品会导致数组占用过多内存，严重时会触发OOM
• 优势仅为内存校验速度快，完全抵不过上述缺陷

最优方案推荐 #

首选：优化后的思路1（行业通用最佳实践） #

调整细节如下：

1. 表结构新增createTime datetime(3) NOT NULL字段，JPA实体类对应字段加@CreatedDate、@Column(updatable = false)注解，避免被意外修改
2. 校验逻辑可以通过Spring AOP切面统一拦截编辑/删除的业务方法，或者直接写在JPA的@PreUpdate、@PreRemove实体监听器里，避免每个业务方法重复写校验代码
3. 如果业务QPS极高，担心数据库查询压力，可以加一层缓存做优化：用Caffeine本地缓存或者Redis缓存，把禁改期内的产品ID缓存起来，过期时间设置为对应产品的剩余禁改时长。校验时优先查缓存，缓存中存在则直接拒绝操作，缓存不存在再查库判断，判断为禁改期内的话顺便把ID写入缓存，进一步降低DB查询压力

伪代码示例：

// 编辑前校验逻辑
public boolean checkEditAllowed(Long productId) {
  if (cache.getIfPresent(productId) != null) {
    return false;
  }
  Product product = productRepository.findById(productId).orElseThrow(() -> new RuntimeException("产品不存在"));
  Duration between = Duration.between(product.getCreateTime(), LocalDateTime.now());
  if (between.toMinutes() < 15) {
    // 写入缓存，过期时间为剩余禁改时间
    cache.put(productId, true, 15 - between.toMinutes(), TimeUnit.MINUTES);
    return false;
  }
  return true;
}

备选：仅单实例部署场景可使用优化后的思路2 #

如果你确认服务永远是单实例部署，可以把数组换成带过期时间的Caffeine缓存，给每个新创建的产品ID单独设置15分钟过期时间，替代统一15分钟清空数组的逻辑，解决边界漏洞。服务启动时先从数据库查询最近15分钟创建的产品ID预热到缓存，解决重启丢失状态的问题。但仍不推荐长期使用这个方案，后续如果扩容多实例会有严重的逻辑兼容问题。

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