各位面试官好，特别荣幸能跟您详细聊我参与的云岚到家项目 —— 这是个家政服务 O2O 平台，核心是把个人服务人员和家政公司的资源整合起来，用户通过线上预约就能享受上门服务。项目分四个端：用户端小程序、服务端 APP、机构端 PC 和运营管理端 PC，我从需求分析到开发落地全程跟着，尤其是核心模块的设计和优化，对整体流程特别熟。接下来我按模块跟您说说具体情况，您要是有哪个细节想深入问，我再补充。
一、服务管理模块 —— 我主导了核心表设计和性能优化
这个模块是平台的 “地基”，用户能看到什么服务、多少钱，全靠它。我当时主要负责两件事：一是核心表结构的设计，二是解决用户端查服务慢的问题。
业务上其实不复杂：运营先在管理端建服务分类，比如 “日常保洁”“家电维修”，再在分类下做具体服务项 —— 像 “3 小时基础保洁”，得写清楚服务内容（擦玻璃、拖地面这些）、标准时长，还有定价规则。这里我特意设计了 “服务 - 区域 - 价格” 的关联逻辑，因为家政太吃地域了，比如北京朝阳的 3 小时保洁卖 198，海淀就得 218，而且只在开通服务的区域显示。运营选区域是用可视化地图勾的，勾完系统会自动同步到用户端，不用手动传。
技术上，我设计了四张核心表：service_category（服务分类）、service_item（服务项）、service_area（服务区域），还有个 service_item_area_price，专门关联服务项和区域的价格 —— 这张表我用了联合主键，就是服务项 ID 加区域 ID，这样能完美解决 “一个服务在多区域多价格” 的问题。
不过最开始用户端查服务列表特别慢，要 300 多毫秒，高峰期还容易卡。我就做了三级缓存优化：本地用 Caffeine 存热门分类（10 分钟过期），Redis 存各区域的服务列表（按 “区域 ID + 分类 ID” 当 key，30 分钟更一次），数据库还加了 area_id+category_id+status 的联合索引。改完之后，接口响应稳定在 50 毫秒内，每秒能抗 2000 多查询，用户端刷首页快多了。
当时还遇到个小问题：区域层级太多，省、市、区、街道一层层勾，运营人员嫌麻烦。我就加了两个功能：一个是 Excel 批量导入，给个模板让他们填区域编码，后端用 POI 解析了直接关联服务项，配置效率提了 80%；另一个是树状选择组件，勾父区域自动带中子区域，不用重复点了。
二、下单支付模块 —— 我参与需求梳理和预创建机制设计
这个模块是用户从 “看服务” 到 “定服务” 的关键，我主要跟产品经理一起梳理需求，还设计了订单预创建的逻辑，避免超售。
流程上，用户打开小程序会自动定位（也能手动切区域），前端从 Redis 拉当前区域的服务列表；选好服务项点 “预约”，就得填预约时间（精确到 30 分钟，比如 09:00-12:00）、地址，还有附加需求 —— 比如 “家里有宠物”“要擦玻璃”。填完提交时，系统不会直接创订单，而是先 “预创建”：生成个唯一订单号（日期 + 随机数 + 用户 ID 后 4 位），先查服务在这个区域能不能用、这个时段还有没有名额（用 Redis 计数器判断），然后锁定 15 分钟库存 —— 防止用户下单了不付钱，占着名额。
预创建过了，用户才能付 money。我们对接的是微信支付，前端调 SDK 生成预付单，用户付完款，微信会回调我们的接口。我当时特意做了双重校验：用订单号 + 微信支付单号确认，防止重复回调；还加了本地消息表记回调状态，万一微信推送失败，能保证最终订单状态是对的。要是 15 分钟没付款，定时任务会自动解锁库存，订单标成 “已取消”。
高峰期的时候出过个问题：周末上午下单的人多，Redis 锁库存偶尔超时，用户下不了单。我就把库存校验和订单预创建拆成异步，用线程池并行处理；还把 Redis 集群从 3 节点扩到 6 节点，开了读写分离，读请求走从节点 —— 最后下单成功率从 95% 提到了 99.8%，基本没再出现过超时。
三、抢单模块 —— 我主导架构设计，解决高并发抢单冲突
这个模块是连接用户订单和服务人员的 “桥梁”，最核心的问题是：高并发下不能让同一个订单被多个人抢走。我当时全程主导这个模块的技术方案。
业务流程很直观：服务人员得先在 APP 里设置 —— 开抢单开关、选接单范围（比如 5 公里内）、绑服务技能（比如只会保洁就选保洁），这些配置会存到 Redis，30 分钟更一次。用户订单变成 “待接单” 后，MQ 会触发推送任务：先提订单的服务类型、经纬度，再从 Redis 里筛符合条件的人（技能对得上、范围覆盖、时段有空），按 “距离由近及远” 排前 20 个，推抢单通知（APP 推送 + 短信）。
服务人员点 “抢单” 后，后端要做几道校验：是不是在线、有没有接满单；然后用 Redis 的分布式锁锁定订单 ——key 是 order_id，过期时间 5 秒，防止锁太久。拿到锁之后，还得再查一次订单状态是不是 “待接单”，没问题才标成 “待服务”，发通知给用户。
最头疼的是极端情况：100 人抢同一个单，Redis 锁释放后还有请求进来，导致重复抢单。我最后用了两个方案：一是引入 ZooKeeper 做降级，Redis 出问题时自动切 ZooKeeper 的锁；二是在订单表加 version 字段做乐观锁，更新时校验 version，不一样就驳回。还写了个监控脚本，每 5 分钟扫异常订单，发现同一单关联多个人就告警 —— 改完之后，再也没出现过超抢。
四、派单调度模块 —— 我优化了匹配算法，提了派单成功率
要是订单 30 分钟没人抢，就轮到这个模块上场了，我主要参与了匹配算法的优化和定时任务的开发。
首先是选待派单订单：用 XXL-JOB 做定时任务，每 10 分钟扫订单表，把 “待接单” 且超 30 分钟的标成 “待派单”。然后是匹配算法，我当时设计了三个评分维度，满分 100：技能匹配度 40 分（完全对得上给 40，沾点边给 20）、距离 30 分（5 公里内满 30，每多 1 公里减 5）、历史好评率 30 分（近 30 天好评率 ×30）。按得分取前 5 个候选，挨个推通知，10 分钟内没确认就推下一个，5 个都不接就转运营手动分配。
一开始算法有问题：好评率权重只有 20%，优质服务人员接单少。我拉了历史数据一看，好评率高的服务人员，用户复购率能提 30%，就把权重调到 30%，还加了 “服务完成率” 的隐藏因子 —— 近 30 天完成率低于 80% 就扣分。最后优质人员的接单率提了 15%，用户反馈也好多了。
还有个问题：有些区域服务人员少，派单成功率才 60%，用户老投诉。我就加了三个优化：区域内候选少于 3 人时，自动把接单范围扩 5 公里；稀缺区域把距离权重降成 20%，给 “愿意跨区” 的服务人员加 10 分；还做了个 “服务热力图”，运营能看到哪里缺人，针对性招募 —— 最后派单成功率提到了 85%。
五、订单管理模块 —— 我设计了状态机和日志监控
这个模块管订单从创建到完成的全流程，核心是保证状态不乱变、能追溯。我当时负责设计订单状态机和操作日志系统。
订单一共 8 个状态，严格按状态机走：支付完是 “待接单”，抢单 / 派单成功变 “待服务”，服务人员点 “开始服务” 就到 “服务中”，结束服务后等用户确认，确认完 “已完成”，用户评价后才算收尾。异常状态比如取消、售后，也得按规则转 —— 比如 “待服务” 只能转 “服务中” 或 “已取消”，不能跳着变。我用枚举类把状态和允许的流转目标写死，再用 Spring StateMachine 管理，避免有人乱改代码导致状态错乱。
还有个关键点是可追溯：我用 AOP 切了所有状态更新的方法，每次变状态都记日志 —— 订单 ID、旧状态、新状态、谁操作的（用户 / 服务人员 / 系统）、时间、IP，都存到 MongoDB 里。后来有用户投诉 “没服务却显示完成”，我们查日志发现是服务人员误点，很快就解决了。
当时还防了个漏洞：有些服务人员会恶意点 “结束服务” 骗钱。我加了两个校验：一是服务期间每 5 分钟要上报位置，偏离服务地址 1 公里以上就标异常；二是对比服务前后的照片，用简单的像素对比看有没有实质服务；异常订单会自动转人工审核，恶意操作 3 次就封号 —— 最后服务纠纷率降了 40%。
六、服务人员 / 企业管理模块 —— 我开发了 OCR 识别和资质校验
这个模块是保证服务质量的关键，我主要做了资质审核的自动化，减少运营的手工活。
服务人员入驻的时候，得传身份证、技能证书、健康证（有效期得≥6 个月）。我对接了百度 AI 的 OCR 接口，能自动提身份证上的姓名、身份证号，营业执照上的企业名称、信用代码 —— 提完还会跟用户填的信息比对，不一致就标异常。之前审核一单平均要 1 小时，用了 OCR 后 5 分钟就能搞定，错误率还降了 60%。
不过 OCR 也有问题：证件模糊、光线不好的时候，识别准确率才 85%，还得人工核对。我就加了三个优化：前端加拍摄指引，提醒 “保持清晰、光线足”，还能裁剪背景；后端同时调百度和阿里云的 OCR，取置信度高的结果；识别失败的字段（比如模糊的身份证号），自动标 “需人工核对”—— 最后准确率提到了 95%，运营也轻松多了。
另外，资质过期也是个麻烦事。我用 XXL-JOB 做了个每月 1 号的定时任务，查服务人员的健康证、企业的营业执照有没有过期，过期前 7 天推提醒，过期了就暂停接单权限，直到更新资质。
七、客户管理与营销管理模块 —— 我做了用户画像和优惠券功能
这个模块主要是拉留存、促转化，我参与了用户画像的构建和优惠券的核心逻辑。
用户画像这块，我们用 ES 存用户行为 —— 浏览、下单、评价这些，然后打标签：比如用户近 3 个月每周五都下 “深度保洁”，就标 “每周五活跃 + 高频深度保洁”；家里有宠物的，标 “宠物家庭”。之后按 RFM 模型分层：高价值用户给专属券（满 300 减 50），优先匹配优质服务人员；快流失的用户，发召回短信（“30 天没下单，赠 20 元无门槛券”）。首页推荐也按标签来，比如给 “宠物家庭” 推 “宠物专属保洁”，推荐点击率提了 25%。
优惠券这块，我主要解决 “超发” 和 “重复领” 的问题。运营创建活动时会设发放总量、每人限领 1 张，用户抢券的时候，我用 Redis 的 bitmap 记状态 ——key 是 “活动 ID + 用户 ID”，抢一张就标 1，防止重复领；库存用 Redis 计数器实时减，减到 0 就返回 “已抢完”。大促的时候峰值能到每秒 1000 多请求，Redis 扛不住，我就加了本地 Caffeine 缓存热门活动的库存（10 秒过期），还用水位线限流，每秒只放 800 个请求，超了就提示 “稍候再试”—— 最后没出现过超时。
最后再跟您总结下
这个项目上线后，覆盖了 20 多个城市，日均订单 10 万多，用户满意度 96%，也算验证了我们技术方案没问题。我在里面不只是写代码，更像是从业务到技术的 “翻译官”—— 比如跟产品经理对齐服务区域的配置逻辑，帮运营解决审核效率的问题，再用技术落地。这段经历让我对微服务架构、高并发处理这些有了实感，也练了从问题到解决方案的全链路能力。
