问题背景

在使用 Seata 等分布式事务框架时，undo_log 表会存储大量的事务回滚日志，用于在事务失败时进行回滚操作。随着业务量的增长，undo_log 表会不断膨胀，甚至可能达到几十 GB 或上百 GB，导致以下问题：

• 数据库存储空间不足：undo_log 表占用大量磁盘空间，影响数据库性能
• 查询性能下降：表数据量大，导致查询速度变慢
• 备份时间过长：数据库备份时间增加，影响系统维护
• 恢复时间延长：数据库恢复时间变长，增加系统 downtime
• 维护成本增加：手动清理日志的成本高，容易出错

核心概念

undo_log 表

undo_log 表是 Seata 等分布式事务框架用于存储事务回滚日志的表，主要包含以下字段：

• id：主键
• branch_id：分支事务 ID
• xid：全局事务 ID
• context：上下文信息
• rollback_info：回滚信息（二进制数据）
• log_status：日志状态
• log_created：创建时间
• log_modified：修改时间

自动归档策略

自动归档策略是指定期将过期的 undo_log 数据归档到历史表或外部存储，以减少主表的数据量，提高系统性能。

归档目标

• 减少主表数据量：将过期数据移至历史表
• 提高查询性能：减少主表的数据量，提高查询速度
• 降低存储成本：可以将历史数据存储在成本更低的存储介质中
• 方便数据审计：历史数据仍然可查，便于审计和问题排查

技术实现

方案架构

我们将实现一个集成了 undo_log 自动归档和清理功能的 Spring Boot 应用，主要包含以下组件：

• 归档服务：负责将过期的 undo_log 数据归档到历史表
• 清理服务：负责清理已经归档的 undo_log 数据
• 调度器：定期执行归档和清理任务
• 存储服务：管理归档数据的存储
• 监控服务：监控 undo_log 表的大小和归档情况

核心代码实现

1. 归档服务

@Service
public class UndoLogArchiveService {
    @Autowired
    private JdbcTemplate jdbcTemplate;
    
    @Autowired
    private ArchiveConfig archiveConfig;
    
    /**
     * 归档 undo_log 数据
     */
    public void archiveUndoLogs() {
        // 计算归档时间点（默认7天前）
        LocalDateTime archiveTime = LocalDateTime.now().minusDays(archiveConfig.getRetentionDays());
        
        // 创建历史表（如果不存在）
        createArchiveTable();
        
        // 归档数据
        String archiveSql = "INSERT INTO undo_log_archive (branch_id, xid, context, rollback_info, log_status, log_created, log_modified) " +
                "SELECT branch_id, xid, context, rollback_info, log_status, log_created, log_modified " +
                "FROM undo_log WHERE log_created < ?";
        
        int archivedCount = jdbcTemplate.update(archiveSql, archiveTime);
        log.info("Archived {} undo_log records", archivedCount);
        
        // 清理已归档的数据
        if (archivedCount > 0) {
            String deleteSql = "DELETE FROM undo_log WHERE log_created < ?";
            int deletedCount = jdbcTemplate.update(deleteSql, archiveTime);
            log.info("Deleted {} archived undo_log records", deletedCount);
        }
    }
    
    /**
     * 创建归档表
     */
    private void createArchiveTable() {
        String createTableSql = "CREATE TABLE IF NOT EXISTS undo_log_archive (
            id BIGINT(20) NOT NULL AUTO_INCREMENT,
            branch_id BIGINT(20) NOT NULL,
            xid VARCHAR(100) NOT NULL,
            context VARCHAR(128) NOT NULL,
            rollback_info LONGBLOB NOT NULL,
            log_status INT(11) NOT NULL,
            log_created DATETIME NOT NULL,
            log_modified DATETIME NOT NULL,
            archive_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
            PRIMARY KEY (id),
            UNIQUE KEY ux_undo_log_archive (xid, branch_id)
        ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4";
        
        jdbcTemplate.execute(createTableSql);
    }
}

2. 清理服务

@Service
public class UndoLogCleanupService {
    @Autowired
    private JdbcTemplate jdbcTemplate;
    
    @Autowired
    private ArchiveConfig archiveConfig;
    
    /**
     * 清理过期的归档数据
     */
    public void cleanupArchiveData() {
        // 计算清理时间点（默认30天前）
        LocalDateTime cleanupTime = LocalDateTime.now().minusDays(archiveConfig.getArchiveRetentionDays());
        
        // 清理过期的归档数据
        String deleteSql = "DELETE FROM undo_log_archive WHERE archive_time < ?";
        int deletedCount = jdbcTemplate.update(deleteSql, cleanupTime);
        log.info("Cleaned up {} expired archive records", deletedCount);
    }
    
    /**
     * 获取 undo_log 表大小
     */
    public long getUndoLogTableSize() {
        String sql = "SELECT table_name, ROUND((data_length + index_length) / 1024 / 1024, 2) AS size_mb " +
                "FROM information_schema.tables WHERE table_name = 'undo_log' AND table_schema = DATABASE()";
        
        return jdbcTemplate.queryForObject(sql, (rs, rowNum) -> rs.getLong("size_mb"));
    }
    
    /**
     * 获取归档表大小
     */
    public long getArchiveTableSize() {
        String sql = "SELECT table_name, ROUND((data_length + index_length) / 1024 / 1024, 2) AS size_mb " +
                "FROM information_schema.tables WHERE table_name = 'undo_log_archive' AND table_schema = DATABASE()";
        
        try {
            return jdbcTemplate.queryForObject(sql, (rs, rowNum) -> rs.getLong("size_mb"));
        } catch (EmptyResultDataAccessException e) {
            return 0;
        }
    }
}

3. 调度器

@Component
public class UndoLogScheduler {
    @Autowired
    private UndoLogArchiveService archiveService;
    
    @Autowired
    private UndoLogCleanupService cleanupService;
    
    @Autowired
    private AlertService alertService;
    
    /**
     * 每天凌晨执行归档任务
     */
    @Scheduled(cron = "0 0 0 * * ?")
    public void archiveUndoLogs() {
        log.info("Starting undo_log archive task");
        archiveService.archiveUndoLogs();
        log.info("Undo_log archive task completed");
    }
    
    /**
     * 每周日凌晨执行清理任务
     */
    @Scheduled(cron = "0 0 0 ? * SUN")
    public void cleanupArchiveData() {
        log.info("Starting archive cleanup task");
        cleanupService.cleanupArchiveData();
        log.info("Archive cleanup task completed");
    }
    
    /**
     * 每天检查 undo_log 表大小
     */
    @Scheduled(cron = "0 0 12 * * ?")
    public void checkUndoLogSize() {
        long size = cleanupService.getUndoLogTableSize();
        log.info("Current undo_log table size: {} MB", size);
        
        // 如果表大小超过阈值，发送告警
        if (size > 10240) { // 10GB
            alertService.sendUndoLogSizeAlert(size);
        }
    }
}

4. 告警服务

@Service
public class AlertService {
    @Autowired
    private NotificationService notificationService;
    
    @Autowired
    private ArchiveConfig archiveConfig;
    
    /**
     * 发送 undo_log 表大小告警
     */
    public void sendUndoLogSizeAlert(long size) {
        String title = "undo_log 表大小告警";
        String message = String.format("系统检测到 undo_log 表大小超过阈值：当前大小 %d MB，阈值 10240 MB，请及时处理！", size);
        
        // 发送邮件告警
        notificationService.sendEmail(archiveConfig.getAlert().getEmail().getRecipients(), title, message);
        
        // 发送短信告警
        notificationService.sendSms(archiveConfig.getAlert().getSms().getRecipients(), message);
    }
    
    /**
     * 发送归档任务执行结果告警
     */
    public void sendArchiveResultAlert(int archivedCount, int deletedCount) {
        String title = "undo_log 归档任务执行结果";
        String message = String.format("undo_log 归档任务执行完成：归档 %d 条记录，清理 %d 条记录", archivedCount, deletedCount);
        
        notificationService.sendEmail(archiveConfig.getAlert().getEmail().getRecipients(), title, message);
    }
}

技术架构

系统架构图

┌─────────────────────┐
│   业务系统           │
└──────────┬──────────┘
           │
┌──────────▼──────────┐
│   分布式事务框架       │
│                     │
│ ┌─────────────────┐ │
│ │ 事务执行         │ │
│ ├─────────────────┤ │
│ │ 生成 undo_log    │ │
│ └─────────────────┘ │
└──────────┬──────────┘
           │
┌──────────▼──────────┐
│   归档服务           │
│                     │
│ ┌─────────────────┐ │
│ │ 数据归档         │ │
│ ├─────────────────┤ │
│ │ 数据清理         │ │
│ └─────────────────┘ │
└──────────┬──────────┘
           │
┌──────────▼──────────┐     ┌─────────────────────┐
│   存储服务           │────▶│   归档存储           │
└──────────┬──────────┘     └─────────────────────┘
           │
┌──────────▼──────────┐
│   监控服务           │
│                     │
│ ┌─────────────────┐ │
│ │ 表大小监控       │ │
│ ├─────────────────┤ │
│ │ 告警触发         │ │
│ └─────────────────┘ │
└──────────┬──────────┘
           │
┌──────────▼──────────┐
│   通知服务           │
└─────────────────────┘

工作流程图

1. 事务执行：业务系统执行分布式事务，生成 undo_log 记录
2. 数据归档：归档服务定期将过期的 undo_log 数据归档到历史表
3. 数据清理：清理服务定期清理已归档的 undo_log 数据和过期的归档数据
4. 监控检查：监控服务定期检查 undo_log 表大小，触发告警
5. 通知发送：当表大小超过阈值时，发送告警通知

配置说明

核心配置

数据库配置

最佳实践

1. 归档策略最佳实践

• 合理设置保留天数：根据业务需求和审计要求，设置合理的保留天数
• 选择合适的归档时间：在业务低峰期执行归档任务，减少对业务的影响
• 分批处理：对于大量数据，采用分批处理的方式，避免长时间占用数据库连接
• 监控归档效果：定期检查归档效果，确保归档任务正常执行
• 备份归档数据：定期备份归档数据，确保数据安全

2. 性能优化最佳实践

• 索引优化：为 undo_log 表的 log_created 字段创建索引，提高归档查询速度
• 批量操作：使用批量插入和批量删除，减少数据库操作次数
• 事务控制：合理控制事务范围，避免长事务
• 资源隔离：为归档任务分配独立的数据库连接池，避免影响业务操作
• 并行处理：对于大量数据，考虑使用并行处理提高归档速度

3. 可靠性最佳实践

• 异常处理：对归档和清理过程中的异常进行合理处理，确保任务能够正常执行
• 重试机制：实现任务重试机制，提高任务成功率
• 监控告警：监控归档任务的执行状态，及时发现和处理异常
• 数据验证：归档后验证数据完整性，确保数据没有丢失
• 回滚机制：提供归档操作的回滚机制，在出现问题时能够恢复

4. 存储优化最佳实践

• 分区表：对 undo_log 表和归档表使用分区表，提高查询和维护效率
• 压缩存储：对归档数据进行压缩存储，减少存储空间
• 外部存储：考虑将归档数据存储到外部存储（如对象存储），进一步降低存储成本
• 冷热分离：将热数据和冷数据分离，提高系统性能
• 自动伸缩：根据数据量自动调整存储资源，避免资源浪费

问题排查

常见问题及解决方案

排查步骤

1. 查看日志：分析系统日志，找出归档任务执行失败的原因
2. 检查数据库：检查数据库连接状态，查看 undo_log 表数据
3. 验证配置：验证归档配置和告警配置是否正确
4. 分析性能：分析归档任务的执行性能，找出瓶颈
5. 测试功能：测试归档和清理功能是否正常工作
6. 检查存储：检查数据库存储空间使用情况

调试工具

• 数据库查询：使用 SQL 语句查询 undo_log 表和归档表数据
• 日志分析：分析系统日志，找出错误信息
• 性能分析：使用数据库性能分析工具分析归档任务的执行性能
• 监控工具：使用监控工具监控数据库表大小和系统资源使用情况
• 备份恢复：测试归档数据的备份和恢复功能

性能测试

测试环境

• 硬件配置：8核16G服务器
• 软件版本：Spring Boot 2.7.15, MySQL 8.0
• 测试工具：JMeter
• 测试场景：1000并发用户，持续测试10分钟

测试结果

优化效果分析

1. 索引优化：通过为 log_created 字段创建索引，归档速度提升约100%，清理速度提升约100%
2. 批量处理：通过使用批量插入和批量删除，归档速度提升约50%，清理速度提升约50%
3. 并行处理：通过使用并行处理，归档速度提升约33%，清理速度提升约33%
4. 综合优化：通过多种优化手段的组合，归档速度提升约150%，清理速度提升约150%，系统负载明显降低

代码示例

1. 归档配置类

@ConfigurationProperties(prefix = "undo-log")
@Data
public class ArchiveConfig {
    private Archive archive;
    private Alert alert;
    
    @Data
    public static class Archive {
        private boolean enabled = true;
        private int retentionDays = 7;
        private int archiveRetentionDays = 30;
        private String cron = "0 0 0 * * ?";
        private String cleanupCron = "0 0 0 ? * SUN";
    }
    
    @Data
    public static class Alert {
        private boolean enabled = true;
        private int sizeThreshold = 10240;
        private Email email;
        private Sms sms;
        
        @Data
        public static class Email {
            private boolean enabled = true;
            private List<String> recipients;
        }
        
        @Data
        public static class Sms {
            private boolean enabled = true;
            private List<String> recipients;
        }
    }
}

2. 归档任务执行器

@Component
public class ArchiveTaskExecutor {
    @Autowired
    private UndoLogArchiveService archiveService;
    
    @Autowired
    private UndoLogCleanupService cleanupService;
    
    @Autowired
    private AlertService alertService;
    
    /**
     * 执行归档任务
     */
    @Async
    public void executeArchiveTask() {
        try {
            archiveService.archiveUndoLogs();
        } catch (Exception e) {
            log.error("Archive task failed: {}", e.getMessage());
            alertService.sendArchiveResultAlert(0, 0);
        }
    }
    
    /**
     * 执行清理任务
     */
    @Async
    public void executeCleanupTask() {
        try {
            cleanupService.cleanupArchiveData();
        } catch (Exception e) {
            log.error("Cleanup task failed: {}", e.getMessage());
        }
    }
}

3. 监控控制器

@RestController
@RequestMapping("/api/undo-log")
public class UndoLogController {
    @Autowired
    private UndoLogCleanupService cleanupService;
    
    @Autowired
    private UndoLogArchiveService archiveService;
    
    /**
     * 获取 undo_log 表大小
     */
    @GetMapping("/size")
    public Map<String, Object> getUndoLogSize() {
        Map<String, Object> result = new HashMap<>();
        try {
            long size = cleanupService.getUndoLogTableSize();
            long archiveSize = cleanupService.getArchiveTableSize();
            result.put("success", true);
            result.put("undoLogSize", size);
            result.put("archiveSize", archiveSize);
            result.put("message", "获取表大小成功");
        } catch (Exception e) {
            result.put("success", false);
            result.put("message", "获取表大小失败: " + e.getMessage());
        }
        return result;
    }
    
    /**
     * 手动执行归档任务
     */
    @PostMapping("/archive")
    public Map<String, Object> manualArchive() {
        Map<String, Object> result = new HashMap<>();
        try {
            archiveService.archiveUndoLogs();
            result.put("success", true);
            result.put("message", "归档任务执行成功");
        } catch (Exception e) {
            result.put("success", false);
            result.put("message", "归档任务执行失败: " + e.getMessage());
        }
        return result;
    }
    
    /**
     * 手动执行清理任务
     */
    @PostMapping("/cleanup")
    public Map<String, Object> manualCleanup() {
        Map<String, Object> result = new HashMap<>();
        try {
            cleanupService.cleanupArchiveData();
            result.put("success", true);
            result.put("message", "清理任务执行成功");
        } catch (Exception e) {
            result.put("success", false);
            result.put("message", "清理任务执行失败: " + e.getMessage());
        }
        return result;
    }
    
    /**
     * 健康检查
     */
    @GetMapping("/health")
    public Map<String, Object> healthCheck() {
        Map<String, Object> result = new HashMap<>();
        result.put("status", "UP");
        result.put("message", "Undo Log Archive Service is running");
        return result;
    }
}

结论

SpringBoot + 分布式事务日志过大清理方案为解决 undo_log 表暴涨问题提供了一个完整的解决方案。通过自动归档、自动清理、实时监控和智能告警等功能，确保 undo_log 表大小在合理范围内，提高系统性能和可靠性。

该方案不仅可以应用于 Seata 等分布式事务框架，也可以应用于其他需要管理事务日志的场景。随着分布式系统的广泛应用，事务日志管理的重要性将日益凸显，而这个方案将为开发者和运维人员提供有力的支持。

更多技术文章，欢迎关注公众号：服务端技术精选