千万级数据批处理实战：SpringBoot + 分片 + 分布式并行处理方案

三水不滴2026-02-15 9:52

从 "天级" 到 "小时级" 的性能跃升，实现高性能并行处理

引言

在开发中，千万级数据的批量清洗、同步、迁移、统计 是非常常见的场景。传统的单线程或单节点批处理方案不仅耗时长达数天，还存在资源利用率低、容错性差、扩展性弱等问题，严重影响业务迭代效率。本文将深度拆解并实战一套基于 SpringBoot + 批处理分片 + 分布式协调 的高性能并行处理方案，通过将大任务拆解为小分片，充分利用分布式集群资源，实现千万级数据处理从 "天级" 到 "小时级" 的性能跃升，实现高性能并行处理.

一、传统批处理的核心痛点

在面对千万级甚至亿级数据时，传统的单线程或单节点批处理方案暴露出诸多难以逾越的瓶颈：

  • 处理效率低下：单线程串行执行，数据量越大，耗时呈线性增长，千万级数据处理往往需要数天甚至更久，严重影响业务迭代。
  • 资源严重浪费：无法充分利用多核 CPU 和多台服务器的计算能力，大量硬件资源处于闲置状态，造成投资浪费。
  • 容错能力薄弱：任务执行链条长，任何一个环节出错都可能导致整个任务失败，需要从头开始，缺乏断点续传和故障隔离能力。
  • 扩展性先天不足：架构设计固化，无法根据数据量的增长动态增减处理节点，难以应对业务规模的快速扩张。

这些痛点直接导致了批处理任务成为系统的性能瓶颈和运维痛点。因此，我们需要一种更高效、更可靠的批处理架构。

二、批处理分片：解决问题的核心思路

批处理分片的核心思想是 "分而治之"，将一个庞大的任务拆解为多个独立的、可并行执行的小任务（分片），然后将这些分片分配到不同的节点上同时执行。这种模式带来了显著的价值：

  • 性能指数级提升：通过并行执行，将任务的总耗时从 "天级" 缩短至 "小时级" 甚至 "分钟级"，极大提升了数据处理效率。
  • 可靠性大幅增强：单个分片的失败不会影响整个任务的执行，系统可以对失败的分片进行重试或标记，实现故障隔离和断点续传。
  • 水平扩展能力：可以根据数据量和负载情况，动态地增加或减少 Worker 节点，实现计算资源的弹性伸缩。
  • 资源高效利用：充分利用分布式集群的 CPU、内存和网络资源，让每一台服务器都发挥最大价值。

三、核心架构设计：三层分布式批处理模型

本方案采用经典的 "Master-Worker" 三层架构，明确各层职责，确保系统的清晰性和可维护性。

scss 复制代码 
┌─────────────────┐    ┌──────────────────┐    ┌─────────────────┐
│   调度中心      │───▶│   分片协调器      │───▶│   执行节点      │
│   (Master)      │    │   (Redis)         │    │   (Worker)      │
└─────────────────┘    └──────────────────┘    └─────────────────┘
        │                        │                        │
        │ 1. 发起任务，生成分片   │                        │
        │───────────────────────▶│                        │
        │                        │ 2. 存储分片到任务队列   │
        │                        │───────────────────────▶│
        │                        │ 3. Worker主动领取分片   │
        │                        │◀───────────────────────│
        │                        │ 4. 原子更新分片状态     │
        │◀───────────────────────│                        │
        │ 5. 汇总所有分片结果     │                        │
        │                        │                        │
  1. 调度中心 (Master) ：作为任务的大脑，负责接收批处理请求、生成任务元数据、根据分片策略将大任务拆分为多个小分片，并最终汇总所有 Worker 的执行结果，生成最终报告。
  2. 分片协调器 (Redis) ：作为分布式环境下的 "大脑中枢"，负责存储所有任务和分片的状态信息（待处理、处理中、已完成、失败），维护任务队列，实现分片的原子分配和状态更新，确保分布式环境下的数据一致性。
  3. 执行节点 (Worker) ：作为任务的 "手脚"，部署在多台服务器上，主动从 Redis 队列中领取分片任务，独立完成数据的读取、处理和写入，并将执行结果和状态更新回协调器。

四、关键技术实现细节

1. 分片策略：如何合理地 "切蛋糕"

分片策略是整个方案的基石，它决定了数据如何被分配，直接影响负载均衡和处理效率。本方案提供了两种核心策略，并支持自定义扩展：

  • ID 范围分片：

    • 原理：根据数据表的主键 ID（如自增 ID）进行范围划分。例如，将 ID 从 1 到 10,000,000 的数据，划分为 100 个分片，每个分片处理 100,000 条数据。
    • 适用场景：数据 ID 是连续的、有序的，且分布均匀的场景，如用户表、订单表。
    • 优势：实现简单，查询效率高，避免了分页查询时的深度偏移问题。

  • 哈希分片：

    • 原理：对每条数据的唯一标识（如用户 ID）进行哈希运算，然后对总分片数取模，将数据分配到对应的分片。
    • 适用场景：数据 ID 不连续或分布不均，需要保证同一类数据（如同一用户的所有订单）被分配到同一个分片处理的场景。
    • 优势：数据分布均匀，能有效避免热点分片问题。
2. 分布式协调器：基于 Redis 的可靠实现

为了在分布式环境下安全地管理任务和分片，我们选择 Redis 作为协调器，利用其原子操作和数据结构来保证一致性：

  • 任务与分片存储：使用 Hash 结构存储任务和分片的详细信息，如任务 ID、分片 ID、状态、开始时间、处理节点等。
  • 任务队列 ：使用 List 结构作为任务队列，Master 生成分片后LPUSH到队列，Worker 通过BRPOP阻塞式地领取任务，实现了任务的有序分配。
  • 状态原子更新：使用 Lua 脚本将 "检查分片状态为待处理" 和 "更新为处理中" 两个操作合并为一个原子操作，避免了多个 Worker 同时领取同一个分片的竞态条件问题。
lua 复制代码 
-- Lua脚本实现原子性领取分片
local taskKey = KEYS[1]
local status = redis.call('HGET', taskKey, 'status')
if status == 'PENDING' then
    redis.call('HSET', taskKey, 'status', 'PROCESSING')
    redis.call('HSET', taskKey, 'workerId', ARGV[1])
    redis.call('HSET', taskKey, 'startTime', ARGV[2])
    return 'OK'
else
    return 'EXISTS'
end
3. Spring Batch 集成：构建健壮的执行引擎

我们使用 Spring Batch 作为批处理的执行引擎，它提供了开箱即用的事务管理、重试、跳过、监听等机制，让我们可以专注于业务逻辑。

  • 主从 Step 设计：

    • Master Step ：负责整个任务的调度，生成分片，并通过PartitionHandler将分片发送到远程的 Worker 节点。
    • Slave Step ：每个 Worker 节点上执行的具体步骤，包含ItemReader（读取分片数据）、ItemProcessor（处理数据）、ItemWriter（写入结果）三个核心组件。

  • 线程池并行执行 ：通过配置TaskExecutor，在单个 Worker 节点上启用多线程，同时处理多个分片，进一步提升单机的处理能力。

java 复制代码 
@Bean
public Step masterStep() {
    return stepBuilderFactory.get("masterStep")
            .partitioner(slaveStep().getName(), partitioner())
            .step(slaveStep())
            .partitionHandler(partitionHandler())
            .build();
}

@Bean
public Step slaveStep() {
    return stepBuilderFactory.get("slaveStep")
            .<InputData, OutputData>chunk(1000)
            .reader(itemReader())
            .processor(itemProcessor())
            .writer(itemWriter())
            .build();
}
4. 数据读取优化：避免 OOM 的关键

在处理千万级数据时，一次性加载所有数据到内存是不现实的，会直接导致内存溢出（OOM）。因此，我们采用了以下优化策略：

  • 分页加载 ：ItemReader每次只读取一个分片内的一小批数据（如 1000 条），处理完成后再读取下一批，有效控制了内存占用。
  • 避免深度偏移 ：对于 ID 范围分片，使用WHERE id BETWEEN ? AND ?进行查询，而非LIMIT offset, size，后者在 offset 很大时性能会急剧下降。

五、核心源码

1. 任务分片实体（核心）
java 复制代码 
@Data
@NoArgsConstructor
@AllArgsConstructor
public class BatchPartition {
    // 任务ID
    private String taskId;
    // 分片序号 0,1,2...
    private int partitionNo;
    // 分片起始ID
    private Long minId;
    // 分片结束ID
    private Long maxId;
    // 状态：INIT, RUNNING, SUCCESS, FAILED
    private String status;
    // 开始时间
    private Long startTime;
    // 结束时间
    private Long endTime;
}
2. 分片任务管理器（核心：切分任务）
java 复制代码 
@Service
public class BatchPartitionService {

    @Autowired
    private RedisTemplate<String, Object> redisTemplate;

    /**
     * 创建分片：按 ID 范围切分
     */
    public List<BatchPartition> createPartition(String taskId, long totalMinId, long totalMaxId, int partitionSize) {
        List<BatchPartition> list = new ArrayList<>();

        long start = totalMinId;
        int no = 0;

        while (start <= totalMaxId) {
            long end = start + partitionSize - 1;
            if (end > totalMaxId) end = totalMaxId;

            BatchPartition p = new BatchPartition();
            p.setTaskId(taskId);
            p.setPartitionNo(no++);
            p.setMinId(start);
            p.setMaxId(end);
            p.setStatus("INIT");

            list.add(p);
            start = end + 1;
        }

        // 存入Redis
        String key = "batch:partition:" + taskId;
        redisTemplate.opsForList().leftPushAll(key, list.toArray());
        return list;
    }
}
3. 分布式抢占分片（Lua 原子脚本）

重点：保证多机器不抢同一片

java 复制代码 
@Service
public class PartitionTakeService {

    @Autowired
    private RedisTemplate<String, Object> redisTemplate;

    /**
     * 原子抢占一个分片
     */
    public BatchPartition takePartition(String taskId) {
        String script =
                "local key = KEYS[1]\n" +
                "local part = redis.call('RPOP', key)\n" +
                "if part then\n" +
                "   return part\n" +
                "else\n" +
                "   return nil\n" +
                "end";

        RedisScript<BatchPartition> redisScript = new DefaultRedisScript<>();
        redisScript.setScriptText(script);
        redisScript.setResultType(BatchPartition.class);

        String key = "batch:partition:" + taskId;
        return redisTemplate.execute(redisScript, Collections.singletonList(key));
    }
}
4. 批处理执行器（Worker 真正干活）
java 复制代码 
@Service
public class BatchWorkerService {

    @Autowired
    private PartitionTakeService takeService;

    @Autowired
    private UserMapper userMapper;

    /**
     * 启动一个Worker
     */
    @Async
    public void startWorker(String taskId) {
        while (true) {
            // 抢分片
            BatchPartition partition = takeService.takePartition(taskId);
            if (partition == null) break;

            try {
                partition.setStatus("RUNNING");
                partition.setStartTime(System.currentTimeMillis());

                // ======================
                // 业务处理：按ID范围查询
                // ======================
                List<User> list = userMapper.selectByIdRange(
                        partition.getMinId(),
                        partition.getMaxId()
                );

                for (User user : list) {
                    // 你的业务逻辑：清洗、同步、计算、统计
                }

                partition.setStatus("SUCCESS");

            } catch (Exception e) {
                partition.setStatus("FAILED");
            } finally {
                partition.setEndTime(System.currentTimeMillis());
                // 记录结果
                saveResult(partition);
            }
        }
    }

    private void saveResult(BatchPartition partition) {
        String key = "batch:result:" + partition.getTaskId();
        redisTemplate.opsForList().rightPush(key, partition);
    }
}
5. Mapper 按 ID 范围查询（避免分页卡顿）
java 复制代码 
public interface UserMapper extends BaseMapper<User> {
    @Select("select * from user where id between #{minId} and #{maxId}")
    List<User> selectByIdRange(@Param("minId") Long minId, @Param("maxId") Long maxId);
}
6. 任务启动入口（Controller 测试）
java 复制代码 
@RestController
@RequestMapping("/batch")
public class BatchController {

    @Autowired
    private BatchPartitionService partitionService;
    @Autowired
    private BatchWorkerService workerService;

    @GetMapping("/start")
    public String start() {
        String taskId = "task_user_sync_" + System.currentTimeMillis();

        // 切1000条一个分片
        partitionService.createPartition(taskId, 1L, 1000000L, 1000);

        // 启动5个线程并行跑
        for (int i = 0; i < 5; i++) {
            workerService.startWorker(taskId);
        }
        return "任务已启动：" + taskId;
    }
}

六、业务场景落地与最佳实践

1. 典型业务场景
  • 数据迁移：将千万级用户数据从旧系统迁移到新系统，支持实时进度查询和预估剩余时间，确保迁移过程透明可控。
  • 批量数据处理：如每日凌晨的用户行为数据清洗、月度财务报表生成、全量用户画像更新等大规模离线计算任务。
  • 数据同步：将内部系统的数据批量同步到外部合作伙伴的系统，保证数据一致性和及时性。
2. 性能调优与最佳实践

为了让方案在生产环境中发挥最佳性能，我们总结了以下关键实践：

优化维度 建议配置 核心目的
分片大小 每个分片处理 10 万 - 100 万条数据 避免分片过小导致调度开销过大，或过大导致单分片处理时间过长。
线程池大小 核心线程数 20-50，根据 CPU 核心数调整 充分利用多核 CPU，同时避免线程上下文切换带来的开销。
批处理大小 (Chunk Size) 1000-5000 条 / 批 在事务性和吞吐量之间取得平衡，减少事务提交次数。
数据库连接池 最大连接数 50-100 确保有足够的数据库连接支持并发读写，避免连接耗尽。
失败重试策略 最多重试 3 次，间隔递增 对因网络抖动等临时故障导致的失败进行自动恢复，提升任务成功率。
超时监控 每分钟检查一次，超时分片自动重置 防止因 Worker 节点宕机导致分片永久处于 "处理中" 状态，实现自动恢复。

七、监控、告警与可观测性

一个成熟的批处理系统，必须具备完善的可观测性，以便及时发现问题、定位问题。

  1. 核心指标埋点：基于 Micrometer 和 Spring Boot Actuator，对以下核心指标进行埋点：

    • batch_task_total：批处理任务总数
    • batch_task_success：成功完成的任务数
    • batch_task_failed：失败的任务数
    • batch_partition_processing_time：单个分片的处理时间分布
    • batch_records_processed_per_second：每秒处理的数据记录数

  2. 实时进度监控：通过定时任务，每 5 秒从 Redis 中统计所有分片的状态，计算出整体任务的完成百分比和预估剩余时间，并推送到监控大屏或前端页面。

  3. 智能告警：当检测到以下情况时，通过钉钉、企业微信或邮件触发告警：

    • 任务执行时间远超预期阈值。
    • 失败分片数超过一定比例。
    • 处理速度骤降，疑似出现性能瓶颈或死锁。

八、方案预期效果与价值

通过实施这套基于分片和分布式协调的批处理方案，我们可以为业务带来显著的价值提升：

  1. 性能跃升：千万级数据处理时间从传统的数天缩短至数小时，性能提升 10-50 倍，极大加速了业务决策和迭代速度。
  2. 系统稳定可靠：完善的故障隔离、重试和自动恢复机制，将批处理任务的成功率提升至 99.9% 以上，大幅降低了运维成本和人工介入。
  3. 资源高效利用：从 "单节点孤军奋战" 转变为 "集群协同作战"，硬件资源利用率提升数倍，降低了数据中心的 TCO（总拥有成本）。
  4. 业务敏捷响应：强大的水平扩展能力，让系统能够轻松应对业务数据量的爆发式增长，为未来的业务发展提供了坚实的技术底座。

九、总结

千万级数据批处理并非遥不可及的技术难题，其核心在于 "分而治之"的分片思想和"可靠协调" 的分布式架构。本文介绍的基于 SpringBoot、批处理分片和 Redis 协调的方案，通过清晰的三层架构、灵活的分片策略、健壮的执行引擎和完善的监控体系，提供了一套可落地、高性能、高可靠的解决方案。

在实际应用中，可以根据自身业务的数据特点和技术栈，对分片策略、线程池大小、批处理大小等参数进行调优，让这套方案更好地服务于业务需求，真正释放数据的价值。

相关推荐
予枫的编程笔记2 小时前
【Docker进阶篇】Docker Compose实战：Spring Boot与Redis服务名通信全解析
spring boot·redis·docker·docker compose·微服务部署·容器服务发现·容器通信
笨蛋不要掉眼泪2 小时前
从单体到分布式：一次完整的架构演进之旅
分布式·架构
❀͜͡傀儡师2 小时前
Vue+SpringBoot 集成 PageOffice实现在线编辑 Word、Excel 文档
vue.js·spring boot·word
会算数的⑨2 小时前
Spring AI Alibaba 学习（三）：Graph Workflow 深度解析（下篇）
java·人工智能·分布式·后端·学习·spring·saa
认真的薛薛2 小时前
数据库-日志管理、备份恢复与主从同步
数据库·分布式·mysql
用户7344028193422 小时前
java 乐观锁的达成和注意细节
后端
哈库纳2 小时前
dbVisitor 利用 queryForPairs 让键值查询一步到位
java·后端·架构
哈库纳2 小时前
dbVisitor 6.7.0 解读：公元前日期处理的两种方案
后端·算法·架构
野犬寒鸦2 小时前
CompletableFuture 在 项目实战 中 创建异步任务 的核心优势及使用场景
java·服务器·后端·性能优化
热门推荐
01PHP Error: 常见错误及其解决方法02GitHub 镜像站点03Claude Code + GLM4.7 避坑指南：解决 Unable to connect to Anthropic services04UV安装并设置国内源05HTB 赛季10 - Pterodactyl - user06爬虫逆向之观安（观镜WEB应用安全防护系统）07openClaw安装飞书插件｜核心踩坑：spawn EINVAL 错误终极解决指南08243 行 microGPT：把“训练 + 推理”拆到骨头里09Android Studio Panda 1 正式版来了：JDK 终于不用手动配了，内存泄漏也有原生方案了10如何解决 OpenClaw “Pairing required” 报错：两种官方解决方案详解