简介本资源是一套面向物联网与环境监测领域开发者的Java水质检测系统完整源码适用于高校课程设计、毕业设计及中小型智能水务项目快速原型开发。系统基于Java语言构建集成阿里云数据库与MySQL双数据源实现传感器数据采集、用户权限管理、实时数据显示及换水电机远程控制等核心功能解决水质监测场景中软硬件协同与云端数据交互的实际问题。压缩包共97个文件含27个Java业务逻辑文件、35个XML配置文件涵盖数据库连接与Spring框架配置、19个PNG界面资源图、3个Gradle构建脚本及配套JAR依赖包整体大小仅1.71MB结构清晰、模块解耦便于理解IoT系统分层架构与云边协同机制。目前已有328人学习下载开发者可直接导入IDE运行快速掌握JDBC数据库连接、NB-IoT设备通信、JavaFX/Swing界面开发及Gradle工程管理等关键技术实践路径。基于Java和阿里云数据库的水质检测系统整套源码设计与落地经验分享最近在整理一套基于Java后端与阿里云数据库的水质检测系统源码从需求梳理、库表设计、接口实现到上线部署几乎每个环节都踩了一遍坑。这个项目本身不算大但涉及物联网设备数据接入、实时检测、阈值告警、历史趋势分析这些常见业务非常适合Java初学者练手也适合想做智慧水务方向产品的同学参考。整套系统以Java为核心语言数据库用的是阿里云RDS MySQL前端配套一个简单的可视化大屏我把编码思路、关键实现和可复用的源码片段都放在了这篇文章里。不管你是刚学完Spring Boot想找个完整项目练手还是已经在做环保、水务相关系统想参考一下架构设计这篇文章都能帮到你。我会把项目从0到1的拆解过程、核心源码解释、以及在实际部署中遇到的问题排查方法全部写清楚尽量做到看完全文能直接照着落地。1. 项目整体设计与技术选型思路1.1 为什么用Java配合阿里云数据库来做水质检测水质检测系统最核心的链路是设备采集水质数据数据上传到服务端服务端落库然后做阈值判断、告警通知、历史查询。这套链路对后端的要求其实很常规但有几个硬性指标并发采集量要扛得住、数据不能丢、查询历史数据要快、后期要能平滑扩容。Java在这个领域依然是稳妥的首选。Spring Boot生态成熟社区资料多招人也好招而且Java的强类型和运行时稳定性在长时间运行的采集服务上比脚本语言更让人放心。另外一个重要考量是阿里云数据库RDS MySQL之所以选它而不自建数据库最大的原因是省心。自建MySQL意味着DBA、备份、高可用、监控全得自己搞而RDS直接把这些能力托管了自动备份、主备切换、慢查询分析这些开箱即用对中小团队来说性价比很高。实际上这套系统也可以部署到阿里云ECS上和RDS走内网连接既稳定又免流量费。如果你是个人学习或者演示环境ECS可以选最低配的2核4GRDS选最小的2核4G就够跑。1.2 系统整体功能模块划分项目功能拆成六个模块设备管理、数据采集、实时检测与存储、告警管理、统计分析与大屏展示、系统管理。每个模块之间边界清晰便于团队分工。设备管理模块负责维护监测点位的信息比如点位名称、所属区域、部署位置、在线状态。数据采集模块是连接设备和系统的桥梁在实际项目中通过MQTT协议接收硬件上传的数据在这套演示源码里则是用模拟数据发生器模拟硬件上报。实时检测与存储模块负责把上报的数据解析成一小时的检测记录同时根据各类指标的标准阈值判断是否超标。告警管理则在超标时生成一条告警记录并支持通过邮件或接口推送通知。统计分析模块提供按站点、按时间段的检测趋势查询大屏展示则是把这几部分数据汇总后通过图表呈现。1.3 技术栈清单和版本选型说明Java 8实际生产环境用Java 8仍然占大头稳定各种中间件兼容性也最好Spring Boot 2.7.x选这个版本是因为它稳定而且对应的Spring Cloud生态资料齐全MyBatis-Plus 3.5.x单表CRUD不用写SQL提升开发效率阿里云RDS MySQL 8.0阿里云物联网平台如果接真实硬件用这个做设备接入和消息流转ECharts 5.x前端大屏图表Redis可选用来做热点数据缓存比如最近的监测数据选型逻辑很简单尽量贴近真实企业项目的技术栈让看完源码的人直接能用这套技术栈去面试或工作。除了技术选型前端部分没有用太重的前端框架直接用了HTML Vue 3 CDN ECharts这样可以降低上手门槛让整个项目的重心放在Java后端代码上。2. 数据库设计与核心表结构2.1 数据表设计的核心思路水质检测系统虽然业务看起来简单但表结构设计需要注意时间和设备两个维度的数据组织。核心表分四张监测点表、水质指标定义表、水质检测数据表、告警记录表。如果需要完整的权限功能可以再加上用户表和角色表这里先用最简方案。重点说一下水质检测数据表这是整个系统数据量最大的一张表也是后续性能优化的重点。每台设备每小时上报一条记录一个点位一天就是24条如果有100个点位一年就是876000条。到了百万级数据量普通的查询已经开始变慢所以表设计的时候要优先考虑分表、索引和归档方案。2.2 建表语句和字段说明下面是核心表的建表SQL我用MySQL 8.0语法写的。-- 监测点表 CREATE TABLE monitor_point ( id bigint(20) NOT NULL AUTO_INCREMENT COMMENT 主键ID, point_code varchar(32) NOT NULL COMMENT 监测点编码, point_name varchar(64) NOT NULL COMMENT 监测点名称, location varchar(128) DEFAULT NULL COMMENT 所在位置, status tinyint(4) DEFAULT 1 COMMENT 状态 1-正常 0-停用, create_time datetime DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 更新时间, PRIMARY KEY (id), UNIQUE KEY uk_point_code (point_code) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT监测点信息表; -- 水质指标定义表 CREATE TABLE water_index ( id bigint(20) NOT NULL AUTO_INCREMENT, index_code varchar(32) NOT NULL COMMENT 指标编码, index_name varchar(64) NOT NULL COMMENT 指标名称, unit varchar(16) DEFAULT NULL COMMENT 单位, standard_max decimal(10,2) DEFAULT NULL COMMENT 标准上限值, standard_min decimal(10,2) DEFAULT NULL COMMENT 标准下限值, sort_order int(11) DEFAULT 0 COMMENT 排序, PRIMARY KEY (id), UNIQUE KEY uk_index_code (index_code) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT水质指标定义表; -- 水质检测数据表核心表 CREATE TABLE water_quality_data ( id bigint(20) NOT NULL AUTO_INCREMENT, point_code varchar(32) NOT NULL COMMENT 监测点编码, index_code varchar(32) NOT NULL COMMENT 指标编码, data_value decimal(10,2) NOT NULL COMMENT 检测数值, detect_time datetime NOT NULL COMMENT 检测时间, is_warning tinyint(4) DEFAULT 0 COMMENT 是否超标 1-是 0-否, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_point_time (point_code, detect_time), KEY idx_index_time (index_code, detect_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT水质检测数据表; -- 告警记录表 CREATE TABLE water_quality_warning ( id bigint(20) NOT NULL AUTO_INCREMENT, point_code varchar(32) NOT NULL COMMENT 监测点编码, index_code varchar(32) NOT NULL COMMENT 指标编码, data_value decimal(10,2) NOT NULL COMMENT 超标时的数值, standard_max decimal(10,2) DEFAULT NULL, standard_min decimal(10,2) DEFAULT NULL, warning_desc varchar(255) DEFAULT NULL COMMENT 告警描述, status tinyint(4) DEFAULT 0 COMMENT 处理状态 0-未处理 1-已处理, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_point_status (point_code, status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT水质告警记录表;2.3 索引设计和水质数据的存储优化水质检测数据表是典型的时间序列数据查询场景有两种一种是按点位查最近一段时间的数据一种是按指标查某个时间范围的数据。所以在索引设计上我建立了一个联合索引(point_code, detect_time)用于点位维度查询又建立了一个(index_code, detect_time)用于指标维度查询。看起来有点冗余但实际查询性能提升非常明显。这里要注意一个坑不要在detect_time上单独建索引单列索引无法同时满足两种查询场景。联合索引的顺序也很重要等值条件放前面、范围条件放后面。如果是真实生产环境几十个监测点跑几年以后数据量会到千万级单纯的索引优化已经不够了建议按月份做RANGE分区。举例来说把water_quality_data表按detect_time做月度分区这样老数据可以直接分区归档查询也能走分区裁剪速度提升非常明显。分区表在RDS上配置很方便语法如下ALTER TABLE water_quality_data PARTITION BY RANGE (TO_DAYS(detect_time)) ( PARTITION p202501 VALUES LESS THAN (TO_DAYS(2025-02-01)), PARTITION p202502 VALUES LESS THAN (TO_DAYS(2025-03-01)), PARTITION p202503 VALUES LESS THAN (TO_DAYS(2025-04-01)) );新增分区可以用ALTER TABLE water_quality_data ADD PARTITION动态加配合定时任务可以提前创建未来六个月的分区。3. 核心功能模块源码实现解析3.1 数据采集模拟数据发生器与真实设备接入的兼容设计这套源码里我设计了一个模拟数据发生器作用是模拟水质监测设备定时上报pH值、溶解氧、浊度、温度等指标。为什么用模拟数据因为真实的设备接入需要硬件配合对学习源码的人来说门槛太高。模拟数据发生器可以让系统在完全脱离硬件的情况下跑起来你只需要观察数据入库和控制台日志就能理解整个数据流转过程。模拟数据发生器的核心代码逻辑如下Component public class DataSimulator { private static final Random RANDOM new Random(); public MapString, Object generateData(String pointCode) { MapString, Object data new HashMap(); data.put(pointCode, pointCode); data.put(ph, round(6.5 RANDOM.nextDouble() * 2)); data.put(dissolvedOxygen, round(5 RANDOM.nextDouble() * 4)); data.put(turbidity, round(0.5 RANDOM.nextDouble() * 10)); data.put(temperature, round(10 RANDOM.nextDouble() * 20)); data.put(timestamp, LocalDateTime.now().format(DateTimeFormatter.ofPattern(yyyy-MM-dd HH:mm:ss))); return data; } private double round(double value) { return Math.round(value * 100.0) / 100.0; } }如果你要用真实硬件只需要把模拟器替换成一个MQTT客户端在KafkaListener或RabbitListener里接收上游系统推送过来的数据即可。为了兼容这两种场景我在接口设计上做了一层抽象统一入口是WaterDataCollectService模拟器和真实设备都实现同一个接口。3.2 数据落库与批量插入的性能优化水质检测数据写入的特点是单条数据量小但频率高。如果用MyBatis-Plus的save方法一条一条地插入到数据量大的时候数据库压力会非常大。我在源码里专门用了自定义的批量插入SQL配合MyBatis-Plus的insertBatchSomeColumn方法把一批数据一次插入。public interface WaterQualityDataMapper extends BaseMapperWaterQualityData { int insertBatchSomeColumn(Param(list) ListWaterQualityData list); } // 调用逻辑 public void saveBatchData(ListWaterQualityData list) { if (CollectionUtils.isEmpty(list)) { return; } // 分批插入每批500条 ListListWaterQualityData partition ListUtils.partition(list, 500); for (ListWaterQualityData batch : partition) { waterQualityDataMapper.insertBatchSomeColumn(batch); } }批量插入能大幅减少网络往返和事务开销实测下来500条一批、事务控制在1秒内提交性能是最稳妥的。需要提醒的是批量插入的事务不要选太大否则一旦失败回滚的数据太多影响其他写入任务。3.3 实时检测、超标判断与告警触发机制实时检测的逻辑是每次数据入库后立即和标准指标表里的上下限值做比对。如果超出范围就生成一条告警记录同时标记这条数据为超标状态。Service public class WaterQualityCheckService { Resource private WaterIndexMapper waterIndexMapper; Resource private WaterQualityDataMapper waterQualityDataMapper; Resource private WaterQualityWarningMapper warningMapper; public void checkAndWarn(WaterQualityData data) { WaterIndex index waterIndexMapper.selectByCode(data.getIndexCode()); if (index null) { return; } boolean over false; if (index.getStandardMax() ! null data.getDataValue().compareTo(index.getStandardMax()) 0) { over true; } if (index.getStandardMin() ! null data.getDataValue().compareTo(index.getStandardMin()) 0) { over true; } if (over) { data.setIsWarning(1); WaterQualityWarning warning new WaterQualityWarning(); warning.setPointCode(data.getPointCode()); warning.setIndexCode(data.getIndexCode()); warning.setDataValue(data.getDataValue()); warning.setStandardMax(index.getStandardMax()); warning.setStandardMin(index.getStandardMin()); warning.setWarningDesc(指标[ index.getIndexName() ]超标); warningMapper.insert(warning); // 发送通知邮件、短信、钉钉机器人等 notifyService.sendWarningMessage(warning); } waterQualityDataMapper.updateById(data); } }判断逻辑看起来简单但实际生产环境要注意一个问题超标的定义往往不是瞬时值超标而是连续几次采样都超标才算真超标否则传感器抖动就会造成误报。所以真实项目中会加一个“连续N次超标确认”的机制这里我在源码里留了扩展点你可以在checkAndWarn方法里统计最近几次记录再决定是否告警。3.4 水质大屏展示与统计查询实现统计查询的核心是分组聚合SQL这里我用MyBatis-Plus的Wrapper实现也可以直接用自定义SQL。SELECT point_code, index_code, AVG(data_value) AS avg_value, MAX(data_value) AS max_value, MIN(data_value) AS min_value FROM water_quality_data WHERE detect_time BETWEEN #{startTime} AND #{endTime} GROUP BY point_code, index_code这段SQL会返回某段时间内每个监测点、每项指标的平均值、最大值和最小值。前端大屏拿到这些数据后通过ECharts渲染折线图和柱状图非常直观。大屏页面我用的是Vue 3 ECharts代码结构简单清晰你只需要在HTML里引入ECharts的CDN然后向后端接口请求数据再渲染。4. 系统部署与阿里云数据库的接入配置4.1 阿里云RDS MySQL实例的创建和配置这一节我按实际操作步骤写出来方便你照着做。第一步登录阿里云控制台在RDS管理页面创建一个MySQL实例。选版本的时候推荐8.0因为8.0在JSON字段支持、窗口函数、性能上都要优于5.7。第二步设置数据库账号和密码。需要注意的是生产环境不要把数据库账号直接设为root建议建一个专用账号只授予业务库的增删改查权限。账号权限最小化这是云端数据库的基本安全习惯。第三步在“数据库管理”里创建数据库字符集选utf8mb4排序规则选utf8mb4_general_ci。utf8mb4能完整支持中文和emoji表情避免出现中文乱码问题。第四步把云服务器ECS的专有网络VPC和RDS实例的VPC设置为同一个这样程序里连接数据库时直接填内网地址。内网连接的好处是速度快、稳定还不占用公网流量。如果只是本地调试需要在RDS白名单里加上你本机的公网IP。4.2 Spring Boot项目配置阿里云RDS连接在application.yml里填写数据库连接信息注意加上时区参数防止时间慢8小时的问题。spring: datasource: url: jdbc:mysql://rm-xxxxxxx.mysql.rds.aliyuncs.com:3306/water_quality?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: water_app password: your_password driver-class-name: com.mysql.cj.jdbc.Driver mybatis-plus: configuration: map-underscore-to-camel-case: true global-config: db-config: id-type: auto配置中有一个细节很多人容易忽略serverTimezone必须设置为Asia/Shanghai否则JDBC驱动会默认使用UTC时区导致插入数据库的时间比实际时间少8小时。我刚开始部署的时候就是没加这个参数数据全部慢8小时排查了半天。连接池配置也建议显式写出来我用的是HikariCPSpring Boot默认连接池就是它性能很好参数建议如下spring: datasource: hikari: minimum-idle: 5 maximum-pool-size: 20 connection-timeout: 30000 idle-timeout: 600000最大连接数和最小空闲连接数要根据并发量来调整连接数不是越大越好太大反而会打满RDS的连接数上限。4.3 项目打包和在服务器上的常见部署方式项目用了Maven作为构建工具打包命令如下mvn clean package -DskipTests打包后在target目录下会生成一个water-quality-system.jar使用nohup命令直接启动nohup java -Xms512m -Xmx512m -jar water-quality-system.jar app.log 21 如果你有多台服务器需要部署可以再套一层Nginx做负载均衡但演示环境单机就够。需要提醒的是阿里云ECS的安全组里一定要放行后端服务端口比如8080端口否则外部请求访问不到接口。这个坑我在第一次部署时踩过启动日志显示正常但接口就是不通最后发现是安全组没有添加规则。5. 实际操作中遇到的高频问题和排查方法5.1 数据库连接超时与连接池连接失效系统运行一段时间之后有时会遇到Communications link failure异常。这通常是RDS MySQL的wait_timeout参数默认8小时连接池里超过8小时没有使用的连接被数据库服务端断开了。解决办法是配置HikariCP的连接存活检测同时在连接池中启用keepaliveTime。spring: datasource: hikari: connection-test-query: SELECT 1 keepalive-time: 300000 validation-timeout: 3000加上这些配置后HikariCP会定时检查连接是否可用不可用就销毁重建跑几天也不会再报连接超时。5.2 高并发写入时数据重复采集模拟数据发生器如果在定时任务创建时没有做好幂等控制很容易出现同一条监测数据被重复写入。原因通常是定时任务被重复触发或者Service方法没有加事务控制。我的处理方式是在数据表里加上唯一键(point_code, index_code, detect_time)这样就算代码里重复调用数据库也能兜底去重。这个方案简单粗暴但在生产环境很有效数据库层面拦截永远比应用层可靠。5.3 MyBatis-Plus批量插入不支持导致方法报错MyBatis-Plus内置的BaseMapper没有insertBatchSomeColumn这个方法这个方法是扩展包提供的需要引入专门的扩展包并在Mapper上继承InsertBatchSomeColumn接口。如果你发现调用报错多半是没加扩展依赖注意在pom.xml中加入对应依赖即可。5.4 大屏数据刷新慢如何优化如果大屏每次加载都要全量扫描water_quality_data表几百万条数据速度会很感人。我在项目里用了三层优化方案第一层SQL层优化。统计查询只聚合最近24小时或者最近7天的数据并且在WHERE条件里强制带上detect_time范围。第二层Redis缓存。热点统计结果缓存5分钟前端大屏轮询的时候直接打缓存数据库压力减少90%以上。第三层定时汇总表。如果数据量进一步增长可以每日凌晨跑定时任务把昨天的数据预聚合到一张汇总表大屏直接查汇总表毫秒级返回。5.5 告警信息太多淹没重要问题告警模块刚开发完联调时我发现只要有一次数据超标就会收到一堆重复告警。一个监测点的一个指标连续超标5次系统就发5条告警。处理办法是增加“告警聚合”逻辑同一个点位、同一个指标在30分钟内只发一条告警后续超标的只更新告警记录的最后触发时间。这样既不会错过问题又不至于被告警轰炸。这个逻辑在WaterQualityCheckService中实现大家在阅读源码时可以重点看一下是一个很好的工程化实践。6. 源码之外的个人实践心得和安全提醒整套项目从设计到部署我前前后后调了两周时间回头总结最想分享的一句话是水质检测系统的难点不在代码本身而在数据处理链路是否完整、稳定、可追溯。很多初学者拿到这类项目会急着写接口但真正重要的是把数据从采集、清洗、入库、分析、展示到告警的闭环先跑通再逐步完善细节。另外在使用阿里云数据库时有几个安全细节想特别提醒RDS的账号权限一定要按需分配不用、不给不要图省事用高权限账号跑业务代码。在RDS控制台开启“SSL加密”和“TDE透明数据加密”尤其是有敏感业务数据时。开启“白名单限制”只允许业务服务器的内网IP访问数据库不要用0.0.0.0/0放开所有来源。数据备份策略要配置好自动化备份建议每天一次并设置合理的保留天数。如果你打算在这个项目上继续扩展我建议可以往两个方向走一是接入真实的水质检测硬件设备把模拟数据发生器替换成MQTT或者CoAP协议接入整个系统的实战价值会立刻上一个台阶二是加入更完整的数据分析能力比如利用时序数据库存储历史数据或者用机器学习算法对水质变化趋势做预测这些方向都会让这套源码有很大的延展空间。最后说一个我自己在调试时养成的习惯在本地开发环境准备一套和线上一致的数据库表结构通过Flyway管住表结构变更这样代码提交、数据库表结构变更、环境部署可以保持同步避免出现“本地能跑线上报错”的尴尬情况。这套源码也是按照这个思路组织的拿到手之后你可以直接从建表脚本开始走起一点点把整套系统跑起来过程中遇到问题也可以对照我的排查笔记基本能覆盖八成以上的坑。本文还有配套的精品资源点击获取 基于Java和阿里云数据库的水质检测系统源码设计与部署实践
简介本资源是一套面向物联网与环境监测领域开发者的Java水质检测系统完整源码适用于高校课程设计、毕业设计及中小型智能水务项目快速原型开发。系统基于Java语言构建集成阿里云数据库与MySQL双数据源实现传感器数据采集、用户权限管理、实时数据显示及换水电机远程控制等核心功能解决水质监测场景中软硬件协同与云端数据交互的实际问题。压缩包共97个文件含27个Java业务逻辑文件、35个XML配置文件涵盖数据库连接与Spring框架配置、19个PNG界面资源图、3个Gradle构建脚本及配套JAR依赖包整体大小仅1.71MB结构清晰、模块解耦便于理解IoT系统分层架构与云边协同机制。目前已有328人学习下载开发者可直接导入IDE运行快速掌握JDBC数据库连接、NB-IoT设备通信、JavaFX/Swing界面开发及Gradle工程管理等关键技术实践路径。基于Java和阿里云数据库的水质检测系统整套源码设计与落地经验分享最近在整理一套基于Java后端与阿里云数据库的水质检测系统源码从需求梳理、库表设计、接口实现到上线部署几乎每个环节都踩了一遍坑。这个项目本身不算大但涉及物联网设备数据接入、实时检测、阈值告警、历史趋势分析这些常见业务非常适合Java初学者练手也适合想做智慧水务方向产品的同学参考。整套系统以Java为核心语言数据库用的是阿里云RDS MySQL前端配套一个简单的可视化大屏我把编码思路、关键实现和可复用的源码片段都放在了这篇文章里。不管你是刚学完Spring Boot想找个完整项目练手还是已经在做环保、水务相关系统想参考一下架构设计这篇文章都能帮到你。我会把项目从0到1的拆解过程、核心源码解释、以及在实际部署中遇到的问题排查方法全部写清楚尽量做到看完全文能直接照着落地。1. 项目整体设计与技术选型思路1.1 为什么用Java配合阿里云数据库来做水质检测水质检测系统最核心的链路是设备采集水质数据数据上传到服务端服务端落库然后做阈值判断、告警通知、历史查询。这套链路对后端的要求其实很常规但有几个硬性指标并发采集量要扛得住、数据不能丢、查询历史数据要快、后期要能平滑扩容。Java在这个领域依然是稳妥的首选。Spring Boot生态成熟社区资料多招人也好招而且Java的强类型和运行时稳定性在长时间运行的采集服务上比脚本语言更让人放心。另外一个重要考量是阿里云数据库RDS MySQL之所以选它而不自建数据库最大的原因是省心。自建MySQL意味着DBA、备份、高可用、监控全得自己搞而RDS直接把这些能力托管了自动备份、主备切换、慢查询分析这些开箱即用对中小团队来说性价比很高。实际上这套系统也可以部署到阿里云ECS上和RDS走内网连接既稳定又免流量费。如果你是个人学习或者演示环境ECS可以选最低配的2核4GRDS选最小的2核4G就够跑。1.2 系统整体功能模块划分项目功能拆成六个模块设备管理、数据采集、实时检测与存储、告警管理、统计分析与大屏展示、系统管理。每个模块之间边界清晰便于团队分工。设备管理模块负责维护监测点位的信息比如点位名称、所属区域、部署位置、在线状态。数据采集模块是连接设备和系统的桥梁在实际项目中通过MQTT协议接收硬件上传的数据在这套演示源码里则是用模拟数据发生器模拟硬件上报。实时检测与存储模块负责把上报的数据解析成一小时的检测记录同时根据各类指标的标准阈值判断是否超标。告警管理则在超标时生成一条告警记录并支持通过邮件或接口推送通知。统计分析模块提供按站点、按时间段的检测趋势查询大屏展示则是把这几部分数据汇总后通过图表呈现。1.3 技术栈清单和版本选型说明Java 8实际生产环境用Java 8仍然占大头稳定各种中间件兼容性也最好Spring Boot 2.7.x选这个版本是因为它稳定而且对应的Spring Cloud生态资料齐全MyBatis-Plus 3.5.x单表CRUD不用写SQL提升开发效率阿里云RDS MySQL 8.0阿里云物联网平台如果接真实硬件用这个做设备接入和消息流转ECharts 5.x前端大屏图表Redis可选用来做热点数据缓存比如最近的监测数据选型逻辑很简单尽量贴近真实企业项目的技术栈让看完源码的人直接能用这套技术栈去面试或工作。除了技术选型前端部分没有用太重的前端框架直接用了HTML Vue 3 CDN ECharts这样可以降低上手门槛让整个项目的重心放在Java后端代码上。2. 数据库设计与核心表结构2.1 数据表设计的核心思路水质检测系统虽然业务看起来简单但表结构设计需要注意时间和设备两个维度的数据组织。核心表分四张监测点表、水质指标定义表、水质检测数据表、告警记录表。如果需要完整的权限功能可以再加上用户表和角色表这里先用最简方案。重点说一下水质检测数据表这是整个系统数据量最大的一张表也是后续性能优化的重点。每台设备每小时上报一条记录一个点位一天就是24条如果有100个点位一年就是876000条。到了百万级数据量普通的查询已经开始变慢所以表设计的时候要优先考虑分表、索引和归档方案。2.2 建表语句和字段说明下面是核心表的建表SQL我用MySQL 8.0语法写的。-- 监测点表 CREATE TABLE monitor_point ( id bigint(20) NOT NULL AUTO_INCREMENT COMMENT 主键ID, point_code varchar(32) NOT NULL COMMENT 监测点编码, point_name varchar(64) NOT NULL COMMENT 监测点名称, location varchar(128) DEFAULT NULL COMMENT 所在位置, status tinyint(4) DEFAULT 1 COMMENT 状态 1-正常 0-停用, create_time datetime DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 更新时间, PRIMARY KEY (id), UNIQUE KEY uk_point_code (point_code) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT监测点信息表; -- 水质指标定义表 CREATE TABLE water_index ( id bigint(20) NOT NULL AUTO_INCREMENT, index_code varchar(32) NOT NULL COMMENT 指标编码, index_name varchar(64) NOT NULL COMMENT 指标名称, unit varchar(16) DEFAULT NULL COMMENT 单位, standard_max decimal(10,2) DEFAULT NULL COMMENT 标准上限值, standard_min decimal(10,2) DEFAULT NULL COMMENT 标准下限值, sort_order int(11) DEFAULT 0 COMMENT 排序, PRIMARY KEY (id), UNIQUE KEY uk_index_code (index_code) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT水质指标定义表; -- 水质检测数据表核心表 CREATE TABLE water_quality_data ( id bigint(20) NOT NULL AUTO_INCREMENT, point_code varchar(32) NOT NULL COMMENT 监测点编码, index_code varchar(32) NOT NULL COMMENT 指标编码, data_value decimal(10,2) NOT NULL COMMENT 检测数值, detect_time datetime NOT NULL COMMENT 检测时间, is_warning tinyint(4) DEFAULT 0 COMMENT 是否超标 1-是 0-否, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_point_time (point_code, detect_time), KEY idx_index_time (index_code, detect_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT水质检测数据表; -- 告警记录表 CREATE TABLE water_quality_warning ( id bigint(20) NOT NULL AUTO_INCREMENT, point_code varchar(32) NOT NULL COMMENT 监测点编码, index_code varchar(32) NOT NULL COMMENT 指标编码, data_value decimal(10,2) NOT NULL COMMENT 超标时的数值, standard_max decimal(10,2) DEFAULT NULL, standard_min decimal(10,2) DEFAULT NULL, warning_desc varchar(255) DEFAULT NULL COMMENT 告警描述, status tinyint(4) DEFAULT 0 COMMENT 处理状态 0-未处理 1-已处理, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_point_status (point_code, status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT水质告警记录表;2.3 索引设计和水质数据的存储优化水质检测数据表是典型的时间序列数据查询场景有两种一种是按点位查最近一段时间的数据一种是按指标查某个时间范围的数据。所以在索引设计上我建立了一个联合索引(point_code, detect_time)用于点位维度查询又建立了一个(index_code, detect_time)用于指标维度查询。看起来有点冗余但实际查询性能提升非常明显。这里要注意一个坑不要在detect_time上单独建索引单列索引无法同时满足两种查询场景。联合索引的顺序也很重要等值条件放前面、范围条件放后面。如果是真实生产环境几十个监测点跑几年以后数据量会到千万级单纯的索引优化已经不够了建议按月份做RANGE分区。举例来说把water_quality_data表按detect_time做月度分区这样老数据可以直接分区归档查询也能走分区裁剪速度提升非常明显。分区表在RDS上配置很方便语法如下ALTER TABLE water_quality_data PARTITION BY RANGE (TO_DAYS(detect_time)) ( PARTITION p202501 VALUES LESS THAN (TO_DAYS(2025-02-01)), PARTITION p202502 VALUES LESS THAN (TO_DAYS(2025-03-01)), PARTITION p202503 VALUES LESS THAN (TO_DAYS(2025-04-01)) );新增分区可以用ALTER TABLE water_quality_data ADD PARTITION动态加配合定时任务可以提前创建未来六个月的分区。3. 核心功能模块源码实现解析3.1 数据采集模拟数据发生器与真实设备接入的兼容设计这套源码里我设计了一个模拟数据发生器作用是模拟水质监测设备定时上报pH值、溶解氧、浊度、温度等指标。为什么用模拟数据因为真实的设备接入需要硬件配合对学习源码的人来说门槛太高。模拟数据发生器可以让系统在完全脱离硬件的情况下跑起来你只需要观察数据入库和控制台日志就能理解整个数据流转过程。模拟数据发生器的核心代码逻辑如下Component public class DataSimulator { private static final Random RANDOM new Random(); public MapString, Object generateData(String pointCode) { MapString, Object data new HashMap(); data.put(pointCode, pointCode); data.put(ph, round(6.5 RANDOM.nextDouble() * 2)); data.put(dissolvedOxygen, round(5 RANDOM.nextDouble() * 4)); data.put(turbidity, round(0.5 RANDOM.nextDouble() * 10)); data.put(temperature, round(10 RANDOM.nextDouble() * 20)); data.put(timestamp, LocalDateTime.now().format(DateTimeFormatter.ofPattern(yyyy-MM-dd HH:mm:ss))); return data; } private double round(double value) { return Math.round(value * 100.0) / 100.0; } }如果你要用真实硬件只需要把模拟器替换成一个MQTT客户端在KafkaListener或RabbitListener里接收上游系统推送过来的数据即可。为了兼容这两种场景我在接口设计上做了一层抽象统一入口是WaterDataCollectService模拟器和真实设备都实现同一个接口。3.2 数据落库与批量插入的性能优化水质检测数据写入的特点是单条数据量小但频率高。如果用MyBatis-Plus的save方法一条一条地插入到数据量大的时候数据库压力会非常大。我在源码里专门用了自定义的批量插入SQL配合MyBatis-Plus的insertBatchSomeColumn方法把一批数据一次插入。public interface WaterQualityDataMapper extends BaseMapperWaterQualityData { int insertBatchSomeColumn(Param(list) ListWaterQualityData list); } // 调用逻辑 public void saveBatchData(ListWaterQualityData list) { if (CollectionUtils.isEmpty(list)) { return; } // 分批插入每批500条 ListListWaterQualityData partition ListUtils.partition(list, 500); for (ListWaterQualityData batch : partition) { waterQualityDataMapper.insertBatchSomeColumn(batch); } }批量插入能大幅减少网络往返和事务开销实测下来500条一批、事务控制在1秒内提交性能是最稳妥的。需要提醒的是批量插入的事务不要选太大否则一旦失败回滚的数据太多影响其他写入任务。3.3 实时检测、超标判断与告警触发机制实时检测的逻辑是每次数据入库后立即和标准指标表里的上下限值做比对。如果超出范围就生成一条告警记录同时标记这条数据为超标状态。Service public class WaterQualityCheckService { Resource private WaterIndexMapper waterIndexMapper; Resource private WaterQualityDataMapper waterQualityDataMapper; Resource private WaterQualityWarningMapper warningMapper; public void checkAndWarn(WaterQualityData data) { WaterIndex index waterIndexMapper.selectByCode(data.getIndexCode()); if (index null) { return; } boolean over false; if (index.getStandardMax() ! null data.getDataValue().compareTo(index.getStandardMax()) 0) { over true; } if (index.getStandardMin() ! null data.getDataValue().compareTo(index.getStandardMin()) 0) { over true; } if (over) { data.setIsWarning(1); WaterQualityWarning warning new WaterQualityWarning(); warning.setPointCode(data.getPointCode()); warning.setIndexCode(data.getIndexCode()); warning.setDataValue(data.getDataValue()); warning.setStandardMax(index.getStandardMax()); warning.setStandardMin(index.getStandardMin()); warning.setWarningDesc(指标[ index.getIndexName() ]超标); warningMapper.insert(warning); // 发送通知邮件、短信、钉钉机器人等 notifyService.sendWarningMessage(warning); } waterQualityDataMapper.updateById(data); } }判断逻辑看起来简单但实际生产环境要注意一个问题超标的定义往往不是瞬时值超标而是连续几次采样都超标才算真超标否则传感器抖动就会造成误报。所以真实项目中会加一个“连续N次超标确认”的机制这里我在源码里留了扩展点你可以在checkAndWarn方法里统计最近几次记录再决定是否告警。3.4 水质大屏展示与统计查询实现统计查询的核心是分组聚合SQL这里我用MyBatis-Plus的Wrapper实现也可以直接用自定义SQL。SELECT point_code, index_code, AVG(data_value) AS avg_value, MAX(data_value) AS max_value, MIN(data_value) AS min_value FROM water_quality_data WHERE detect_time BETWEEN #{startTime} AND #{endTime} GROUP BY point_code, index_code这段SQL会返回某段时间内每个监测点、每项指标的平均值、最大值和最小值。前端大屏拿到这些数据后通过ECharts渲染折线图和柱状图非常直观。大屏页面我用的是Vue 3 ECharts代码结构简单清晰你只需要在HTML里引入ECharts的CDN然后向后端接口请求数据再渲染。4. 系统部署与阿里云数据库的接入配置4.1 阿里云RDS MySQL实例的创建和配置这一节我按实际操作步骤写出来方便你照着做。第一步登录阿里云控制台在RDS管理页面创建一个MySQL实例。选版本的时候推荐8.0因为8.0在JSON字段支持、窗口函数、性能上都要优于5.7。第二步设置数据库账号和密码。需要注意的是生产环境不要把数据库账号直接设为root建议建一个专用账号只授予业务库的增删改查权限。账号权限最小化这是云端数据库的基本安全习惯。第三步在“数据库管理”里创建数据库字符集选utf8mb4排序规则选utf8mb4_general_ci。utf8mb4能完整支持中文和emoji表情避免出现中文乱码问题。第四步把云服务器ECS的专有网络VPC和RDS实例的VPC设置为同一个这样程序里连接数据库时直接填内网地址。内网连接的好处是速度快、稳定还不占用公网流量。如果只是本地调试需要在RDS白名单里加上你本机的公网IP。4.2 Spring Boot项目配置阿里云RDS连接在application.yml里填写数据库连接信息注意加上时区参数防止时间慢8小时的问题。spring: datasource: url: jdbc:mysql://rm-xxxxxxx.mysql.rds.aliyuncs.com:3306/water_quality?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: water_app password: your_password driver-class-name: com.mysql.cj.jdbc.Driver mybatis-plus: configuration: map-underscore-to-camel-case: true global-config: db-config: id-type: auto配置中有一个细节很多人容易忽略serverTimezone必须设置为Asia/Shanghai否则JDBC驱动会默认使用UTC时区导致插入数据库的时间比实际时间少8小时。我刚开始部署的时候就是没加这个参数数据全部慢8小时排查了半天。连接池配置也建议显式写出来我用的是HikariCPSpring Boot默认连接池就是它性能很好参数建议如下spring: datasource: hikari: minimum-idle: 5 maximum-pool-size: 20 connection-timeout: 30000 idle-timeout: 600000最大连接数和最小空闲连接数要根据并发量来调整连接数不是越大越好太大反而会打满RDS的连接数上限。4.3 项目打包和在服务器上的常见部署方式项目用了Maven作为构建工具打包命令如下mvn clean package -DskipTests打包后在target目录下会生成一个water-quality-system.jar使用nohup命令直接启动nohup java -Xms512m -Xmx512m -jar water-quality-system.jar app.log 21 如果你有多台服务器需要部署可以再套一层Nginx做负载均衡但演示环境单机就够。需要提醒的是阿里云ECS的安全组里一定要放行后端服务端口比如8080端口否则外部请求访问不到接口。这个坑我在第一次部署时踩过启动日志显示正常但接口就是不通最后发现是安全组没有添加规则。5. 实际操作中遇到的高频问题和排查方法5.1 数据库连接超时与连接池连接失效系统运行一段时间之后有时会遇到Communications link failure异常。这通常是RDS MySQL的wait_timeout参数默认8小时连接池里超过8小时没有使用的连接被数据库服务端断开了。解决办法是配置HikariCP的连接存活检测同时在连接池中启用keepaliveTime。spring: datasource: hikari: connection-test-query: SELECT 1 keepalive-time: 300000 validation-timeout: 3000加上这些配置后HikariCP会定时检查连接是否可用不可用就销毁重建跑几天也不会再报连接超时。5.2 高并发写入时数据重复采集模拟数据发生器如果在定时任务创建时没有做好幂等控制很容易出现同一条监测数据被重复写入。原因通常是定时任务被重复触发或者Service方法没有加事务控制。我的处理方式是在数据表里加上唯一键(point_code, index_code, detect_time)这样就算代码里重复调用数据库也能兜底去重。这个方案简单粗暴但在生产环境很有效数据库层面拦截永远比应用层可靠。5.3 MyBatis-Plus批量插入不支持导致方法报错MyBatis-Plus内置的BaseMapper没有insertBatchSomeColumn这个方法这个方法是扩展包提供的需要引入专门的扩展包并在Mapper上继承InsertBatchSomeColumn接口。如果你发现调用报错多半是没加扩展依赖注意在pom.xml中加入对应依赖即可。5.4 大屏数据刷新慢如何优化如果大屏每次加载都要全量扫描water_quality_data表几百万条数据速度会很感人。我在项目里用了三层优化方案第一层SQL层优化。统计查询只聚合最近24小时或者最近7天的数据并且在WHERE条件里强制带上detect_time范围。第二层Redis缓存。热点统计结果缓存5分钟前端大屏轮询的时候直接打缓存数据库压力减少90%以上。第三层定时汇总表。如果数据量进一步增长可以每日凌晨跑定时任务把昨天的数据预聚合到一张汇总表大屏直接查汇总表毫秒级返回。5.5 告警信息太多淹没重要问题告警模块刚开发完联调时我发现只要有一次数据超标就会收到一堆重复告警。一个监测点的一个指标连续超标5次系统就发5条告警。处理办法是增加“告警聚合”逻辑同一个点位、同一个指标在30分钟内只发一条告警后续超标的只更新告警记录的最后触发时间。这样既不会错过问题又不至于被告警轰炸。这个逻辑在WaterQualityCheckService中实现大家在阅读源码时可以重点看一下是一个很好的工程化实践。6. 源码之外的个人实践心得和安全提醒整套项目从设计到部署我前前后后调了两周时间回头总结最想分享的一句话是水质检测系统的难点不在代码本身而在数据处理链路是否完整、稳定、可追溯。很多初学者拿到这类项目会急着写接口但真正重要的是把数据从采集、清洗、入库、分析、展示到告警的闭环先跑通再逐步完善细节。另外在使用阿里云数据库时有几个安全细节想特别提醒RDS的账号权限一定要按需分配不用、不给不要图省事用高权限账号跑业务代码。在RDS控制台开启“SSL加密”和“TDE透明数据加密”尤其是有敏感业务数据时。开启“白名单限制”只允许业务服务器的内网IP访问数据库不要用0.0.0.0/0放开所有来源。数据备份策略要配置好自动化备份建议每天一次并设置合理的保留天数。如果你打算在这个项目上继续扩展我建议可以往两个方向走一是接入真实的水质检测硬件设备把模拟数据发生器替换成MQTT或者CoAP协议接入整个系统的实战价值会立刻上一个台阶二是加入更完整的数据分析能力比如利用时序数据库存储历史数据或者用机器学习算法对水质变化趋势做预测这些方向都会让这套源码有很大的延展空间。最后说一个我自己在调试时养成的习惯在本地开发环境准备一套和线上一致的数据库表结构通过Flyway管住表结构变更这样代码提交、数据库表结构变更、环境部署可以保持同步避免出现“本地能跑线上报错”的尴尬情况。这套源码也是按照这个思路组织的拿到手之后你可以直接从建表脚本开始走起一点点把整套系统跑起来过程中遇到问题也可以对照我的排查笔记基本能覆盖八成以上的坑。本文还有配套的精品资源点击获取