千万级数据批处理实战：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 小时前
[Java] 用 GUI 展示 EnumSet 增减元素时的内部变化（上）
java·后端·ai编程
念何架构之路3 小时前
go-grpc设计思想
开发语言·后端·golang
system_error_x3 小时前
SpringBoot 集成 Thymeleaf 简洁入门
java·spring boot·后端
步行cgn5 小时前
Spring MVC 视图机制的核心接口与类
java·开发语言·后端·spring·mvc
码事漫谈6 小时前
AI 读你的提示词，其实很没耐心
后端
用户8356290780516 小时前
如何使用 Python 格式化 Excel 单元格中的长文本
后端·python
我命由我123456 小时前
Python 开发 - Python 的 pathlib
java·开发语言·后端·python·学习·java-ee·学习方法
IT_陈寒6 小时前
Java性能优化完全指南
前端·人工智能·后端
电子IT笔记6 小时前
对接群晖NAS，上传和删除踩坑记录
前端·后端
Mk598787 小时前
P4：把 Agent 的记忆搬进 Redis —— AgentScope-Java 工程化实战
后端
热门推荐
01国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）02如何新建文件夹？ 电脑新建文件夹的4种方法03GitHub 镜像站点04ai安全工具:CyberStrikeAI安装部署与使用05历年考研数学一、数学二、数学三真题试卷及答案PDF06几个好用的ip纯净度检测网站07Windows 10/11 如何退出微软账户并改用本地账户登录（含找不到选项的解决方法）08昇腾910B系列芯片完全指南：四款型号对比、服务器选型与大模型部署实战09苹果iPA游戏软件资源下载网站10乙二醇水溶液物性参数