前阵子有个在那边的亲戚跟我吐槽想找个靠谱的保洁阿姨翻了半天本地生活App不是距离太远就是时间对不上最后还得靠熟人介绍。我当时就琢磨与其等大平台把资源下沉不如自己动手做一个面向本地市场的家政服务平台。于是就有了基于 Spring Boot 的莆田家政服务平台这个项目。这篇文章不是讲某家公司怎么做的而是记录我实地从零搭一个家政O2O平台的全过程重点涉及技师匹配、订单状态流转、支付对账这些最让人头疼的部分。如果你打算做本地生活服务类的项目或者正在用 Spring Boot 做带定位和支付的业务系统这篇应该能帮你少走几段弯路。1. 为什么是莆田本地家政平台项目源头与需求边界1.1 本地生活服务需要的不是大而全而是及时响应先说说这个项目是怎么来的。我整理了很多本地生活类的需求后发现有三个共性痛点第一用户想找的是“现在就能来”的人而不是预约到三天后第二服务者和用户之间的地理位置距离直接决定了成交率第三价格敏感度很高平台如果抽成太狠技师根本不愿意入驻。莆田这个城市规模不算大服务范围基本可以覆盖主城区和周边几个区县本地化的调度反而比一线城市更友好。一个熟练技师从接单到上门骑电动车大概二三十分钟就能搞定。所以这个平台的核心指标不是用户量有多大而是“下单后多久能匹配到人”以及“匹配成功之后有多少比例真正完成了服务”。基于这样的前提我只保留四个最核心的流程用户下单、技师抢单和指派、上门服务、验收结算。社区团购、会员积分、社交裂变这些当时统统不做先把订单闭环跑通。边界越清晰后续开发时就不会被各种临时想法带偏。1.2 需求拆解从用户、技师、平台三个视角看问题我把角色分成三类每个角色关注的东西完全不同。用户端关心的是能不能快速找到附近的服务者、价格是否透明、上门是否准时、出了问题能不能退款。技师端关心的是单量是否充足、距离是否太远、平台抽成多少、用户评价是否公正。平台端关心的是订单如何高效匹配、服务如何验收、资金如何安全结算、异常订单如何介入处理。这三类需求在系统设计上是互相约束的。比如用户想要“快速匹配”如果简单做成“谁手快谁抢单”那服务能力弱的技师也会抢到单服务质量不可控。所以我在抢单机制上做了限制技师只能看到自己技能标签匹配且距离在阈值范围内的订单这样用户匹配到的可能性更高技师也不会空跑太远。需求的优先级排序也很有意思。看起来最重要的是派单算法但实际做下来真正决定平台生死的其实是订单状态的准确性和资金安全。因为派单失误最多是用户体验差但支付和退款如果出了岔子那就是真金白银的纠纷。所以我在前期需求文档里把“状态流转严谨性”列为最高优先级比界面效果要重要得多。2. 工程结构设计与模块边界单体应用也能组织得明明白白2.1 按业务域划分 module而不是按 controller、service、dao 切包很多 Spring Boot 项目一上来就建controller、service、mapper三层目录然后所有业务的类都往里塞。前几个月看着还行一旦订单、用户、支付这些逻辑混在一起改一个需求就要动好几个不相关的文件。我在这个项目里换了种方式按业务域拆 Maven module。homeclean-platform ├── homeclean-common // 通用工具、统一返回结果、异常处理 ├── homeclean-user // 用户端注册、登录、地址管理 ├── homeclean-worker // 技师端入驻、技能标签、服务状态 ├── homeclean-order // 订单创建、匹配、状态流转 ├── homeclean-payment // 支付渠道对接、回调处理、退款 ├── homeclean-evaluation // 评价订单完成后的互评 └── homeclean-admin // 管理后台人工介入和配置这样做最直接的好处是依赖方向是单向的。order模块可以依赖user和worker的接口但user绝不会反过来依赖order。各模块之间通过内部接口调用底层的数据表也做了归属隔离不允许跨模块直接操作对方的表。团队协作的时候每个人只要盯着自己负责的模块就行合并代码时冲突概率明显下降。如果你是一个人维护整个项目可能觉得模块化反而啰嗦。但我的经验是哪怕单兵作战这种拆分也能逼着你把接口想清楚。比如技师模块提供给订单模块的就只有“查询可用技师”这个接口内部是查缓存还是查数据库订单模块完全不用关心。这层抽象的收益在后期写单元测试时体现得最明显。2.2 三个贯穿全局的基础组件鉴权、日志与消息推送业务模块之外有三套基础能力是绕不开的。第一是鉴权。我直接用了 Spring Security 加 JWT 的组合用户和技师共用同一套登录认证逻辑只是角色标识不同。JWT 的有效期设置了两层短期 token 两小时刷新用的 refresh token 七天。家政场景里用户可能很久才打开一次App如果 token 频繁过期体验会非常折腾所以我把刷新有效期拉长到三十天。第二是操作日志。所有涉及订单金额、状态变更的操作都必须写入操作日志表记录操作人、操作前状态、操作后状态、变更原因。这个表在日常没什么存在感但一旦用户投诉“我没取消订单为什么退款了”你查日志就能还原完整链路。日志的写入用异步方式避免影响主流程性能。第三是消息推送。技师端接单提醒用的不是短信而是服务端通过 WebSocket 推送实时消息同时落一条站内通知。因为技师抢单的场景对实时性要求很高轮询的方式延迟太明显。我单独做了一个轻量的推送模块支持连接管理和消息广播没有引入重量级的推送框架够用就好。3. 附近技师匹配与抢单池设计平台最核心的计算逻辑3.1 算距离的方案选择从经纬度球面距离到 MySQL 空间索引匹配技师的第一步是把“三公里内的保洁员”这个条件落到实际代码里。最开始我直接用 MySQL 的ST_Distance_Sphere函数计算并排序代码写起来倒是简单SELECT *, ST_Distance_Sphere( POINT(worker.lng, worker.lat), POINT(#{lng}, #{lat}) ) AS distance FROM worker WHERE skill_tag cleaning HAVING distance 3000 ORDER BY distance ASC LIMIT 20;这个方案在数据量只有几百个技师时毫无压力查询基本都在几十毫秒内完成。但考虑到后续如果接入的技师数量增长或者用户频繁搜索全表扫描加实时计算会越来越吃力。所以我做了第二版方案把技师位置缓存到 Redis用有序集合按经纬度分桶存储查询时直接算候选集合再在应用层过滤距离范围。实际操作中Redis 的方案有点过度设计因为单城市几千技师根本不需要额外的中间件。最后我采用的是一套折中方案用 Geohash 把技师位置编码成字符串存储到单独的位置表并建联合索引。查询时先根据用户位置的 Geohash 前缀匹配附近几个网格内的技师缩小候选集。再用ST_Distance_Sphere计算精确距离并过滤排序。Geohash 精度选择了个长度为 6 的编码对应大约 1 公里左右的网格粒度。加上前后左右相邻网格内的技师基本能覆盖三到五公里的范围。这套方案不需要引入额外的搜索引擎MySQL 本身就能跑得很舒服。3.2 抢单和派单结合的分配策略匹配方式上我参考了很多平台的通用做法最终做成了“抢单为主、平台指派兜底”的混合模式。新订单进入待接单池系统通过消息推送给符合技能和距离条件的技师。前 60 秒技师可主动抢单同一订单同时只能被一个技师锁定。60 秒内无人接单系统自动从候选技师里选一个评分高、被拒次数少的人指派。被指派的技师可以拒绝拒绝后顺延给下一位最多轮转三次。为什么不全自动派单因为家政服务的体验很大程度上依赖技师的主观能动性强制派单容易造成服务抵触。但完全放养也不行如果高峰期单量多总会有单子在池子里没人接。混合策略既能保留技师的自主权又能保证订单不被长时间搁置。订单池的存取用了 Redis 的列表结构每个技能类目对应一个队列。技师抢单时通过 Lua 脚本保证原子性防止两个技师同时锁定同一个订单。local orderKey KEYS[1] local workerId ARGV[1] if redis.call(get, orderKey) false then redis.call(set, orderKey, workerId) redis.call(expire, orderKey, 60) return 1 end return 0这段极简的 Lua 脚本就保证了“先到先得”比用分布式锁还要轻量。具体使用时会对订单号做 hash同一个订单一定只落在一个 Redis slot 上配合单命令执行整个脚本原子性没有问题。4. 订单状态机与支付流程的安全边界每一步都想清楚谁能做、何时能做4.1 订单状态定义的粒度不能太粗也不能碎到难维护我见过很多项目把订单状态只定义成待支付、已支付、已完成三个导致中途各种异常情况没法表达。家政服务订单有预约时间、上门、服务中、验收等多个阶段状态粒度太粗运营后台根本没法准确判断问题出在哪个环节。这个项目最终定义的订单状态如下状态含义允许的下一个状态PENDING_PAY待支付已取消、已支付PAID已支付待匹配已匹配MATCHED已匹配技师待上门、已取消ON_SERVICE服务中待验收PENDING_VERIFY待验收已完成、退款申请COMPLETED已完成已评价CANCELED已取消无REFUNDING退款中已退款REFUNDED已退款无每个状态的迁移都对应一个明确的前置条件和操作人。比如从MATCHED到ON_SERVICE必须是技师点击“开始服务”并且用户已支付。从PENDING_VERIFY到COMPLETED用户确认后触发同时系统自动生成一笔待结算记录。状态迁移的代码里只允许调用统一的状态变更方法不允许直接改状态字段这样方便在方法内部统一写入操作日志和触发后续流程。4.2 支付回调的幂等处理与对账机制支付模块是家政平台里最容易出 SQ 事故的地方。支付渠道的回调通知是异步的且可能重复推送如果没有做好幂等用户可能被重复扣款。我在支付回调处理上做了两层防护。第一层是回调处理接口内的幂等判断根据平台的业务订单号查询流水状态如果流水已经是SUCCESS直接返回成功给支付渠道不再执行后续逻辑。第二层是数据库层面的并发控制支付流水表里对业务订单号加了唯一索引重复插入时直接报错兜住极端并发场景。更关键的是对账。每天凌晨两点跑一次定时任务拉取支付渠道前一日的账单明细和我们本地的支付流水表做比对。比对的字段包括订单号、金额、渠道流水号、交易时间。对不上的记录进异常表由人工在管理后台逐条处理。退款流程我也做了独立的状态机。用户申请退款后如果技师未开始服务全额原路退回如果已开始服务但用户不满意需要上传凭证由平台客服介入判断部分退款还是全额退款。退款本身也是异步回调确认同样要做幂等处理。支付这块看似是最简单的“调用完等结果”实际做下来才发现细节远比想象中多。如果没有对账任务偶尔一次回调丢失就会造成长期挂账用户来投诉时又查不出所以然非常被动。5. 数据表设计与并发防护防重复、防超卖、防资损5.1 订单和支付相关表的设计思路表结构设计我是按业务域分开规划的先看订单域的核心表CREATE TABLE order_info ( id bigint NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 业务订单号, user_id bigint NOT NULL, worker_id bigint DEFAULT NULL COMMENT 技师ID, service_type varchar(32) NOT NULL, amount decimal(10,2) NOT NULL, address varchar(255) NOT NULL, lng decimal(10,6) NOT NULL, lat decimal(10,6) NOT NULL, appoint_time datetime DEFAULT NULL, status varchar(32) NOT NULL, version int NOT NULL DEFAULT 0, created_at datetime NOT NULL, updated_at datetime NOT NULL, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;order_no的生成用“日期 服务类型 随机串”的方式不在数据库里做自增便于在日志和客服沟通中直接识别订单类型。金额字段用decimal(10,2)绝不用 float 或 double避免精度问题。支付流水表单独放在支付模块字段除了基本的订单号、渠道流水号还包含一个notify_status字段标记回调状态以及一个channel_return_code保存渠道返回原文。技师履约表记录每一笔订单的服务过程实际上门时间、完成时间、用户验收照片的路径、用户和技师的互评内容。这样后续如果产生纠纷有完整的证据链可以追溯。5.2 乐观锁与唯一索引如何拦住并发问题家政订单量虽然不像电商那样每秒几万笔但并发问题依然存在而且一旦发生就是资损级别的。我主要防了三种情况。第一种情况是用户重复点击支付按钮。这个在客户端可以限制按钮但服务端不能依赖客户端。支付流水表上对order_no加了唯一索引并发插入时只有一个能成功另一个直接报DuplicateKeyException捕获后返回“请勿重复提交”。第二种情况是同一个技师同时被多个订单锁定。抢单场景里技师手速很快可能同时点了两个订单。我在技师接单时用乐观锁控制更新技师当前订单状态前先检查状态是否还是IDLEint updated workerMapper.updateStatusIfIdle( workerId, WorkerStatus.BUSY, WorkerStatus.IDLE); if (updated 0) { throw new BizException(技师忙请选择其他技师); }这种方案比先查询再更新的“检查再执行”模式可靠得多因为数据库的 update 自带行锁并发下只有一个请求能改成功。第三种情况是支付回调与用户取消订单同时发生。用户点了取消取消接口还没执行完支付回调就到了。处理方法是取消订单前检查支付流水状态如果发现渠道已经回调成功就把用户请求转成退款流程而不是强制取消。订单状态机的每个迁移都做好前置校验就不会出现“订单已取消但钱却扣了”的矛盾状态。6. 从本地联调到上线的真实问题那些不跑一遍根本发现不了的坑6.1 本地环境跑得通部署到服务器却问题百出开发阶段一切都挺顺结果部署到测试服务器后先冒出来三个问题都是环境相关的。第一个是时区问题。本地 Mac 和服务器默认时区不一致导致订单创建时间和支付回调时间的偏差最严重时差八个小时。后来在数据库连接串上显式指定serverTimezoneAsia/Shanghai并且在所有接口返回时间戳的地方统一按用户端时区解析才彻底解决。第二个是文件上传路径的问题。用户验收照片上传到本地磁盘但服务器是多实例部署照片传到 A 实例用户请求时负载均衡路由到 B 实例图片就找不到了。后面改成把上传文件存到可公用的分布式存储应用服务器只保留临时目录不再作为持久化存储。第三个是内存溢出。第一次压测时并发量稍微上来一点系统频繁 Full GC。排查发现是查询附近技师时默认每次把数据库里所有技师位置都加载到内存再计算数据量小看着没事实际测试就崩了。改成 Geohash 前缀过滤后内存占用直接降下来了。6.2 模拟真实场景的联调比单元测试更能发现问题单元测试能验证方法的逻辑正确性但验证不了整个订单链路的一致性。我搭了一个简易的联调环境用脚本模拟用户下单、技师接单、服务完成、用户验收的全流程并把订单状态打印出来人工核对。第一次联调就发现了一个问题用户支付成功后订单状态被正确置为PAID但技师端却没有收到推送消息。排查后定位到是我在订单状态变更时发消息用的是同步调用支付回调里事务还没提交消息就已经发出去了技师端点进详情页时查不到订单自然就觉得是异常。解决办法是把消息发送放到事务提交后的TransactionSynchronizationManager回调里执行保证订单数据已经可见了再发消息。联调时还发现一个体验问题用户下单时填写的地址是文本描述比如“荔城区某小区 3 栋 205”这个地址无法直接转成经纬度。我接入了一个地理编码服务在下单时就把文本地址转成经纬度存到订单表里匹配技师和计算距离都直接用经纬度。如果转换失败就把地址退给用户重新填写不让脏数据进入后续流程。6.3 运营后台的人工介入能力必须提前规划平台上线后一定会遇到系统自动处理不了的边缘情况。比如用户反馈技师一直没上门但系统里订单状态还是MATCHED很可能是技师端 App 崩了根本没有触发状态变更。这时候运营后台必须能手动完成状态修正。我做了一套人工操作能力运营人员可以把指定订单的状态手动置为任意合法状态但每一次操作都要填写原因并且系统自动记录操作人和前后状态。这个能力看起来简单却是平台运行的兜底保障。没有它一旦出现客户端异常订单就会卡死在中间状态用户和技师两头扯皮。运营后台还加了一个实时大屏展示当前待接单数量、正在服务中的订单量、平均匹配耗时等指标。这些数字平时看也许没感觉但在大促或推广活动期间能直观反映系统压力方便提前扩容或降级派单策略。写在最后的一点心得项目的核心代码量不算大真正花时间的是想清楚状态流转和边界场景。对我个人而言最大的收获不是学会了多少新框架而是意识到对于家政这类本地生活服务技术上的难点从来不是炫酷的算法而是把订单、支付、履约这些基础流程的严谨性做到极致。如果你也要做类似项目我的建议是先画一遍完整的订单状态图把所有异常分支都列出来再开始写代码。状态图越细后面改代码的次数就越少。支付回调的幂等和数据库的唯一索引再怎么强调都不为过这是资损的最后一道防线。定位匹配的部分从数据量规模出发选择方案不要在几百个技师时就直接上分布式方案先做简单方案等瓶颈真正出现时再优化完全来得及。
前阵子有个在那边的亲戚跟我吐槽想找个靠谱的保洁阿姨翻了半天本地生活App不是距离太远就是时间对不上最后还得靠熟人介绍。我当时就琢磨与其等大平台把资源下沉不如自己动手做一个面向本地市场的家政服务平台。于是就有了基于 Spring Boot 的莆田家政服务平台这个项目。这篇文章不是讲某家公司怎么做的而是记录我实地从零搭一个家政O2O平台的全过程重点涉及技师匹配、订单状态流转、支付对账这些最让人头疼的部分。如果你打算做本地生活服务类的项目或者正在用 Spring Boot 做带定位和支付的业务系统这篇应该能帮你少走几段弯路。1. 为什么是莆田本地家政平台项目源头与需求边界1.1 本地生活服务需要的不是大而全而是及时响应先说说这个项目是怎么来的。我整理了很多本地生活类的需求后发现有三个共性痛点第一用户想找的是“现在就能来”的人而不是预约到三天后第二服务者和用户之间的地理位置距离直接决定了成交率第三价格敏感度很高平台如果抽成太狠技师根本不愿意入驻。莆田这个城市规模不算大服务范围基本可以覆盖主城区和周边几个区县本地化的调度反而比一线城市更友好。一个熟练技师从接单到上门骑电动车大概二三十分钟就能搞定。所以这个平台的核心指标不是用户量有多大而是“下单后多久能匹配到人”以及“匹配成功之后有多少比例真正完成了服务”。基于这样的前提我只保留四个最核心的流程用户下单、技师抢单和指派、上门服务、验收结算。社区团购、会员积分、社交裂变这些当时统统不做先把订单闭环跑通。边界越清晰后续开发时就不会被各种临时想法带偏。1.2 需求拆解从用户、技师、平台三个视角看问题我把角色分成三类每个角色关注的东西完全不同。用户端关心的是能不能快速找到附近的服务者、价格是否透明、上门是否准时、出了问题能不能退款。技师端关心的是单量是否充足、距离是否太远、平台抽成多少、用户评价是否公正。平台端关心的是订单如何高效匹配、服务如何验收、资金如何安全结算、异常订单如何介入处理。这三类需求在系统设计上是互相约束的。比如用户想要“快速匹配”如果简单做成“谁手快谁抢单”那服务能力弱的技师也会抢到单服务质量不可控。所以我在抢单机制上做了限制技师只能看到自己技能标签匹配且距离在阈值范围内的订单这样用户匹配到的可能性更高技师也不会空跑太远。需求的优先级排序也很有意思。看起来最重要的是派单算法但实际做下来真正决定平台生死的其实是订单状态的准确性和资金安全。因为派单失误最多是用户体验差但支付和退款如果出了岔子那就是真金白银的纠纷。所以我在前期需求文档里把“状态流转严谨性”列为最高优先级比界面效果要重要得多。2. 工程结构设计与模块边界单体应用也能组织得明明白白2.1 按业务域划分 module而不是按 controller、service、dao 切包很多 Spring Boot 项目一上来就建controller、service、mapper三层目录然后所有业务的类都往里塞。前几个月看着还行一旦订单、用户、支付这些逻辑混在一起改一个需求就要动好几个不相关的文件。我在这个项目里换了种方式按业务域拆 Maven module。homeclean-platform ├── homeclean-common // 通用工具、统一返回结果、异常处理 ├── homeclean-user // 用户端注册、登录、地址管理 ├── homeclean-worker // 技师端入驻、技能标签、服务状态 ├── homeclean-order // 订单创建、匹配、状态流转 ├── homeclean-payment // 支付渠道对接、回调处理、退款 ├── homeclean-evaluation // 评价订单完成后的互评 └── homeclean-admin // 管理后台人工介入和配置这样做最直接的好处是依赖方向是单向的。order模块可以依赖user和worker的接口但user绝不会反过来依赖order。各模块之间通过内部接口调用底层的数据表也做了归属隔离不允许跨模块直接操作对方的表。团队协作的时候每个人只要盯着自己负责的模块就行合并代码时冲突概率明显下降。如果你是一个人维护整个项目可能觉得模块化反而啰嗦。但我的经验是哪怕单兵作战这种拆分也能逼着你把接口想清楚。比如技师模块提供给订单模块的就只有“查询可用技师”这个接口内部是查缓存还是查数据库订单模块完全不用关心。这层抽象的收益在后期写单元测试时体现得最明显。2.2 三个贯穿全局的基础组件鉴权、日志与消息推送业务模块之外有三套基础能力是绕不开的。第一是鉴权。我直接用了 Spring Security 加 JWT 的组合用户和技师共用同一套登录认证逻辑只是角色标识不同。JWT 的有效期设置了两层短期 token 两小时刷新用的 refresh token 七天。家政场景里用户可能很久才打开一次App如果 token 频繁过期体验会非常折腾所以我把刷新有效期拉长到三十天。第二是操作日志。所有涉及订单金额、状态变更的操作都必须写入操作日志表记录操作人、操作前状态、操作后状态、变更原因。这个表在日常没什么存在感但一旦用户投诉“我没取消订单为什么退款了”你查日志就能还原完整链路。日志的写入用异步方式避免影响主流程性能。第三是消息推送。技师端接单提醒用的不是短信而是服务端通过 WebSocket 推送实时消息同时落一条站内通知。因为技师抢单的场景对实时性要求很高轮询的方式延迟太明显。我单独做了一个轻量的推送模块支持连接管理和消息广播没有引入重量级的推送框架够用就好。3. 附近技师匹配与抢单池设计平台最核心的计算逻辑3.1 算距离的方案选择从经纬度球面距离到 MySQL 空间索引匹配技师的第一步是把“三公里内的保洁员”这个条件落到实际代码里。最开始我直接用 MySQL 的ST_Distance_Sphere函数计算并排序代码写起来倒是简单SELECT *, ST_Distance_Sphere( POINT(worker.lng, worker.lat), POINT(#{lng}, #{lat}) ) AS distance FROM worker WHERE skill_tag cleaning HAVING distance 3000 ORDER BY distance ASC LIMIT 20;这个方案在数据量只有几百个技师时毫无压力查询基本都在几十毫秒内完成。但考虑到后续如果接入的技师数量增长或者用户频繁搜索全表扫描加实时计算会越来越吃力。所以我做了第二版方案把技师位置缓存到 Redis用有序集合按经纬度分桶存储查询时直接算候选集合再在应用层过滤距离范围。实际操作中Redis 的方案有点过度设计因为单城市几千技师根本不需要额外的中间件。最后我采用的是一套折中方案用 Geohash 把技师位置编码成字符串存储到单独的位置表并建联合索引。查询时先根据用户位置的 Geohash 前缀匹配附近几个网格内的技师缩小候选集。再用ST_Distance_Sphere计算精确距离并过滤排序。Geohash 精度选择了个长度为 6 的编码对应大约 1 公里左右的网格粒度。加上前后左右相邻网格内的技师基本能覆盖三到五公里的范围。这套方案不需要引入额外的搜索引擎MySQL 本身就能跑得很舒服。3.2 抢单和派单结合的分配策略匹配方式上我参考了很多平台的通用做法最终做成了“抢单为主、平台指派兜底”的混合模式。新订单进入待接单池系统通过消息推送给符合技能和距离条件的技师。前 60 秒技师可主动抢单同一订单同时只能被一个技师锁定。60 秒内无人接单系统自动从候选技师里选一个评分高、被拒次数少的人指派。被指派的技师可以拒绝拒绝后顺延给下一位最多轮转三次。为什么不全自动派单因为家政服务的体验很大程度上依赖技师的主观能动性强制派单容易造成服务抵触。但完全放养也不行如果高峰期单量多总会有单子在池子里没人接。混合策略既能保留技师的自主权又能保证订单不被长时间搁置。订单池的存取用了 Redis 的列表结构每个技能类目对应一个队列。技师抢单时通过 Lua 脚本保证原子性防止两个技师同时锁定同一个订单。local orderKey KEYS[1] local workerId ARGV[1] if redis.call(get, orderKey) false then redis.call(set, orderKey, workerId) redis.call(expire, orderKey, 60) return 1 end return 0这段极简的 Lua 脚本就保证了“先到先得”比用分布式锁还要轻量。具体使用时会对订单号做 hash同一个订单一定只落在一个 Redis slot 上配合单命令执行整个脚本原子性没有问题。4. 订单状态机与支付流程的安全边界每一步都想清楚谁能做、何时能做4.1 订单状态定义的粒度不能太粗也不能碎到难维护我见过很多项目把订单状态只定义成待支付、已支付、已完成三个导致中途各种异常情况没法表达。家政服务订单有预约时间、上门、服务中、验收等多个阶段状态粒度太粗运营后台根本没法准确判断问题出在哪个环节。这个项目最终定义的订单状态如下状态含义允许的下一个状态PENDING_PAY待支付已取消、已支付PAID已支付待匹配已匹配MATCHED已匹配技师待上门、已取消ON_SERVICE服务中待验收PENDING_VERIFY待验收已完成、退款申请COMPLETED已完成已评价CANCELED已取消无REFUNDING退款中已退款REFUNDED已退款无每个状态的迁移都对应一个明确的前置条件和操作人。比如从MATCHED到ON_SERVICE必须是技师点击“开始服务”并且用户已支付。从PENDING_VERIFY到COMPLETED用户确认后触发同时系统自动生成一笔待结算记录。状态迁移的代码里只允许调用统一的状态变更方法不允许直接改状态字段这样方便在方法内部统一写入操作日志和触发后续流程。4.2 支付回调的幂等处理与对账机制支付模块是家政平台里最容易出 SQ 事故的地方。支付渠道的回调通知是异步的且可能重复推送如果没有做好幂等用户可能被重复扣款。我在支付回调处理上做了两层防护。第一层是回调处理接口内的幂等判断根据平台的业务订单号查询流水状态如果流水已经是SUCCESS直接返回成功给支付渠道不再执行后续逻辑。第二层是数据库层面的并发控制支付流水表里对业务订单号加了唯一索引重复插入时直接报错兜住极端并发场景。更关键的是对账。每天凌晨两点跑一次定时任务拉取支付渠道前一日的账单明细和我们本地的支付流水表做比对。比对的字段包括订单号、金额、渠道流水号、交易时间。对不上的记录进异常表由人工在管理后台逐条处理。退款流程我也做了独立的状态机。用户申请退款后如果技师未开始服务全额原路退回如果已开始服务但用户不满意需要上传凭证由平台客服介入判断部分退款还是全额退款。退款本身也是异步回调确认同样要做幂等处理。支付这块看似是最简单的“调用完等结果”实际做下来才发现细节远比想象中多。如果没有对账任务偶尔一次回调丢失就会造成长期挂账用户来投诉时又查不出所以然非常被动。5. 数据表设计与并发防护防重复、防超卖、防资损5.1 订单和支付相关表的设计思路表结构设计我是按业务域分开规划的先看订单域的核心表CREATE TABLE order_info ( id bigint NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 业务订单号, user_id bigint NOT NULL, worker_id bigint DEFAULT NULL COMMENT 技师ID, service_type varchar(32) NOT NULL, amount decimal(10,2) NOT NULL, address varchar(255) NOT NULL, lng decimal(10,6) NOT NULL, lat decimal(10,6) NOT NULL, appoint_time datetime DEFAULT NULL, status varchar(32) NOT NULL, version int NOT NULL DEFAULT 0, created_at datetime NOT NULL, updated_at datetime NOT NULL, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;order_no的生成用“日期 服务类型 随机串”的方式不在数据库里做自增便于在日志和客服沟通中直接识别订单类型。金额字段用decimal(10,2)绝不用 float 或 double避免精度问题。支付流水表单独放在支付模块字段除了基本的订单号、渠道流水号还包含一个notify_status字段标记回调状态以及一个channel_return_code保存渠道返回原文。技师履约表记录每一笔订单的服务过程实际上门时间、完成时间、用户验收照片的路径、用户和技师的互评内容。这样后续如果产生纠纷有完整的证据链可以追溯。5.2 乐观锁与唯一索引如何拦住并发问题家政订单量虽然不像电商那样每秒几万笔但并发问题依然存在而且一旦发生就是资损级别的。我主要防了三种情况。第一种情况是用户重复点击支付按钮。这个在客户端可以限制按钮但服务端不能依赖客户端。支付流水表上对order_no加了唯一索引并发插入时只有一个能成功另一个直接报DuplicateKeyException捕获后返回“请勿重复提交”。第二种情况是同一个技师同时被多个订单锁定。抢单场景里技师手速很快可能同时点了两个订单。我在技师接单时用乐观锁控制更新技师当前订单状态前先检查状态是否还是IDLEint updated workerMapper.updateStatusIfIdle( workerId, WorkerStatus.BUSY, WorkerStatus.IDLE); if (updated 0) { throw new BizException(技师忙请选择其他技师); }这种方案比先查询再更新的“检查再执行”模式可靠得多因为数据库的 update 自带行锁并发下只有一个请求能改成功。第三种情况是支付回调与用户取消订单同时发生。用户点了取消取消接口还没执行完支付回调就到了。处理方法是取消订单前检查支付流水状态如果发现渠道已经回调成功就把用户请求转成退款流程而不是强制取消。订单状态机的每个迁移都做好前置校验就不会出现“订单已取消但钱却扣了”的矛盾状态。6. 从本地联调到上线的真实问题那些不跑一遍根本发现不了的坑6.1 本地环境跑得通部署到服务器却问题百出开发阶段一切都挺顺结果部署到测试服务器后先冒出来三个问题都是环境相关的。第一个是时区问题。本地 Mac 和服务器默认时区不一致导致订单创建时间和支付回调时间的偏差最严重时差八个小时。后来在数据库连接串上显式指定serverTimezoneAsia/Shanghai并且在所有接口返回时间戳的地方统一按用户端时区解析才彻底解决。第二个是文件上传路径的问题。用户验收照片上传到本地磁盘但服务器是多实例部署照片传到 A 实例用户请求时负载均衡路由到 B 实例图片就找不到了。后面改成把上传文件存到可公用的分布式存储应用服务器只保留临时目录不再作为持久化存储。第三个是内存溢出。第一次压测时并发量稍微上来一点系统频繁 Full GC。排查发现是查询附近技师时默认每次把数据库里所有技师位置都加载到内存再计算数据量小看着没事实际测试就崩了。改成 Geohash 前缀过滤后内存占用直接降下来了。6.2 模拟真实场景的联调比单元测试更能发现问题单元测试能验证方法的逻辑正确性但验证不了整个订单链路的一致性。我搭了一个简易的联调环境用脚本模拟用户下单、技师接单、服务完成、用户验收的全流程并把订单状态打印出来人工核对。第一次联调就发现了一个问题用户支付成功后订单状态被正确置为PAID但技师端却没有收到推送消息。排查后定位到是我在订单状态变更时发消息用的是同步调用支付回调里事务还没提交消息就已经发出去了技师端点进详情页时查不到订单自然就觉得是异常。解决办法是把消息发送放到事务提交后的TransactionSynchronizationManager回调里执行保证订单数据已经可见了再发消息。联调时还发现一个体验问题用户下单时填写的地址是文本描述比如“荔城区某小区 3 栋 205”这个地址无法直接转成经纬度。我接入了一个地理编码服务在下单时就把文本地址转成经纬度存到订单表里匹配技师和计算距离都直接用经纬度。如果转换失败就把地址退给用户重新填写不让脏数据进入后续流程。6.3 运营后台的人工介入能力必须提前规划平台上线后一定会遇到系统自动处理不了的边缘情况。比如用户反馈技师一直没上门但系统里订单状态还是MATCHED很可能是技师端 App 崩了根本没有触发状态变更。这时候运营后台必须能手动完成状态修正。我做了一套人工操作能力运营人员可以把指定订单的状态手动置为任意合法状态但每一次操作都要填写原因并且系统自动记录操作人和前后状态。这个能力看起来简单却是平台运行的兜底保障。没有它一旦出现客户端异常订单就会卡死在中间状态用户和技师两头扯皮。运营后台还加了一个实时大屏展示当前待接单数量、正在服务中的订单量、平均匹配耗时等指标。这些数字平时看也许没感觉但在大促或推广活动期间能直观反映系统压力方便提前扩容或降级派单策略。写在最后的一点心得项目的核心代码量不算大真正花时间的是想清楚状态流转和边界场景。对我个人而言最大的收获不是学会了多少新框架而是意识到对于家政这类本地生活服务技术上的难点从来不是炫酷的算法而是把订单、支付、履约这些基础流程的严谨性做到极致。如果你也要做类似项目我的建议是先画一遍完整的订单状态图把所有异常分支都列出来再开始写代码。状态图越细后面改代码的次数就越少。支付回调的幂等和数据库的唯一索引再怎么强调都不为过这是资损的最后一道防线。定位匹配的部分从数据量规模出发选择方案不要在几百个技师时就直接上分布式方案先做简单方案等瓶颈真正出现时再优化完全来得及。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
