Spring Boot整合Kafka与Flink：疫情追踪系统大数据链路实战

每年到毕业设计季，总有人私信问我，能不能推荐一个既有工程含量、又能让答辩老师眼前一亮的题目。我的答案里经常会出现今天这个方向：基于Spring Boot与大数据组件的疫情追踪系统。这标题看起来是个信息管理系统，但做透了以后你会发现，它实际上是一条从前端接入、消息队列削峰、实时计算、风险分析到可视化大屏的完整数据链路。我做完这个项目后最大的感受是，Spring Boot不再是简单做CRUD的框架，而是能把大数据生态串起来的“业务中枢”。

如果你正在准备计算机毕业设计，或者想从“会写接口”进阶到“会搭数据链路”，这篇文章应该能帮你省下不少翻文档的时间。下文我会把项目从选题定位、技术选型、核心模块实现，到实际开发中踩过的坑、答辩时可能被追问的问题全部梳理一遍，内容偏工程实操，可以直接对照着调整成你自己的毕设方案。

1. 先想清楚：这到底是个管理系统，还是数据链路项目？

1.1 业务痛点与系统边界

我先说一个很多同学会踩的误区：看到“疫情追踪系统”这几个字，直接就开始设计人员管理、打卡记录上报、后台增删改查，最后做出来一个和“学生管理系统”没有本质区别的CRUD项目，只是把表名换成了“人员表”“打卡表”。如果题目里没有“大数据”三个字，这么做问题不大，但既然标题写了“基于大数据”，那系统必须回答一个核心问题：当数据量上来、时效性要求变高时，我的系统架构能撑住吗？

我建议把这个项目重新定义成一套“面向突发公共卫生事件的重点人群轨迹追踪与风险分析平台”。它面向两类用户：普通用户通过小程序或H5页面完成行程上报、健康状态打卡；管理端用户查看实时统计、查询人员轨迹、处理风险预警。也就是说，一个前台数据采集端，加一个后台监测分析端，底层再挂一条大数据实时处理链路，这是一个典型的“前中后”三层结构。

1.2 真实场景下的数据链路

既然是“追踪系统”，核心数据就是人和位置、时间的关联关系。我梳理的数据链路大概是这样的：用户行程上报后进入上报接口，接口不做复杂计算，直接把原始事件发给消息队列，再由流处理引擎从队列里拉数据，做清洗、补全、去重、聚合，再把结果写到OLAP数据库或业务数据库里。后端的查询接口和可视化大屏读取的，是已经处理好的结果数据。

这个设计思路和快递物流系统很像。你寄一个快递，快递员扫码上传，系统不是马上就更新整个路由，而是先把“包裹当前位置”这个事件记录下来，后台再异步更新运输轨迹。对人的健康监测也类似，上报动作本身就相当于一个快递节点，后台需要做的事情是，把同一时间窗口内、同一空间位置附近的人关联起来，做风险判定和趋势统计。理解了这一点，你就明白为什么要引入大数据组件，而不只是用一个MySQL表硬扛。

1.3 功能模块划分与需求拆解

我把整个系统的功能模块拆成六个部分，每个部分都有明确的业务产出。

需求拆解的时候一定要有一条主线，就是“上报-分析-预警-处置”的闭环。当时我把这个闭环画在一张纸上，贴在了显示器旁边，开发时每做一个模块都会回来对照一次，避免功能做偏。

2. 技术选型：Spring Boot做底座，大数据组件怎么搭配才不虚

2.1 为什么业务底座选Spring Boot

很多毕设之所以选Spring Boot，第一反应是好找工作、资料多，这个理由没错，但不完整。Spring Boot真正厉害的地方在于它解决了业务系统开发中大量枯燥的集成问题，提供了starter机制、自动装配和约定优于配置的开发体验。你引入一个依赖，框架自动帮你在容器里配置好对应的Bean，基本不需要手动写XML配置。

我理解的Spring Boot自动装配原理，简单说是通过@EnableAutoConfiguration注解，结合META-INF/spring.factories或AutoConfiguration.imports文件里注册的配置类，在应用启动时按条件加载对应的Bean。这个机制对毕设来说意味着两件事：第一，项目结构可以非常清爽，XML配置大量减少；第二，集成第三方组件时，只要找到对应的starter，引入依赖就可以快速跑通，这对时间有限的毕设来说是决定性的优势。

2.2 消息队列到底要不要上Kafka

这个项目的题目里同时有“大数据”和“Spring Boot”，如果要体现实时处理的场景，第一步就是要引入消息队列。在Kafka、RabbitMQ、RocketMQ之间我最终选了Kafka，原因主要有三个：第一，Kafka天生为高吞吐量的流式数据设计，日志类、轨迹类数据写入性能非常突出；第二，它和Flink、Spark Streaming配合最成熟，几乎已经是大数据处理链路的事实标准；第三，Kafka的安装部署相对轻量，本地开发时用Docker启动一个单节点就能跑通全流程。

但如果你的机器内存有限，或者不想额外维护中间件，也可以退而求其次用Redis的Stream或List结构暂存数据。我不建议在毕设中全部用同步接口处理，因为这样就完全没有体现“大数据架构”中的削峰填谷思想。哪怕只是加一个线程池做异步处理，也比全部同步强。不过从我自己的答辩经验来看，只有当你真正用上Kafka并且能解释清楚为什么用它，老师才会觉得这个项目的“大数据”含量是真实的。

2.3 实时计算引擎：Flink还是Spark Streaming

到了实时统计和风险分析这一层，常见的选择是Flink或Spark Streaming。Spark Streaming更偏向“微批处理”，每隔几秒把一批数据拿过来统一处理，优点是API简单、生态丰富；Flink是真正的流式计算引擎，数据是一条一条处理的，延迟更低，窗口机制和状态管理也更灵活。

在毕设这个场景里，我的建议是优先选Flink。因为它对窗口计算、事件时间、迟到数据处理都有比较完整的支持。比如要统计“近15分钟内某商场周边上报人数超过阈值”，如果用Flink的滑动窗口，代码几行就能搞定；如果自己写定时任务去扫数据库，逻辑上也能实现，但实时性差，且响应式不好。再有，Flink可以无缝消费Kafka里的Topic，开箱即用，不需要额外写复杂的接入层。

2.4 存储组件如何分工，别让MySQL干所有活

存储选型是整个项目架构里最需要动脑的一部分。我项目里最终用了三个存储组件，各干各的：

• MySQL：存业务基础数据，比如用户表、地点表、配置表，以及一些管理端需要的强一致数据。用MyBatis Plus操作，开发效率高。
• ClickHouse：存需要做联机分析的大量轨迹明细、统计结果。ClickHouse是列式存储，在聚合查询、范围查询上的表现远好于MySQL，特别适合大屏的统计报表。
• Redis：做缓存和实时去重，比如记录上报接口的幂等标记、保存高频访问的热点配置，还可以用Redis的Geo命令做附近地点查询。

如果你的本机配置一般，一下子跑起三个存储组件会很吃力。我当时用Docker分别启动了单节点的Kafka、MySQL、Redis和ClickHouse，一共分配了4GB内存左右，开发时还能接受。如果内存实在紧张，ClickHouse也可以先用MySQL加定时聚合表代替，只需在架构说明里写清楚最终方案即可。

3. 核心设计：从上报到风险分析，每一步的关键实现

3.1 行程上报接口与数据入Kafka

上报接口要做到“快”，不要在接口内部做太多耗时操作。我设计的上报接口接收一个ReportDTO，里面包含人员ID、地点ID或经纬度、停留开始时间、停留结束时间、上报渠道等字段。接口第一件事是参数校验，第二件事是把数据转成消息发送到Kafka的report_topic，发送成功后就立即返回“上报成功”。后续的轨迹写入、风险分析都在消费端完成。

我当时还用@KafkaListener写了一个消费者，把从Topic里收到的消息解析成实体，写入MySQL的轨迹表。这个步骤本身很简单，但需要注意生产者和消费者之间的消息结构一致性，不要在生产端用JSON序列化，到了消费端却试图读取Java对象，这样很容易报反序列化错误。实际开发中我统一使用JSON字符串作为传输格式，并在文档里定义了字段含义。

一个看起来不起眼但很关键的点是接口幂等性设计。用户在弱网环境下点了一次上报，前端可能会自动重试两三次，如果接口没有幂等保护，后台就会收到多条重复数据。我当时的处理方案是使用人员ID加时间戳生成一个唯一业务ID，在Redis里用setNx命令做标记，如果标记已存在就直接拒绝。

3.2 时空伴随风险判定的算法实现

这是整个项目里最有技术含量的模块。时空伴随本身不是一个非常高深的算法，核心逻辑是：判断两个人是否在相同的时间窗口内、出现在相同的空间范围内。如果把时间离散成15分钟一个槽位，把空间按某个网格大小划分，那么同一网格且同一时间槽内出现的两个人，就有“轨迹重合”的可能。

我在实现时借鉴了GeoHash的思路。GeoHash可以把二维经纬度编码成一个短字符串，字符串相同的前缀越长，表示两个点距离越近。代码逻辑大致可以描述为：

1. 从Kafka消费轨迹数据，解析出人员ID、经纬度、时间戳；
2. 用GeoHash工具把经纬度编码成7位字符串，精度大约几百米；
3. 计算时间桶编号，比如时间戳除以900秒取整，表示第几个15分钟；
4. 以“GeoHash值 + 时间桶编号”作为关联键，进入Flink窗口；
5. 在窗口内做分组，如果同一分组内出现不同人员ID，则生成一条关联记录，再结合业务规则判断风险等级。

这里有一个比较容易忽略的问题：单纯的GeoHash不能完全解决边界邻居的问题，两个人可能就在网格线两侧，实际距离很近，但因为GeoHash前缀不同被漏掉了。要处理这个问题，专业做法是取当前格子周围相邻8个格子的编码一起做关联判断。好在Flink里处理这种需求不算困难，直接把切分好的完整编码映射成多组key就行。

3.3 风险分析与统计看板怎么设计

统计看板是大数据能力的直接出口。我在管理端做了以下几个维度的指标：每日新增上报人数、累计健康状态分布、近7天活跃地点Top10、重点区域15分钟内人流量趋势、异常事件告警次数。这些指标如果都写在SQL里硬查，光是联表查询就能把MySQL拖垮。

所以我把Flink的实时聚合结果输出到ClickHouse的汇总表，每5分钟更新一次。在ClickHouse里建了以人员维度、区域维度、时间维度为主键的聚合表。查询时只需要按日期和地区过滤，ClickHouse返回数值的速度非常快，前端大屏基本能做到秒开。这一步也让我在写论文和做答辩PPT时有非常明确的亮点可讲：你真正分清了OLTP和OLAP的边界。

3.4 预警通知与系统集成

预警模块要求当某个区域短时间内上报的人数超过阈值，或者出现风险人员轨迹关联时，系统要主动推送给管理员。我用了WebSocket实时推送浏览器通知，并预留了短信和邮件接口。需要注意的细节是，不要在实时计算链路里直接调短信网关，否则可能会因为第三方服务响应慢导致整个数据处理任务阻塞。正确的做法是把预警事件先发到一个独立的Kafka主题，由另一个消费者专门处理通知任务，这样“计算逻辑”和“通知动作”就解耦了。

4. Spring Boot整合大数据组件实操细节

4.1 环境准备与版本匹配表

如果你准备复现这个项目，环境版本请直接参考下面这个列表，能少踩很多坑。

我看到不少同学直接用了Spring Boot 3.2加JDK21，然后发现很多旧教程里的javax包全部需要改成jakarta，如果只是写接口倒还好，一旦要整合一些内部依赖，真的会被版本问题折磨到崩溃。毕设项目我建议求稳不求新，2.7.18加JDK8的组合虽然不酷，但绝对可靠。

4.2 Spring Boot工程里接入Kafka的完整配置

在pom.xml中引入依赖之后，最核心的就是配置生产者和消费者。下面这份配置是我实际用过的，直接贴出来给你参考。

xml复制<dependency>
    <groupId>org.springframework.kafka</groupId>
    <artifactId>spring-kafka</artifactId>
</dependency>

然后修改application.yml：

yaml复制spring:
  kafka:
    bootstrap-servers: localhost:9092
    producer:
      key-serializer: org.apache.kafka.common.serialization.StringSerializer
      value-serializer: org.apache.kafka.common.serialization.StringSerializer
      acks: all
    consumer:
      group-id: report-group
      key-deserializer: org.apache.kafka.common.serialization.StringDeserializer
      value-deserializer: org.apache.kafka.common.serialization.StringDeserializer
      auto-offset-reset: latest
      enable-auto-commit: false

这里重点说明两点。第一，acks: all表示生产者要等所有副本都写入成功后才会确认，可以最大程度避免消息丢失，但吞吐量会稍微下降；对一个面向公共卫生事件的追踪系统来说，数据的可靠性优先于极致吞吐，这个取舍合情合理。第二，enable-auto-commit: false是建议手动提交偏移量，否则可能出现消息还没处理完，但偏移量已经提交导致重启后漏数据的问题。手动提交的代码可以在@KafkaListener方法的最后调用acknowledgment.acknowledge()完成。

生产者侧发送消息的代码非常简单，注入KafkaTemplate后调用send方法即可：

java复制kafkaTemplate.send("report_topic", JSON.toJSONString(reportDTO));

我这里再补充一个容易被忽略的点：如果同一个Topic被多个消费者实例消费，要注意消费者组的概念。不同group-id的消费者会各自消费一份完整的数据，相同group-id的多个消费者会分摊消息。如果你同时启动两个服务实例做负载均衡，请确保它们配置了相同的group-id，否则每条消息会被重复处理两次。

4.3 用Flink实现分钟级统计

Flink接入Kafka后做一个窗口统计，这可以说是大数据链路中代码量最少、但效果最直观的部分。我写了一段Flink SQL风格的示例，你可以感受一下实现逻辑：

sql复制CREATE TABLE report_source (
    user_id STRING,
    geo_hash STRING,
    event_time TIMESTAMP(3),
    WATERMARK FOR event_time AS event_time - INTERVAL '10' SECOND
) WITH (
    'connector' = 'kafka',
    'topic' = 'report_topic',
    'properties.bootstrap.servers' = 'localhost:9092',
    'properties.group.id' = 'flink-report-group',
    'format' = 'json',
    'scan.startup.mode' = 'latest-offset'
);

CREATE TABLE area_stat_sink (
    stat_time STRING,
    geo_hash STRING,
    user_cnt BIGINT,
    PRIMARY KEY (stat_time, geo_hash) NOT ENFORCED
) WITH (
    'connector' = 'jdbc',
    'url' = 'jdbc:clickhouse://localhost:8123/health',
    'table-name' = 'area_stat',
    'username' = 'default',
    'password' = '',
    'sink.buffer-flush.max-rows' = '1000'
);

INSERT INTO area_stat_sink
SELECT
    DATE_FORMAT(TUMBLE_START(event_time, INTERVAL '5' MINUTE), 'yyyy-MM-dd HH:mm:ss') AS stat_time,
    geo_hash,
    COUNT(DISTINCT user_id) AS user_cnt
FROM report_source
GROUP BY TUMBLE(event_time, INTERVAL '5' MINUTE), geo_hash;

这段逻辑做的事情是，每5分钟统计一次每个GeoHash区域内出现了多少去重用户。如果你不想在项目里额外引入一套Flink开发环境，也可以退而求其次在Spring Boot里写定时任务，配合Redis HyperLogLog做近似去重计数，但这就回到前面说的，大数据含量会弱很多。我还是建议完整走一遍Flink流程，因为论文的创新点和技术描述会好写很多。

4.4 Docker部署整个项目

毕设验收时一定会让你演示运行，如果现场环境和你本机不一致，跑不起来会非常尴尬。我建议提前把中间件全部用Docker Compose编排起来，这样无论换到哪台电脑，只要安装了Docker和Docker Desktop，就能一键启动依赖环境。

下面是一个简化版的docker-compose.yml片段：

yaml复制version: '3.8'
services:
  mysql:
    image: mysql:8.0
    environment:
      MYSQL_ROOT_PASSWORD: root
      MYSQL_DATABASE: health
    ports:
      - "3306:3306"
    volumes:
      - ./mysql_data:/var/lib/mysql

  redis:
    image: redis:6.2
    ports:
      - "6379:6379"

  kafka:
    image: bitnami/kafka:2.8.1
    ports:
      - "9092:9092"
    environment:
      KAFKA_CFG_NODE_ID: 0
      KAFKA_CFG_PROCESS_ROLES: controller,broker
      KAFKA_CFG_LISTENERS: PLAINTEXT://:9092,CONTROLLER://:9093
      KAFKA_CFG_ADVERTISED_LISTENERS: PLAINTEXT://localhost:9092
      KAFKA_CFG_CONTROLLER_LISTENER_NAMES: CONTROLLER
      KAFKA_CFG_LISTENER_SECURITY_PROTOCOL_MAP: CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT
      KAFKA_CFG_CONTROLLER_QUORUM_VOTERS: 0@kafka:9093

  clickhouse:
    image: clickhouse/clickhouse-server:22.8
    ports:
      - "8123:8123"
      - "9000:9000"
    volumes:
      - ./clickhouse_data:/var/lib/clickhouse

Spring Boot应用本身也可以打包成Docker镜像，这里的重点是要注意基础镜像里的JDK版本必须和项目编译版本一致。我遇到过自己电脑上JDK11编译的jar包，丢到JDK8的容器里直接报UnsupportedClassVersionError，排查了半天才发现是基础镜像版本不对。用Docker Desktop调试时，先用docker logs看容器启动日志，是最快的排查路径。

5. 我踩过的坑和你在答辩时会被问的问题

5.1 真实开发中的典型问题汇总

常见问题和解决办法，我整理成了一个速查表，如果你在实际开发中遇到同类问题，可以按表排查。

这七条问题里，前三条是最容易碰到的，也很适合写进论文的“系统调试与问题分析”章节。你在写这块时千万不要只写“我修改了配置就解决了”，要像上面表格一样把原因分析和解决方案对照起来，老师能一眼看出你是真做过而不是光抄代码。

5.2 Windows本机调试大数据组件有什么建议

我自己的开发环境是Windows，跑Kafka和Flink时主要问题在于两个：一是端口占用，Kafka默认使用的9092经常会被其他进程占用；二是脚本命令和Linux有差异，很多网上的教程只写Linux命令，Windows下要用.bat脚本。

解决思路有两个。第一种是尽量用Docker Desktop跑中间件，Windows下启动Docker容器比直接下载压缩包省心很多。Kafka、ClickHouse、Redis都有官方镜像，Compose文件写好之后，docker compose up -d就能起来。第二种是开发调试时把Flink任务跑在IDE里，用本地的执行环境，不提交到集群，这样可以看到完整的日志输出，也方便断点调试。等代码验证通过，论文里再补上提交到集群运行的截图即可。

5.3 数据和压测怎么准备，能让答辩更有说服力

很多同学的毕设项目界面很漂亮，但演示时用的是MySQL里人工添加的几十条数据，点开统计大屏图表全是空的。这种情况在答辩现场很容易被老师追问“数据量呢？”。

我建议写一个简单的数据模拟器，用循环脚本生成虚假的轨迹上报数据，投递到Kafka里。你可以参考下面的思路：

1. 预先准备10000个模拟用户ID；
2. 随机生成城市范围内的经纬度坐标，再按一定概率聚合成几个热点区域；
3. 给每个用户生成连续的轨迹点，时间间隔设定为10到30分钟；
4. 用Java或Python脚本每隔100毫秒发送一批数据到Kafka。

准备完模拟数据后，用Flink任务跑一遍，统计结果表里自然会出现足够的实时数据。如果被问到系统性能，我还可以用JMeter对上报告诉接口做一次简单的并发压测，记录下每秒处理请求数TPS和响应时间，这个数据放在论文的测试章节非常有说服力。

5.4 答辩现场可能被追问的问题

我复盘了自己的答辩过程，列出几个命中率极高的问题，你提前准备答案就不会卡壳：

第一问：你项目里说大数据，到底数据量有多大？这个问题其实就是看你是不是真正理解大数据场景。你不需要说几百亿条，可以用模拟器的数据量和系统设计容量来回答。比如“系统设计时参照了每分钟一万条上报的峰值场景，本机环境测试用模拟器产生了数十万条轨迹记录，消息中间件能支撑水平扩展”。

第二问：为什么不用Redis直接存轨迹，还要引入Kafka？回答主线是：Redis是内存数据库，虽然读写快但容量有限，适合做缓存和去重；Kafka是分布式消息队列，天然支持数据持久化、回放和多个消费者订阅，数据经过Kafka后才能再分流给实时计算、离线数仓等多个下游。

第三问：Flink和Spark Streaming你了解区别吗？之前我讲过，Flink是逐条处理的原生流引擎，Spark Streaming本质上是微批处理。如果老师追问得更细，你可以补充Flink支持事件时间和watermark机制，处理乱序数据时更优雅。

第四问：如果系统要部署到生产环境，哪些环节需要改？这个问题考察你的工程化认知。你可以说：Kafka会有多副本配置，ClickHouse会做分布式集群，Spring Boot应用会通过Nginx负载均衡多实例部署，还要加入监控告警体系等。不用面面俱到，能说出两三点合理的架构扩展方向就够了。

最后补几句我的经验

从开题到答辩，这个项目我前前后后调试了一个多月。最深的体会是，毕设题目里带不带“大数据”三个字，决定了你要用管理系统的思路去设计，还是用数据处理链路的思路去设计。如果你最后能让评委看到一条清晰的数据流，从上报接口一路流到Kafka、Flink、ClickHouse，再到可视化大屏，那这个项目的技术高度就立住了。至于代码量，反而不用刻意追求多，逻辑通顺、模块边界清楚才是关键。

还有个小建议，如果你时间紧张，不需要把所有大数据组件都学完再动手。先把Spring Boot接口写好，把Kafka跑通，再加入最简单的Flink消费任务，每做成一步都会带来正反馈。这个项目后续还可以扩展的方向其实也不少，比如接入更完善的规则引擎、增加移动端小程序入口、引入机器学习模型做趋势预测。只要基础架构不打歪，后续每一步都是加分项。