家政服务行业的竞争早已从“拼人力”转向“拼系统”。四川康宏源家庭服务有限公司近期完成了对自研调度平台的架构升级，核心目标只有一个：让保洁预约系统在高峰期也能扛住每秒上千次的并发请求。这个项目由公司技术部主导，前后迭代了四个月，今天把其中的关键设计思路拆解出来，供同行参考。

一、双写分离：预约与履约的异步解耦

最初我们的订单表是单库单表，一到周末上午9点到11点的预约高峰，数据库连接池直接被打满，用户端的响应时间从200ms飙到3秒以上。后来我们把家政平台开发中的核心链路拆成两条：写入路径走主库，查询路径走只读从库。同时引入消息队列，将保洁订单的创建、支付回调、服务人员派单等事件异步化处理。

实测效果：在模拟3000用户同时提交预约的压测场景下，订单创建的TPS从原来的480提升至2100，接口P99延迟稳定在800ms以内。对于上门服务平台而言，这个量级已经能覆盖绝大多数城市周末峰值。

二、基于地理位置的分片路由策略

家电清洗管理和日常保洁的服务半径通常不超过5公里。我们利用了这一点，在订单表的主键中嵌入城市ID + 区域编码，通过一致性哈希将数据分布到不同的物理分片。这样，用户在微信小程序里搜索“附近保洁”时，查询只会落在对应的分片上，避免了全表扫描。

具体实现上，我们用ShardingSphere做数据分片，分片键就是service_city_code。目前线上跑着32个分片，单分片数据量控制在500万行以内。这套方案让我们的家政小程序在弱网环境下的定位查询速度提升了近40%。

三、服务人员热力池与智能抢单

家政行业的瓶颈往往不在C端流量，而在供给侧调度。我们做了一个“热力池”模块：根据服务人员的历史接单位置、当前实时GPS、技能标签（比如是否擅长家电清洗管理），动态计算每个保洁员在15分钟内的可接单半径。当新订单进入系统时，不是广播推送，而是只推送给热力池中匹配度最高的5名服务人员。

这套逻辑上线后，订单被接起的平均时长从原来的4.2分钟缩短到了1.8分钟。而且由于减少了无关推送，服务人员端的App耗电量降低了约15%。

案例：一次真实的“双11”家政大促

去年双11，我们联合物业公司做了一次“9.9元深度保洁体验”活动，单日涌入的有效预约请求超过8万次。如果没有异步解耦和分片路由，系统大概率会雪崩。当时我们提前扩容了Kafka集群，将消费者组的并发数调高到64，同时开启了限流降级——超过阈值的请求直接返回“排队中”提示，让用户稍后重试。最终活动顺利完成，系统可用性维持在99.95%。

这套架构的落地，意味着四川康宏源家庭服务有限公司在家庭服务数字化方面又往前走了一步。从保洁预约系统到家政小程序，我们更看重的是每一步能否真实改善用户体验和员工效率。技术方案没有绝对的最优解，只有不断根据业务数据做调整。后续我们计划在多租户隔离和AI动态定价上继续投入，让平台更“聪明”一点。