Java家政服务平台实战：状态机与派单系统设计

简介这份资源是面向计算机专业学生与Java初学者的一份毕业设计论文文档主题为基于Java的家政服务平台的设计与实现适合正在准备课程设计、毕业设计或希望了解Spring Boot项目开发流程的读者参考。压缩包内共1个docx文件大小约1.07MB内容涵盖摘要、绪论、系统设计、功能实现与数据库设计等完整论文结构可直接用于学习论文写作规范与项目开发思路。平台围绕管理员、雇主、雇员三个角色展开管理员负责雇主管理、雇员管理、资料认证、服务项目、需求信息、服务预约、签订合同、雇主评价及留言板等模块雇主可发布需求、支付报酬并评价雇员雇员则可申请预约、提供服务功能划分清晰贴近真实业务场景。技术层面采用Spring Boot框架、跨平台Java语言与MySQL数据库兼顾开发效率与数据存储稳定性并涉及用户身份验证、访问控制与数据备份等安全措施。目前已有49人学习适合需要完整家政服务平台方案与论文参考的读者。1. 家政服务平台从需求到上线Java 技术栈选型与最小闭环打开招聘软件搜“家政服务平台”你会发现大量中小型公司正在把线下派单搬到线上但真正跑通全流程的系统并不多。这个标题讲的就是用 Java 技术栈从零搭一套能派单、能结算、能评价的家政服务平台。它解决的核心问题是把阿姨、客户、订单、资金四者之间的状态流转管清楚而不是做一个花哨的展示页。适合谁看有 Java 基础、想接私活或做毕设的开发者以及需要给传统家政公司做数字化改造的一线工程师。我见过太多项目死在“订单状态对不上”和“派单逻辑写死”上所以这篇笔记会按可复现的路径把表设计、接口幂等、状态机、实时通知这几个硬骨头逐个拆开。家政服务平台的设计和实现难点从来不在增删改查而在业务状态的一致性。2. 家政服务平台的数据模型从用户、阿姨到订单的状态流转2.1 四张核心表怎么切分才不打架家政业务里最容易翻车的地方是“一个人既是客户又是阿姨”或者“一个阿姨同时接多单导致时间冲突”。我一般会把用户体系拆成三张表user登录凭证、customer_profile客户地址、偏好、worker_profile阿姨技能、接单状态、健康证。订单表service_order单独一张里面冗余存客户 ID 和阿姨 ID避免多表 join 查历史订单时性能塌方。-- 阿姨接单状态表用状态字段控制并发 CREATE TABLE worker_profile ( worker_id BIGINT PRIMARY KEY, user_id BIGINT NOT NULL, skill_tags VARCHAR(255) COMMENT 保洁,月嫂,育儿嫂, work_status TINYINT DEFAULT 0 COMMENT 0空闲 1服务中 2休息, service_radius INT DEFAULT 5000 COMMENT 接单半径(米), UNIQUE KEY uk_user (user_id) ); -- 订单表状态机字段是关键 CREATE TABLE service_order ( order_id BIGINT PRIMARY KEY AUTO_INCREMENT, customer_id BIGINT NOT NULL, worker_id BIGINT DEFAULT NULL, service_type VARCHAR(64) NOT NULL, order_status TINYINT NOT NULL DEFAULT 10 COMMENT 10待派单 20已接单 30服务中 40待确认 50已完成 60已取消, appointment_time DATETIME NOT NULL, address_snapshot VARCHAR(512) NOT NULL, amount DECIMAL(10,2) NOT NULL, version INT DEFAULT 0 COMMENT 乐观锁版本号, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_worker_status (worker_id, order_status), KEY idx_customer (customer_id, create_time) );逻辑说明worker_profile里的work_status是派单时的第一道过滤只有空闲的阿姨才会进入候选池。service_order的order_status用数字编码而不是字符串是为了在索引和状态机判断时更快。version字段配合乐观锁防止两个运营同时给同一订单改状态。参数怎么改service_radius默认 5 公里如果做高端月嫂可以调到 20 公里order_status的编码间隔留 10方便以后插入“待支付”“已退款”等中间态。2.2 订单状态机别让 if-else 变成黑匣子状态流转是家政平台最玄学的地方。我见过一个系统阿姨点了“开始服务”客户那边还能点“取消订单”最后钱和工时全乱套。正确做法是定义一个状态机每个状态只允许特定角色触发特定事件。public enum OrderStatus { PENDING_DISPATCH(10, 待派单), ACCEPTED(20, 已接单), IN_SERVICE(30, 服务中), PENDING_CONFIRM(40, 待确认), COMPLETED(50, 已完成), CANCELLED(60, 已取消); private final int code; private final String desc; // 构造和 getter 省略 // 状态流转规则表当前状态 - 允许的下一个状态 private static final MapOrderStatus, SetOrderStatus TRANSITIONS Map.of( PENDING_DISPATCH, Set.of(ACCEPTED, CANCELLED), ACCEPTED, Set.of(IN_SERVICE, CANCELLED), IN_SERVICE, Set.of(PENDING_CONFIRM), PENDING_CONFIRM, Set.of(COMPLETED), COMPLETED, Set.of(), CANCELLED, Set.of() ); public static boolean canTransfer(OrderStatus from, OrderStatus to) { return TRANSITIONS.getOrDefault(from, Set.of()).contains(to); } }逻辑说明把流转规则集中在一个 Map 里而不是散落在各个 Service 方法中。每次改状态前调用canTransfer不通过就抛业务异常。参数说明PENDING_CONFIRM到COMPLETED只能由客户确认触发阿姨不能自己点完成这个权限控制在 Controller 层做角色校验。常见误用是直接在 SQL 里update order_status 50绕过状态机后期排查问题时根本不知道谁改的。2.3 派单算法的最小可用版本派单不需要一上来就搞机器学习。我一般先用“距离 评分 接单量”三个因子做加权排序跑通业务后再迭代。public ListWorkerProfile dispatchCandidates(Order order) { // 1. 查空闲且技能匹配的阿姨 ListWorkerProfile workers workerMapper.selectBySkillAndStatus( order.getServiceType(), 0); // 2. 过滤距离用 Haversine 公式算直线距离 workers workers.stream() .filter(w - distance(w.getLat(), w.getLng(), order.getLat(), order.getLng()) w.getServiceRadius()) .collect(Collectors.toList()); // 3. 加权排序距离权重 0.5评分权重 0.3今日接单量权重 0.2 workers.sort((a, b) - { double scoreA 0.5 * (1 - distanceRatio(a, order)) 0.3 * a.getRating() / 5.0 0.2 * (1 - a.getTodayOrders() / 5.0); double scoreB 0.5 * (1 - distanceRatio(b, order)) 0.3 * b.getRating() / 5.0 0.2 * (1 - b.getTodayOrders() / 5.0); return Double.compare(scoreB, scoreA); }); return workers; }逻辑说明selectBySkillAndStatus走idx_worker_status索引先粗筛再精排。距离用 Haversine 公式算不要用 MySQL 的ST_Distance因为阿姨和订单的经纬度是存在业务表里的跨表计算索引失效。参数说明权重 0.5/0.3/0.2 是拍脑袋定的上线后根据成单率调整todayOrders上限设 5超过 5 单的阿姨权重不再增加防止疲劳接单。这个版本能跑通但要注意如果候选阿姨为空订单要回落到“待派单”并触发运营告警不能静默失败。3. 用 Spring Boot 搭后端接口幂等、鉴权与实时通知3.1 下单接口的幂等设计别让用户点两下就出两个单家政平台的下单入口通常有两个小程序和 H5。用户网络卡顿时连点两次如果后端不做幂等就会生成两笔订单派单时阿姨收到两个一样的任务。常见做法是用 Redis 存 token但更轻量的方案是让前端传一个requestId后端用唯一索引兜底。PostMapping(/order/create) public ResultOrderVO createOrder(RequestBody Valid OrderCreateDTO dto, RequestHeader(X-Request-Id) String requestId) { // 1. 先查 requestId 是否已处理 String cacheKey order:req: requestId; Boolean absent redisTemplate.opsForValue() .setIfAbsent(cacheKey, 1, 10, TimeUnit.MINUTES); if (Boolean.FALSE.equals(absent)) { // 重复请求直接返回已创建的订单 return Result.success(orderService.getByRequestId(requestId)); } try { OrderVO vo orderService.create(dto, requestId); return Result.success(vo); } catch (DuplicateKeyException e) { // 数据库唯一索引兜底 return Result.success(orderService.getByRequestId(requestId)); } }逻辑说明setIfAbsent是 Redis 的原子操作只有第一个请求能设置成功。X-Request-Id由前端生成 UUID每次下单前刷新。参数说明过期时间设 10 分钟覆盖用户从点击到支付完成的窗口。数据库层还要在service_order表加request_id唯一索引防止 Redis 宕机时穿透。注意如果业务允许同一用户短时间内下多个不同服务的订单requestId必须每次不同不能复用。3.2 JWT 鉴权与角色隔离客户和阿姨看到的不是同一个世界家政平台有三类角色客户、阿姨、运营。用 Spring Security JWT 做无状态鉴权但要在过滤器里把角色写进AuthenticationController 层用PreAuthorize控制。Component public class JwtAuthFilter extends OncePerRequestFilter { Override protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain chain) throws IOException, ServletException { String token request.getHeader(Authorization); if (token ! null token.startsWith(Bearer )) { Claims claims jwtUtil.parse(token.substring(7)); String role claims.get(role, String.class); Long userId claims.get(userId, Long.class); // 把角色和用户 ID 放进 SecurityContext UsernamePasswordAuthenticationToken auth new UsernamePasswordAuthenticationToken(userId, null, List.of(new SimpleGrantedAuthority(ROLE_ role))); SecurityContextHolder.getContext().setAuthentication(auth); } chain.doFilter(request, response); } }逻辑说明JWT 里只放userId和role不放敏感信息。ROLE_前缀是 Spring Security 的约定。参数说明token 过期时间设 2 小时refresh token 设 7 天。常见坑是阿姨端和客户端共用同一个登录接口导致角色混淆正确做法是登录时根据user_type字段签发不同角色的 token。3.3 WebSocket 心跳机制让派单通知不丢派单通知如果用轮询阿姨端延迟高、耗电快。用 WebSocket 长连接但必须加心跳否则 NAT 超时后连接假死阿姨收不到新单。Component public class HeartbeatHandler extends TextWebSocketHandler { private static final long HEARTBEAT_INTERVAL 30_000; // 30秒 Override public void afterConnectionEstablished(WebSocketSession session) { // 把 session 按 workerId 存起来 Long workerId (Long) session.getAttributes().get(workerId); SessionManager.add(workerId, session); // 启动心跳检测 ScheduledFuture? future taskScheduler.scheduleAtFixedRate(() - { try { if (session.isOpen()) { session.sendMessage(new TextMessage(PING)); } } catch (IOException e) { SessionManager.remove(workerId); } }, HEARTBEAT_INTERVAL, HEARTBEAT_INTERVAL); session.getAttributes().put(heartbeat, future); } Override protected void handleTextMessage(WebSocketSession session, TextMessage message) { if (PONG.equals(message.getPayload())) { // 客户端响应心跳更新最后活跃时间 session.getAttributes().put(lastActive, System.currentTimeMillis()); } } }逻辑说明服务端每 30 秒发PING客户端回PONG。如果连续两次没收到PONG就关闭连接并清理 session。参数说明HEARTBEAT_INTERVAL设 30 秒是折中值太短耗电太长容易被 NAT 断开。注意WebSocket 集群部署时SessionManager 要用 Redis 做共享否则阿姨连到不同节点会收不到通知。4. 避坑与排查家政平台上线后最容易翻车的 5 个点4.1 阿姨接单后订单状态没变客户还能取消现象阿姨点了“接单”但客户端刷新后订单还是“待派单”客户点取消直接成功阿姨白跑一趟。 原因接单接口更新了worker_profile.work_status但没更新service_order.order_status两个操作不在同一个事务里。 解决把“改阿姨状态”和“改订单状态”放在同一个Transactional方法里并且用乐观锁version字段防止并发覆盖。上线前用 JMeter 模拟 50 个并发接单看是否有状态不一致。4.2 派单时查不到阿姨但数据库里明明有空闲的现象运营手动派单系统提示“无可用阿姨”但后台查work_status0的阿姨有十几个。 原因派单查询用了skill_tags LIKE %保洁%但阿姨的技能标签存的是“日常保洁”模糊匹配没命中。 解决技能标签用枚举编码存储比如SKILL_CLEAN1查询时用FIND_IN_SET或关联表。不要用字符串模糊匹配做核心业务查询。4.3 WebSocket 连接数一多就内存溢出现象上线一周后服务器内存持续上涨重启后恢复过几天又满。 原因SessionManager用HashMap存 session阿姨断开后没有移除导致 session 对象堆积。 解决在afterConnectionClosed里显式移除并且加一个定时任务清理超过 5 分钟没有心跳的 session。用ConcurrentHashMap替代HashMap。4.4 订单金额出现 0.01 元误差现象客户结算时显示 199.99阿姨端显示 200.00财务对账对不上。 原因金额字段用double存储浮点运算精度丢失。 解决数据库用DECIMAL(10,2)Java 用BigDecimal并且所有除法运算指定RoundingMode.HALF_UP。前后端传输金额统一用“分”为单位的长整型。4.5 运营改价后客户看到的还是原价现象运营在后台把订单金额从 200 改成 180客户小程序刷新后还是 200。 原因订单详情接口加了 Redis 缓存改价后没有删缓存。 解决改价操作后主动删除order:detail:{orderId}缓存或者用 Canal 监听 binlog 异步删。缓存过期时间设 5 分钟作为兜底。5. 进阶技巧用状态机引擎和对账任务把平台做稳5.1 把硬编码状态机换成 Spring StateMachine前面用 Map 手写的状态机在订单量少时够用但一旦要加“退款中”“申诉中”等状态Map 会变得很难维护。我后来把状态机迁移到 Spring StateMachine用配置类定义状态和事件。Configuration EnableStateMachineFactory public class OrderStateMachineConfig extends StateMachineConfigurerAdapterOrderStatus, OrderEvent { Override public void configure(StateMachineTransitionConfigurerOrderStatus, OrderEvent transitions) throws Exception { transitions .withExternal().source(OrderStatus.PENDING_DISPATCH).target(OrderStatus.ACCEPTED).event(OrderEvent.WORKER_ACCEPT) .and() .withExternal().source(OrderStatus.ACCEPTED).target(OrderStatus.IN_SERVICE).event(OrderEvent.START_SERVICE) .and() .withExternal().source(OrderStatus.IN_SERVICE).target(OrderStatus.PENDING_CONFIRM).event(OrderEvent.FINISH_SERVICE) .and() .withExternal().source(OrderStatus.PENDING_CONFIRM).target(OrderStatus.COMPLETED).event(OrderEvent.CUSTOMER_CONFIRM); } }逻辑说明withExternal定义外部流转每个事件只能从指定源状态触发。参数说明EnableStateMachineFactory让每个订单可以创建独立的状态机实例避免状态串扰。迁移后新增状态只需要改配置类不用动业务代码。注意StateMachine 默认是内存态重启后丢失需要配合StateMachinePersist把当前状态存回数据库。5.2 每日对账任务把资金差错挡在用户投诉之前家政平台涉及预付款和结算必须每天跑对账。我一般用 Spring Schedule 在凌晨 2 点执行比对service_order的amount和支付流水表的total_amount。Scheduled(cron 0 0 2 * * ?) public void dailyReconcile() { LocalDate yesterday LocalDate.now().minusDays(1); // 1. 查昨日已完成订单的总金额 BigDecimal orderTotal orderMapper.sumCompletedAmount(yesterday); // 2. 查支付流水总金额 BigDecimal payTotal payMapper.sumSuccessAmount(yesterday); // 3. 比对不一致就告警 if (orderTotal.compareTo(payTotal) ! 0) { alertService.send(对账不平订单 orderTotal 支付 payTotal); } }逻辑说明sumCompletedAmount只统计order_status50的订单sumSuccessAmount只统计支付状态为成功的流水。参数说明cron 表达式设凌晨 2 点避开业务高峰。如果金额差异超过 1 元除了告警还要自动生成差异明细表方便财务人工核查。这个任务跑了一个月后我们提前发现了 3 笔因网络超时导致的“支付成功但订单未完成”的异常。5.3 一个让我少加三天班的习惯每次上线新状态或新接口前我会先写一个“状态流转测试用例”把所有非法流转都跑一遍。比如“已完成”的订单不能取消“待派单”的订单不能直接完成。这个习惯帮我挡掉了至少五次线上事故。家政平台的设计和实现说到底就是把状态和钱管清楚其他都是锦上添花。希望帮到你。本文还有配套的精品资源点击获取