多NoSQL数据库同步调用部分失败的回滚与脏数据清理策略问询

我的服务中创建实体操作需完成三步才视为成功：

1. 向DataBase 1写入元数据（服务可直接访问该库）；
2. 内部调用当前服务的另一API，向DataBase 2（服务可直接访问的graphdb）持久化关联关系；
3. 将DataBase 3中的实体状态标记为ACTIVE。
   三个数据库均为NoSQL数据库，客户端可通过同步或异步方式调用创建实体API。

当前针对部分失败的处理思路：重试耗尽后将原始请求移入DLQ，为DLQ消息数量设置告警通知运维值班人员排查。若根因为底层系统临时问题，运维可将请求重推至源队列重试恢复；否则需调试修正系统并回填数据。

该方案适用于异步流程，但同步调用时需向客户端抛异常由其决定是否重试，现咨询：

1. 是否应在抛异常前实时执行自定义回滚？此类场景如何实现回滚？有无参考方案？
2. 或是否采用离线定时任务（如每日一次）清理部分失败产生的脏数据？

问题1：同步调用时是否应实时自定义回滚？如何实现？ #

• 必须做实时回滚：同步场景下客户端同步等待结果，若不回滚，部分成功的数据会成为脏数据，后续不管是客户端重试还是人工清理，都会增加一致性风险和额外成本。比如仅完成步骤1、2却失败在步骤3，若不回滚，DB1、DB2中的无效数据可能被其他业务逻辑读取，引发连锁错误。
• 回滚实现思路：
  • 记录已完成操作：在每步执行前，把该步骤的回滚逻辑（比如删除DB1元数据、删除DB2关联关系）和上下文信息（如数据ID）暂存到内存或本地临时存储中。
  • 逆序执行回滚：当某一步失败时，从最后成功的步骤开始倒序执行回滚。比如步骤3失败时，先回滚步骤2（调用删除DB2关联关系的内部API），再回滚步骤1（删除DB1中的对应元数据）。
  • 处理回滚失败：若回滚过程中再次出错，需将回滚失败信息和原始请求一起写入DLQ，同时向客户端抛出包含回滚状态的异常，让客户端知晓部分回滚未完成，后续需人工介入。
• 参考伪代码示例：

  // 记录已完成的回滚动作
  List<Runnable> rollbackActions = new ArrayList<>();
  try {
      // 步骤1：写入DB1
      String db1DataId = db1Client.saveMetadata(request);
      rollbackActions.add(() -> db1Client.deleteMetadata(db1DataId));
      
      // 步骤2：写入DB2
      String db2RelId = internalApi.saveRelation(db1DataId);
      rollbackActions.add(() -> internalApi.deleteRelation(db2RelId));
      
      // 步骤3：更新DB3状态
      db3Client.markEntityActive(request.entityId);
      
      return buildSuccessResponse();
  } catch (Exception e) {
      // 逆序执行回滚
      Collections.reverse(rollbackActions);
      for (Runnable action : rollbackActions) {
          try {
              action.run();
          } catch (Exception re) {
              log.error("回滚操作失败，数据ID: {}", re.getMessage(), re);
          }
      }
      // 抛异常给客户端，告知创建失败且已尝试回滚
      throw new EntityCreateFailException("创建实体失败，已执行回滚操作", e);
  }
  

问题2：是否采用离线定时任务清理脏数据？ #

• 可作为补充方案，但不能替代实时回滚：定时任务适合处理实时回滚失败、或因系统崩溃、网络中断等极端情况未触发回滚的脏数据，但不能作为同步调用的核心异常处理手段——脏数据长时间存在会影响业务逻辑的正确性。
• 定时任务实现要点：
  • 明确脏数据判定规则：比如DB1存在元数据，但DB3对应实体状态非ACTIVE且创建时间超过1小时；或DB2存在关联关系，但DB1无对应元数据。
  • 清理前加分布式锁：避免多个任务实例同时清理同一条数据，引发重复操作或数据不一致。
  • 记录清理日志：每条被清理的数据都要记录操作时间、数据内容、清理原因，方便后续排查和审计。
  • 调整执行频率：无需每日一次，可根据业务场景设置为每2-4小时执行一次，减少脏数据的留存时间。

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