12306数据库下载实战：2026最新避坑指南

版本升级后 API 全变了，是不是让你瞬间头大？别慌，这在 2026 最新的后端开发环境里太常见了。很多转岗过来的朋友，一看到 12306 数据库下载这种高并发、高可用的场景，心里就发虚。

其实，核心逻辑没变，变的是封装方式和性能优化策略。今天我们就从零搭建一个模拟 12306 数据库下载的系统，不整虚的，直接上代码。你会看到，如何在保证数据一致性的同时，把下载速度拉满。

项目目标

我们要实现的不是真的去爬 12306，而是模拟其核心数据下载机制。目标很明确：

高并发处理：模拟百万级查询请求下的数据库读取。
数据一致性：确保在分页下载时，数据不重、不漏。
断点续传：模拟网络波动时的恢复机制。
资源隔离：防止下载任务拖垮主业务库。

很多新手在这里容易踩坑，以为“下载”就是 SELECT * FROM table。错！在 12306 这种场景下，直接全表扫描会把数据库拖死。我们需要的是流式读取和分批加载。

这里有个关键概念：游标（Cursor）。在 MDN Web Docs 中，虽然主要讲 Web API，但其关于数据流处理的哲学同样适用于后端。我们要做的，就是控制数据流，而不是让数据洪峰淹没内存。

目录结构

项目结构要清晰，方便后续扩展。我们采用分层架构：

project_root/
├── src/
│   ├── main/
│   │   ├── java/
│   │   │   └── com/example/
│   │   │       ├── controller/  # 接口层
│   │   │       ├── service/     # 业务逻辑层
│   │   │       ├── repository/  # 数据访问层
│   │   │       └── config/      # 配置类
│   │   └── resources/
│   │       └── application.yml
│   └── test/
├── pom.xml
└── README.md

重点说明：

Repository 层：不要直接写 SQL，使用 MyBatis 或 JPA，但要特别注意 fetchSize 的配置。
Service 层：核心逻辑在这里，包括分页策略、异常重试。
Config 层：线程池配置、数据源连接池配置。很多性能问题，根源就在连接池配置不当。

核心代码实现

1. 数据源配置与游标优化

很多开发者默认使用 JDBC 默认的 fetchSize（通常是 10 或 100），这在大数据量下载时是灾难。我们需要调整它。

@Configuration
public class DataSourceConfig {@Bean@ConfigurationProperties(prefix = "spring.datasource.hikari")public HikariDataSource dataSource() {HikariDataSource ds = new HikariDataSource();// 关键：设置获取大小，避免一次性加载过多数据ds.setFetchSize(1000); // 设置连接超时，防止慢查询占满连接ds.setConnectionTimeout(30000);return ds;}
}

逐行解析：

setFetchSize(1000)：告诉 JDBC 驱动，每次从数据库拉取 1000 行数据到内存，而不是一行一行拉。这是提升 IO 效率的关键。
setConnectionTimeout(30000)：30 秒没拿到连接就报错，防止连接池耗尽导致整个服务雪崩。

2. 流式下载 Service

这是核心中的核心。我们使用 StreamingResponseBody 或 SseEmitter 来实现流式输出。这里以 Spring Boot 的 ResponseEntity<StreamingResponseBody> 为例。

@Service
public class TicketDownloadService {@Autowiredprivate TicketRepository repository;public StreamingResponseBody downloadTickets(Long trainId) {return output -> {try (PrintWriter writer = new PrintWriter(new BufferedWriter(new OutputStreamWriter(output)))) {// 使用游标分页，而不是 limit offset// 避免深分页性能问题Long lastId = 0L;int batchSize = 1000;while (true) {// 关键：基于主键 ID 的游标查询List<Ticket> batch = repository.findByTrainIdAndIdGreaterThan(trainId, lastId, batchSize);if (batch.isEmpty()) {break;}for (Ticket ticket : batch) {// 逐行写入，避免内存堆积writer.println(ticket.serializeToJson());writer.flush(); // 强制刷写，确保数据实时发出}lastId = batch.get(batch.size() - 1).getId();}} catch (IOException e) {throw new RuntimeException("Download failed", e);}};}
}

避坑指南：

不要用 LIMIT offset, size：当 offset 达到百万级时，数据库需要扫描前百万行再丢弃，性能极差。必须使用 WHERE id > lastId LIMIT size 这种游标方式。
writer.flush() 不能少：如果不 flush，数据会缓存在内存缓冲区，直到缓冲区满才发送。对于长连接下载，这会导致前端长时间收不到数据，误判为超时。
事务隔离：这个查询方法必须确保在只读事务中执行，或者无事务，避免锁表。

3. Repository 层 SQL 优化

public interface TicketRepository extends JpaRepository<Ticket, Long> {@Query("SELECT t FROM Ticket t WHERE t.trainId = :trainId AND t.id > :lastId ORDER BY t.id ASC")@org.springframework.data.jpa.repository.QueryHints(@QueryHint(name = "org.hibernate.fetchSize", value = "1000"))List<Ticket> findByTrainIdAndIdGreaterThan(@Param("trainId") Long trainId, @Param("lastId") Long lastId, Pageable pageable);
}

注意：这里使用了 @QueryHint 来动态设置 fetchSize，比在配置类里全局设置更灵活，适合针对特定慢查询优化。

运行与测试

代码写完了，怎么测？别只测功能，要测压力。

1. 基础功能测试

@SpringBootTest
class TicketDownloadServiceTest {@Autowiredprivate TestRestTemplate restTemplate;@Testvoid testDownloadStream() {ResponseEntity<String> response = restTemplate.getForEntity("/api/tickets/{trainId}/download", String.class, 1001L);assertEquals(HttpStatus.OK, response.getStatusCode());assertNotNull(response.getBody());// 验证数据行数assertTrue(response.getBody().split("\n").length > 0);}
}

2. 压力测试模拟

使用 JMeter 或 wrk 模拟 100 个并发下载请求。

观察指标：

内存占用：JVM Heap 是否持续增长？如果持续增长，说明 flush() 没生效，或者对象没释放。
数据库连接数：是否达到 HikariCP 的最大连接数？如果满了，新请求会排队，导致响应延迟飙升。
网络带宽：服务器出口带宽是否打满？如果是，说明瓶颈在网络，而非代码。

常见现象：很多初学者发现，测试环境很快，生产环境很慢。90% 的原因是生产环境的数据量是测试环境的 1000 倍，而 fetchSize 还是默认值。这时候，调整 fetchSize 和 batchSize 是性价比最高的优化手段。

优化扩展

基础功能跑通后，怎么让它更“像” 12306？

1. 数据压缩

12306 的数据下载通常伴随 Gzip 压缩。Spring Boot 默认支持，但需要配置：

server:compression:enabled: truemime-types: application/jsonmin-response-size: 1024

收益：带宽占用降低 70%-80%。对于长文本数据，压缩比极高。

2. 断点续传实现

利用 HTTP Range 请求。前端记录已下载的字节数，请求时带上 Range: bytes=1000- 头。

后端需要修改：

@GetMapping("/api/tickets/{trainId}/download")
public ResponseEntity<StreamingResponseBody> download(@PathVariable Long trainId,@RequestHeader(value = "Range", required = false) String range) {long startByte = 0;if (range != null && range.startsWith("bytes=")) {startByte = Long.parseLong(range.split("=")[1].split("-")[0]);}// 在 Service 层根据 startByte 计算跳过多少行// 注意：JSON 序列化后的字节偏移与行号不完全对应，需要缓存或重新计算// 简化版：直接从头开始，但前端丢弃前 N 字节// 进阶版：存储数据指纹，实现真正的二进制断点续传StreamingResponseBody body = downloadService.downloadTickets(trainId, startByte);return ResponseEntity.status(HttpStatus.PARTIAL_CONTENT).header("Content-Range", "bytes " + startByte + "-").body(body);
}

难点：JSON 流式输出的字节偏移很难精确定位到某一行。实际生产中，通常采用分片下载策略：将大数据集切成 10MB 一片，每片单独一个 URL，支持独立重试。这比字节级断点续传更可靠。