Java智慧养老平台代码实战：工单闭环、Redis防抖与高并发优化

简介：一套基于SpringBoot的智慧养老平台完整Java源码，面向计算机、电子信息工程等专业学习者，适合作为毕业设计、课程设计及期末大作业。系统采用B/S架构与MVC模式，整合SpringBoot、Mybatis、Ajax、Vue等技术栈，覆盖前端交互、后端服务与数据库设计，可在Windows/Mac环境下配合JDK1.8、Mysql5.7、Maven3.6快速运行。压缩包共包含950个文件，总体积17.83MB，以Java源文件（195个）、Vue组件（65个）、JavaScript脚本（164个）、HTML页面（69个）及CSS样式（53个）为主，并附带数据库脚本、配置文件与启动脚本，目录划分明确便于学习和二次开发。已有335人学习下载，所有源码经过严格测试，可直接部署使用。这套代码能帮助读者快速理解SpringBoot实际项目的完整结构，掌握前后端分离开发与养老服务业务逻辑的实现思路，是提升工程实践能力的实用参考。

1. Java智慧养老平台代码的核心是三条数据闭环，不是一个后台管理系统

一位养老机构的负责人在项目启动会上说，平台要能看大屏、能看监控、能派单、家属能收到推送。听起来是标准的管理系统，可一旦设备数据接入，问题立刻就变了：老人离床报警和SOS按钮可能一秒内上报多次，护工抢单并发来了，家属通知要等所有渠道都发送完再返回。Java智慧养老平台代码真正的复杂度不在增删改查，而在「老人轨迹、服务工单、健康时序」这三条闭环数据如何被正确建模和处理。

如果只把平台当作按角色分菜单的CRUD，大概率会在联调阶段被真实的时序数据和高频上报打穿。这篇博客不贴完整源码，而是把做这个标题最常见的落地路径讲清楚：从ER设计、工单状态机，到设备上报的防抖和并发通知，再落到部署和压测参数。适合正在设计或维护养老类平台后端的Java工程师，也适合团队里负责技术选型的人用来校对方案的边界。

2. Java智慧养老平台代码的选型与ER设计，先定表再写逻辑

2.1 单体优先：Spring Boot 3 + MySQL 8 足够支撑两千张床位

养老平台的并发量本质上是低频写、中频读：几千名老人、几百名护工、每天几万条健康指标。作为技术负责人，我一般不会为了这种体量引入微服务和消息中间件，因为事务的复杂度远大于流量的复杂度。一个工单从创建到结算涉及订单、护工、回访、结算四个表，用单体里的本地事务和数据库锁就能解决；拆成微服务反而要处理分布式事务和最终一致性，是给自己挖坑。

建议技术栈固定为 Java 17、Spring Boot 3.x、MyBatis-Plus、MySQL 8、Redis 7。前端用 Vue3 或其他管理端框架都行，和本标题关系不大，不在这里展开。依赖坐标用一个最小骨架：

<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>3.2.5</version> </parent> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-spring-boot3-starter</artifactId> <version>3.5.7</version> </dependency> <dependency> <groupId>com.mysql</groupId> <artifactId>mysql-connector-j</artifactId> <scope>runtime</scope> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId> </dependency> </dependencies>

MyBatis-Plus 在 Java 智慧养老平台代码里主要价值是单表 CRUD 不用写 SQL，工单查询这种多条件场景仍需要手写 XML。Redis 的用途是防抖、计数和分布式锁，不是为了缓存热数据，健康数据本身更适合查 MySQL 的分表。选型时把这些定位说清楚，后面写代码就不会纠结技术栈是否够强。

2.2 六张核心表：把老人、护工、服务单、健康指标分开建模

设计数据库时最容易犯的错是给平台建一张巨大的「用户表」，把老人、家属、护工、管理员全塞进去。正确做法是把组织身份和业务数据分开，老人是档案主数据，护工是服务资源，家属只作为关联通知对象。下面的表结构是 Java 智慧养老平台代码里相对通用的起步形态：

其中 service_order 是核心，它把老人的服务需求和护工的执行动作串起来；order_track 是工单状态机的审计日志，每次状态变更都插入一条，方便追溯责任。health_metric 和 sos_alert 是设备侧的写模型，特点是写入量大、几乎不更新、按时间范围查询，这类表在后续章节里再做按月分表处理，这里先保留逻辑外键。

elderly_id 处不做物理外键，理由是业务上需要支持批量导入和归档，物理外键在大批量写入时会拖慢性能。一致性交给应用层保障，也就是在创建工单时显式校验老人和护工的存在性。这个取舍在 Java 智慧养老平台代码场景里很常见，数据库只需要承担存储和索引，不需要承担业务规则。

2.3 用 Java 工具自动生成数据库设计文档，避免文档和表结构脱节

项目迭代到第二个月，数据库设计文档往往就没人维护了。常见做法是用开源工具从数据库元数据自动生成 Markdown 或 HTML 文档。这里推荐 screw（数据库表结构文档生成工具），它支持 MySQL、PostgreSQL，能直接生成包含表注释、列注释、索引信息的文档。在测试环境执行一次，输出产物丢到项目 docs 目录里，配合接口文档就能覆盖大部分交接场景。

// 直接用 main 方法触发，无需启动 Spring 容器 public class DbDocGenerator { public static void main(String[] args) { String url = "jdbc:mysql://localhost:3306/elderly_care?useUnicode=true&characterEncoding=utf8"; Configuration config = Configuration.builder() .driver("com.mysql.cj.jdbc.Driver") .url(url) .username("root") .password("root") .build(); new DocumentGenerate(config, new ExecutePropel( ProcessConfig.builder() .designatedTableName(Arrays.asList("elderly_member", "service_order")) .build() ), new MarkdownBuilder()).execute(); } }

这段代码里的designatedTableName参数用来指定要导出的表，不传则导出全部表。用 MarkdownBuilder 生成的文档适合放 Git 仓库评审；如果在交付时要给客户看，换成 HtmlBuilder 会更美观。关键点是把这个工具接进 CI 流程或至少放进项目根目录，每次表结构变更顺手跑一次，才能避免文档过期。

3. 工单闭环是Java智慧养老平台代码的核心业务，状态机和动态SQL要一起设计

3.1 用枚举和事件驱动实现工单状态流转，别用 if else 散落一地

工单是这个平台里业务规则最密集的地方：待派单、已派单、服务中、待回访、已完成、已取消。每个状态能做什么操作、谁能操作、状态怎么流转，必须收敛到一处，否则上线三个月后会变成维护灾难。用枚举实现状态机，把当前状态、目标状态和动作绑定在事务方法里，是常见的可靠做法：

public enum OrderStatus { PENDING_ASSIGN(0, "待派单"), ASSIGNED(1, "已派单"), SERVING(2, "服务中"), PENDING_REVIEW(3, "待回访"), COMPLETED(4, "已完成"), CANCELED(5, "已取消"); private final int code; private final String desc; public boolean canTransferTo(OrderStatus target) { // 定义允许的流转路径，防住非法跳转 return switch (this) { case PENDING_ASSIGN -> target == ASSIGNED || target == CANCELED; case ASSIGNED -> target == SERVING || target == CANCELED; case SERVING -> target == PENDING_REVIEW || target == CANCELED; case PENDING_REVIEW -> target == COMPLETED; default -> false; }; } }

这种写法把「谁能干」的校验放在 Service 层调用canTransferTo，职责清晰且方便写单元测试。switch表达式中没有 case 的状态一律不接收流转，包括已完成状态不允许再回退。八股文里常考的状态模式在这里的真正意义不是套设计模式，而是把规则集中，让新同学改需求时不用满项目找if。

3.2 派单接口的事务与防重：@Transactional 要和分布式锁配合

派单是高频操作，护工在 App 抢单时多个请求可能同时命中同一个工单。单纯用数据库乐观锁可以防超卖，但 Java 智慧养老平台代码里还可能涉及调第三方短信和生成派单记录，这些动作不适合只靠UPDATE count = count - 1去约束。推荐组合方案：Redis 分布式锁控制并发，数据库状态字段做兜底，事务包裹业务写操作：

@Transactional(rollbackFor = Exception.class) public boolean dispatchOrder(Long orderId, Long caregiverId) { String lockKey = "lock:order:" + orderId; boolean locked = stringRedisTemplate.opsForValue() .setIfAbsent(lockKey, "1", Duration.ofSeconds(10)); if (!locked) { throw new BizException("工单正在处理中，请勿重复操作"); } try { // 数据库兜底：必须是待派单状态才允许派单 int updated = orderMapper.casDispatch(orderId, caregiverId); if (updated == 0) { throw new BizException("工单状态已变化，派单失败"); } orderTrackMapper.insert(new OrderTrack(orderId, OrderStatus.PENDING_ASSIGN, OrderStatus.ASSIGNED, caregiverId)); return true; } finally { stringRedisTemplate.delete(lockKey); } }

setIfAbsent是加锁的原子操作，设置 10 秒过期防止锁未释放导致死锁。这里有个细节：业务执行时间超过锁过期时间时 A 线程的锁会被 B 线程覆盖，所以锁过期时间要远大于业务耗时。casDispatch是自定义 SQL，核心是UPDATE service_order SET status=1 WHERE id=? AND status=0，影响行数为 0 时说明并发下状态已被其他请求更新，这种写法即使 Redis 锁失效，数据库条件更新也会拦截重复派单。

3.3 Java对MySQL的搜索语句：动态SQL处理多条件筛选

平台管理后台的工单查询往往要同时支持老人姓名、护工姓名、时间范围、状态多个筛选条件，用 Java 的 if 拼 SQL 很容易造成 SQL 注入或语法错误。标准做法是 MyBatis XML 里的动态标签，把条件判断交给框架处理：

<select id="searchOrders" resultType="com.demo.order.vo.OrderVO"> SELECT o.id, o.order_no, e.name AS elderly_name, c.name AS caregiver_name, o.status, o.created_at FROM service_order o LEFT JOIN elderly_member e ON o.elderly_id = e.id LEFT JOIN caregiver c ON o.caregiver_id = c.id <where> <if test="param.status != null"> AND o.status = #{param.status} </if> <if test="param.elderlyName != null and param.elderlyName != ''"> AND e.name LIKE CONCAT('%', #{param.elderlyName}, '%') </if> <if test="param.startTime != null"> AND o.created_at &gt;= #{param.startTime} </if> <if test="param.endTime != null"> AND o.created_at &lt;= #{param.endTime} </if> </where> ORDER BY o.created_at DESC LIMIT #{param.offset}, #{param.pageSize} </select>

<where>标签会自动去掉第一个条件前多余的 AND，不需要在业务代码里手动处理。LIKE 查询的CONCAT拼接能避免#{param.elderlyName}直接拼进字符串带来的注入风险。pageSize 建议限制最大值 100，防止有人调LIMIT 999999把数据库拖垮。查询返回的 VO 不直接映射实体，因为需要关联老人和护工的姓名字段。

4. 健康设备上报与SOS呼救的并发处理，Redisincrement的坑要提前排

4.1 健康指标按月分表，MyBatis-Plus 动态表名实现

health_metric 表每天写入量取决于设备接入量，一张床的智能床垫每 5 分钟上报一条体动和心率数据，2000 张床一天就是约 60 万条。单表超过几百万行后，按时间范围查询会明显变慢，所以要在设计初期就按月分表，表名类似health_metric_202506。用 MyBatis-Plus 的DynamicTableNameInnerInterceptor可以按当前月份自动路由，不需要在业务代码里写死表名：

@Configuration public class MybatisPlusConfig { @Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); DynamicTableNameInnerInterceptor dynamic = new DynamicTableNameInnerInterceptor(); dynamic.setTableNameHandler((sql, tableName) -> { if ("health_metric".equals(tableName)) { return tableName + "_" + LocalDate.now().format(DateTimeFormatter.ofPattern("yyyyMM")); } return tableName; }); interceptor.addInnerInterceptor(dynamic); return interceptor; } }

这里的拦截器会在执行 SQL 前把表名替换为带后缀的物理表。需要注意，这个处理器是应用级全局的，对于需要跨月查询报表的场景要再手写 SQL 查多张表做 UNION ALL。分表后，建表语句里的索引也要跟着调整，推荐联合索引(elderly_id, collected_at)，按老人查询时间范围的频率远高于跨所有老人查询。

设备插入采用批量写入优化，MyBatis-Plus 的saveBatch默认分批提交，建议每批 500 条，过高会导致单条 SQL 超过 MySQL 的max_allowed_packet。写入失败时不要整批重试，先按设备 ID 分组找出失败的数据再补写，避免重复消费时把完整批次再次提交。

4.2 用 Redis 做SOS防抖和计数，increment的类型坑要处理

SOS 呼救按钮一旦按下，设备往往会连续上报多次，如果每次都触发一次工单创建和家属短信，后果是灾难性的。常规方案是给同一老人设置一个 10 秒的防抖标记，标记存在时直接丢弃，同时用计数器记录上报次数作为冗余追踪信息：

public boolean tryAcquireSos(Long elderlyId) { String dedupKey = "sos:dedup:" + elderlyId; Boolean success = stringRedisTemplate.opsForValue() .setIfAbsent(dedupKey, "1", Duration.ofSeconds(10)); if (Boolean.TRUE.equals(success)) { // 首次上报，计数归 1 stringRedisTemplate.opsForValue().set("sos:cnt:" + elderlyId, "1"); return true; } // 10 秒内重复上报，计数加一 try { stringRedisTemplate.opsForValue() .increment("sos:cnt:" + elderlyId); } catch (Exception ex) { // 计数失败只记录日志，不影响防抖主流程 log.warn("increment sos count failed: {}", ex.getMessage()); } return false; }

这里必须用stringRedisTemplate而不是默认的redisTemplate，否则很容易踩到increment()报错的坑：使用 JDK 序列化器时，存进去的字符串读到的是 byte[]，increment()执行时报ClassCastException或提示value is not an integer or out of range。用StringRedisTemplate，key 和 value 都是字符串，Redis 服务端会把字符串当整数处理，避免序列化器带来的类型问题。

防抖期间 S* 设备仍旧上报，这些重复数据会记到sos_alert表里的一个字段，用于后续判断误报率。如果平台要求每次呼救都生成轨迹，可以再单独维护 append-only 的原始事件表，但不要用同一张表同时承接防抖判断和事件归档。

4.3 家属通知要等待所有渠道返回，CompletableFuture 控制超时与失败

呼救确认后，系统需要同时发短信给家属、推送站内信给管理员、可能还要调第三方电话通知。这个场景对应 Java 八股里常问的「多个线程等待都完成后汇总」，实现时用好CompletableFuture：

public void notifyFamilyAfterSos(SosAlert alert) { ExecutorService pool = new ThreadPoolExecutor( 4, 8, 60L, TimeUnit.SECONDS, new ArrayBlockingQueue<>(50), new ThreadPoolExecutor.CallerRunsPolicy()); CompletableFuture<Void> smsFuture = CompletableFuture.runAsync( () -> smsClient.send(alert.getFamilyPhone(), alert.getMessage()), pool); CompletableFuture<Void> appFuture = CompletableFuture.runAsync( () -> appPushClient.send(alert.getOperatorId()), pool); try { CompletableFuture.allOf(smsFuture, appFuture).get(5, TimeUnit.SECONDS); } catch (TimeoutException e) { // 超时也要记录，短信可能已发送成功，需要做补偿 smsFuture.exceptionally(ex -> { log.error("sms send failed: {}", ex.getMessage()); return null; }); } catch (Exception e) { Thread.currentThread().interrupt(); } finally { pool.shutdown(); } }

allOf().get(5, TimeUnit.SECONDS)是关键：它等待所有异步任务完成，但不会一直阻塞。如果短信通道在 5 秒内没返回，主流程继续向下执行，不需要把家属通知的失败拖到整个呼救流程里。线程池必须自定义，不能用Executors.newFixedThreadPool，因为无界队列在高并发告警时会把内存撑满；CallerRunsPolicy拒绝策略在队列满时让调用线程执行任务，保证通知不丢失，但会影响呼救接口的返回速度，需要压测时观察。

5. 上线前用三项检查压住Java智慧养老平台代码的稳定性

5.1 一台 4C8G 服务器上的 JVM 和连接池参数

平台部署初期一台 4C8G 的云主机足够支撑 300 人同时在线操作。JVM 参数怎么配是热词里的高频问题，直接给一套可用的组合，堆大小设置 4GB 避免操作系统内存不足，垃圾回收器在 Java 17 上直接用默认的 G1 即可，不必再调 CMS：

JAVA_OPTS="-Xms4g -Xmx4g -XX:MaxMetaspaceSize=512m \ -XX:+UseG1GC -XX:MaxGCPauseMillis=200 \ -Xlog:gc*:/data/logs/gc.log:time,uptime,level,tags"

-Xms4g和-Xmx4g保持一致，避免运行期堆扩容触发 Full GC。G1 的MaxGCPauseMillis设置到 200 毫秒就够了，设太短会导致 G1 频繁调整年轻代大小，反而影响吞吐。MySQL 连接池配合 HikariCP，maximum-pool-size设为 20 足够，一个 4C8G 实例上连接数过高只会增加上下文切换开销。

5.2 慢SQL排查先看这张表，再用 Arthas热修现场问题

后台上线后最容易出现的卡顿都集中在工单列表和健康数据查询。先用 MySQL 自带的慢查询日志定位具体语句，再针对执行计划里 type 为 ALL 的字段补索引：

SHOW VARIABLES LIKE 'slow_query_log%'; SHOW GLOBAL STATUS LIKE 'Slow_queries'; EXPLAIN SELECT * FROM service_order WHERE elderly_id = 10086 AND status = 1 ORDER BY created_at DESC LIMIT 20;

EXPLAIN 返回结果里key为 NULL 时，说明这条 SQL 没走任何索引，考虑建(elderly_id, status, created_at)的联合索引。线上环境如果某个接口逻辑出现问题时，用 Arthas 的trace命令跟踪方法调用耗时比反复加日志再发布高效得多，以下是常用的排查命令：

java -jar arthas-boot.jar # 选择目标 Java 进程后在 Arthas 命令行执行： watch com.demo.order.service.ServiceOrderService dispatchOrder '{params, returnObj}' -x 2 trace com.demo.order.service.ServiceOrderService dispatchOrder '#cost > 200'

watch查看入参和返回值，trace把所有子调用耗时打印出来，#cost > 200只显示超过 200 毫秒的调用，适合在生产环境低流量时临时开启。注意这些命令本身有性能开销，排查完要立刻stop退出，不能长时间挂着。

5.3 用 wrk 压测派单接口，验证吞吐和防重逻辑

压测目标是确认派单接口在 100 并发下不报错，并且同一个工单不会被重复派发。wrk 是 Linux 上常用的压测工具，一条命令就能看透接口表现：

wrk -t8 -c100 -d30s -s post.lua http://127.0.0.1:8080/api/order/dispatch

post.lua 里用wrk.request()构造 POST 请求，把固定 orderId 放进 body。观察两个核心指标：Requests/sec 是否达到预期，以及非 200 响应比例。由于业务里同时有 Redis 锁和casDispatch的数据库条件更新兜底，即使压测请求重复轰炸同一个工单，失败率也应收敛到 0。压测时注意观察Redis connected clients和 MySQL 连接池使用率，连接数打满通常是连接池配置过小的信号。

整个平台上线前，按这三项检查走一遍，Java智慧养老平台代码的核心链路才算站得住。

本文还有配套的精品资源，点击获取